Una nueva versión de Asterisk corrige el dialplan injection

Hace una semana Olle Johansson anunció un fallo de seguridad bastante interesante, pero no me atreví a escribir sobre él hasta que no lo hubiésemos probado y al fín lo hicimos, y los resultados son escalofriantes:

Imaginemos que utilizamos un terminal IP (o softphone) con una cuenta limitada a extensiones SIP, en principio sólo podríamos llamar a extensiones SIP, pero el bug explica cómo aprovechar una mala programacion del dialplan y poder llamar a donde queramos:

El fallo de seguridad ocurre principalmente si tenemos una línea como esta:

exten=>_X.,1,Dial(SIP/${EXTEN})

De manera que cualquier número que marquemos, intentará llamar por SIP:

Si marcamos 800, en el dialplan se ejecutará: exten=>800,1,Dial(SIP/800)
Si queremos llamar hacia el exterior, marcamos 952123456, y en el dialplan se ejecutará: exten=>952123456,1,Dial(SIP/952123456)

Claro, que si no tenemos una extensión SIP con ese número, no hará nada y colgará la llamada.
Pero como todos ‘deberíamos’ saber, el comodín punto ‘.’ admite cualquier cosa y tantas como queramos (símbolos, letras, etc) por lo que si en lugar de utilizar un terminal IP utilizamos un softphone, podríamos llamar a nombres o a cualquier cosa que podamos escribir:

Si marcamos 3pepota, en el dialplan se ejecutará:
exten=>3pepota,1,Dial(SIP/3pepota)

Tampoco llamará a nadie, ya que la extensión 3pepota no existe.

El fallo de seguridad consiste en que también podemos utilizar signos de puntuación y otros caracteres, por lo que perfectamente podríamos marcar:

Si marcamos 3pepota&DAHDI/g1/952123456, en el dialplán se ejecutará:

exten=>3pepota&DAHDI/g1/952123456,1,Dial(SIP/3pepota&DAHDI/g1/952123456)

Asterisk por lo tanto, al existir el símbolo ‘&’ llamará a ambos sitios simultaneamente:

Llamará  a SIP/3pepota y a  DAHDI/g1/952123456

De forma que si una de las partes contesta, podremos hablar con ella saltándonos todas las prohibiciones.

Sencillo ¿verdad?

Para evitar esto, Olle Johansson propuso un «arreglo» en el dialplan que podeis ver en la web donde describe el problema.

Hay que dejar claro que esto NO ES UN FALLO DE ASTERISK, si no un fallo de la persona que ha programado el dialplan. No obstante, parece que ha salido una versión que dispone de herramientas (aplicaciones y t funciones que ayuda a prevenir esta práctica, aunque la mejor práctica es evitar utilizar el punto tanto como nos sea posible, y que si queremos programar llamadas a extensiones que empiezan en 200 y acaban en 799 deberíamos escribir algo como:

exten=>_[2-7]XX,1,Dial(SIP/${EXTEN})

o como mínimo:

exten=>_XXX,1,Dial(SIP/${EXTEN})

pero nunca jamás:

exten=>_X.,1,Dial(SIP/${EXTEN})

Así que se ha redactado una «guía del buen administrador» para que aquellos que quieran administrar un Asterisk, puedan seguir unos consejos muy interesantes.

Las nuevas versiones con las herramientas y funciones como FILTER().

Además, un consejo gratuito: para las llamadas internacionales que sí utilizan puntos y son bastante «suculentas», os recomiendo utilizar algo como esto:

exten=>_00XXXX.,1,ExecIF(${REGEX(«&,/|@» ${EXTEN})}?Congestion())
exten=>_00XXXX.,n,Authenticate(1234) ;; Numero pin conocido por todos los usuarios.
exten=>_00XXXX.,n,Dial(SIP/${EXTEN}@proveedorIP)

De esta forma, si hubiese algún fallo por nuestra parte y dejamos desprotegida la entrada de llamadas por SIP para que cualquiera pudiera llamarnos, con capacidad de salto entre contextos internos y permitiésemos en algún momento que alguien remoto sin autentificar pueda llamar a un número internacional a través nuestra, por lo menos tendría que insertar un código PIN nada agradable y que tendría que averiguar.
Una pequeña molestia para las llamadas internacionales, que nos puede ahorrar mucho dinero si pasa lo peor.