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.

11 Comentarios

  • Hola Elio,

    Muy interesante el artículo, aunque parece que el link a la guía no funciona… :S

    Un saludo!

    Israel 2010-02-19

  • El enlace a la guía está caput…

    Juan Antonio Ibáñez 2010-02-19

  • Corregido, gracias por el aviso. 😀

    Elio Rojano 2010-02-19

  • Pues yo pienso que sí es un fallo de asterisk.

    Si marco
    3pepota&DAHDI/g1/952123456

    Debería hacer un

    Dial SIP/”3pepota&DAHDI/g1/952123456″

    (vamos… ver todo lo que hemos marcado como un único parámetro)

    davidp 2010-02-22

  • Gracias por la info, ahi te envíe un trackback a este post, ya habia leido el post que publicó Ollé el sábado pasado, gracias por aporte, me alegra que la gente de Asterisk halla sacado un release para ayudar a solucionar estos problemas que como bien decís son falló en la implementación del dialplan no del Asterisk. Excelente saludos desde Costa Rica

    Jose Tapia 2010-02-24

  • Elio, de que manera puedo acceder a leer el post original de Olle? acaso fue en alguna lista? me podes pasar la info por favor? gracias.

    Martin 2010-02-26

  • Elio que fue de Asterisk Desktop Assistant (ADA)

    Saludos

    Willy 2010-02-26

  • @Margin: Es el primer enlace del post.

    @Willy: Tengo un post preparado hablando sobre el ADA.
    Como adelanto te diré que han abandonado el proyecto y nadie más se va a hacer cargo de él. Una lástima que no lo liberen, pero de hecho ya han dicho que no lo van a hacer. 🙁

    Elio Rojano 2010-02-27

  • […] Article about this security issue in Spanish (sinologic.net) Share and Enjoy: These icons link to social bookmarking sites where readers can share and discover new web pages. […]

    Important security advisory for Asterisk :: Dialstring injections 2010-02-27

  • […] en el código, sacando parches que eviten problemas de seguridad (por ejemplo, la solución para el problema de dial-injection publicado hace unos dias),  pero eso no es suficiente, ya que la mayoría de los  problemas […]

    » Seguridad y BFD (Brute Force Deny) en Asterisk SinoLogic 2010-03-12
Entradas recientes
Comentarios recientes
Archivos
Categorías

© 2014 Sinologic, inc. All rights reserved.

Menú

Redes sociales