Archivo de la etiqueta: Seguridad

svcrash: ¿el comienzo del anti-hacking en SIP?

Hace unas semanas fue presentada (el autor también fue invitado al VUC) la utilidad svrash.py, de la suite de seguridad SIPVicious. Con esta utilidad es posible hacer que las utilidades svwar.py y svcrack.py se dentengan, ya que les provoca una excepción. ¿WTF?

Así es, svcrash es capaz de detener los ataques causados desde SIPVicious. Su autor no programó las utilidades para que la gente lanzara ataques contra otros, sino para que cualquiera pudiera comprobar el nivel de seguridad de sus propios sistemas, pero como hay malos sueltos por ahí que utilizan las herramientas de un modo bastante dudoso, programó svcrack.

Svcrash aprovecha un bug (tal vez dejado intencionadamente) para convertirlo en una feature: todas las versiones de SIPVicious tienen un bug que provoca la parada del programa debido a una excepción no controlada si se le envía un To tag con determinada forma. El funcionamiento de svcrash es sencillo: responde a los requests enviados por svcrack o svwar con un 200 OK con el To tag adecuado para provocar una excepción. El autor incluso ha añadido un modo automático, en el cual svcrash funciona en modo demonio leyendo los logs de Asterisk, y responde con éstos 200 OK (con el To tag adecuado) en caso de que Asterisk indique un fallo de autenticación en los logs.

Podéis ver un vídeo de su funcionamiento aquí.

Además de ser una manera elegante de terminar un ataque, el concepto de svcrash me hizo pensar un rato… ¿y si en lugar de bloquear o evitar un ataque simplemente contraatacamos, llegado el momento?

Supongamos el siguiente escenario: estamos sufriendo un ataque con el objetivo de adivinar el password de alguno de nuestros usuarios SIP. Lo habitual al detectar el tráfico generado por éste tipo de ataques suele ser bloquear el acceso de la IP en cuestión. Pero eso no quiere decir que el atacante haya dejado de enviar paquetes. El atacante podría enviarnos tráfico desde distintas IPs de manera dinámica, lo que haría más complicado bloquearlo, aunque tampoco imposible.

Si “la mejor defensa es un buen ataque” aquí va una idea: extender el concepto de svcrash y crear una suite de anti-hacking para SIP. Las herramientas de ataque para SIP no suelen implementar un completo cliente SIP, básicamente se quieren enviar paquetes SIP por un socket rápido o con ciertas credenciales. Por lo tanto, podríamos suponer que la herramienta que nos ataque haya dejado algún caso sin contemplar en su parser y podríamos provocar una excepción en la aplicación con una respuesta especialmente preparada (tal y como hace svcrash). Aquí van unas cuantas ideas que se me ocurren a botepronto:

  • Que la respuesta empiece con “SIP/1.0 200 OK”.
  • Utilizar unicode en las cabeceras From y To. (el soporte unicode es algo en lo que casi nunca se piensa desde el principio…)
  • Eliminar cabeceras de manera arbitraria: responder sin Contact, sin From ni To, …

Es solo una idea, pero sería interesante ver alguna herramienta que empiece a responder con alguna de las respuestas malvadas cuando detecte X intentos de autenticación fallidos, ¿no creéis?

Happy anti-hacking! 🙂

Entrevista con Blake Cornell, descubridor del bug AST-2009-006

Desde que el año pasado publiqué aquí la noticia de el primer 0day en IAX2 he tenido la ocasión de hablar en varias ocasiones con Blake Cornell, su autor. Posteriormente él mismo descubrió otros 9 bugs de seguridad y hace bien poco Digium tomó cartas en el asunto y arregló el problema.

A raíz de esto intercambié unos cuantos mails con él, fruto de los cuales es esta entrevista, que traduciría al castellano si no fuera porque me da algo de pereza y se perdería la esencia de sus respuestas 😉

Me ha parecido particularmente interesante la descripción de la resolución del problema en IAX2 así como los consejos de seguridad que comenta. ¡Espero que os guste!

Q1: Describe a bit yourself: who are you and what do you do?

I’ve been involved in security for several years. Currently, I work for a large telecommunications and professional services organization. I perform penetration tests and assessments for financial, telecommunications, media and other sensitive systems.

Q2: When did you start playing around with Asterisk?

I started using Asterisk roughly 5 years ago. Initially, I used Asterisk to create viable communications solutions for my clients. Strictly no security research and only secure implimentations. Luckily for me, I was able to combine my previous security methodologies, via fuzzing specifically, with my knowledge of IAX2 to find the AST-2009-006 issue.

Q3: Do you think that Asterisk’s IAX2 implementation is secure now?

Currently, the implementation is not as secure as I’d prefer.  If the newly implimented challenge hash were predictable then this solution could be broken easily.

This challenge hash is determined by the server by combining the source IP, port number, the time since epoch and a “random” number to create a SHA1 hash.

+#define CALLTOKEN_HASH_FORMAT “%s%d%u%d”  /* address + port + ts + randomcalldata */

The server then sends this hash to the IAX2 client and waits for the identical hash in the response.  IAX2 will only assign a call number at this point.  This hash only tests agaist spoofing while DoS attacks.  An Asterisk administrator can then throttle the number of call numbers via IP address.

If an attacker can guess the randomcalldata then they can accurately predict the challenge hash.

+       randomcalltokendata = ast_random();

This randomcalltokendata is generated once when loading chan_iax2.  Its not uncommon for an Asterisk server to have over a year of uptime.  This number won’t change frequently.  If you manage to determine the current value then you’ve successfully broken it.  This is definitely a compensating control as long as the hash is strong enough.

Q4: Is there any other security enhancement you’d do to Asterisk?

Regarding the patch for AST-2009-006 I would randomize the randomcalltokendata value upon every request.  This would mitigate any challenge determination attack vector.

Following proper procedures when possible.  IAX2 was designed for Inter-Asterisk communication.  Since IAX2 is becoming popular with soft/hard phones this is no longer the case.

Use encryption on signalling and media.  Also use VPN tunnels as often as possible.  Any publically facing VoIP service is a target, be aware of this. Utilize proper ACL’s and firewall rules on OSI layers 3 and 4.  This will limit an attackers ability to target your VoIP services.

Q5: Did you study any other VoIP related software?

Most of my billable work involves design reviews and subtle, not complex, penetration tests for large organizations. My research is currently limited to IAX2 and SIP, still pretty nasty though. I’ve plans to test DUNDI soon, maybe within 6 to 8 months. Owning DUNDI would be a nasty proposition.

Q6: Generally speaking: do you think VoIP is secure nowadays?

No!  Some nasty things are going to be public soon.  I have a few Call for Papers out with some reputable conferences.  I plan to reveal some of the details then but it could be considered a basic example of how to build a VoIP Darknet.

Q7: What are your main areas of interest?

I support and am a New York, New Jersey and Long Island board member of OWASP.  OWASP is an application security consortium with members, meetings and conferences around the world.

I’ve been working on fuzzing SIP.  More thourough then my IAX2 fuzzer.  I had sent you a PoC video showing an attack against PBXware that added a new user with administrator privledges (which is now fixed).  This flaw was found with my SIP fuzzer with relative ease.  Less then an hour from scan to working exploit.  I’ve been calling this type of vector “SIP vectored XSS attacks”.

Currently, I’ve only been interested with security research for VoIP. AST-2009-006 was a design flaw.  I’m looking for other design flaws within SIP implimentations.

Basically, my main interests are application and infrastructure security.

Q8: How would you describe you relationship with Digium?

Not pleasant.  Some employees at Digium absolutely detest my existence. Sucks for them.  I don’t let that deter me though and am lucky I have found a few people within management whom appreciate my voluntary efforts.  That helps a lot.  In the future I at least know whom I can rely on and whom to ignore.

If anyone whom knows of security flaws that affect Asterisk and are afraid that they will have libel commited against them, by Digium employees none the less, please feel free to contact me directly.  I’ve been through that mess already and can mitigate it in the future.  I can help you help them.

I have a lot of respect for Digium.  There are many talented peopole working there.  Asterisk is a viable solution for millions of companies.  It has the potential to change how the world communicates.

I believe those in power within Digium will continue to do the right thing.

Thanks for taking the time to answer my questions Blake! 🙂

Comienza el desarrollo de un framework de seguridad en Asterisk

La seguridad en VoIP es algo que no ha preocupado demasiado a la gente, pero que cada vez es más necesario. La inexistencia de ataques en el pasado ha podido ser la causa de que no se haya pensado antes en la seguridad en la VoIP.

Asterisk es un claro ejemplo de esto, basta con hacer un poco de flooding de lo que sea (mensajes SIP OPTIONS por ejemplo) para dejarlo fuera de combate. Esto puede solucionarse situando Asterisk detrás de un software que mitigue eses efectos, como podría ser un IDS como Snort. Gracias a Snort podemos evitar ataques DoS, pero es una ñapa… ¡Asterisk debería ser capaz de detctar que está siendo atacado!

Además, cuando hablamos de seguridad en VoIP hay que tener en cuenta más factores además de los ataques DoS, ya que también es posible que algún usuario malvado intente llamar a través de nuestro sistema sin las credenciales adecuadas.

Tras múltiples discusiones en la lista Asterisk-Dev y en AstriDevCon del año pasado, Russell Bryant acaba de mandar un email con una propuesta para un framework de seguridad en Asterisk. Su propuesta implica la creación de 2 subsistemas:

  • Generación de eventos de seguridad: Se utilizará un API para la generación de eventos relativos a la seguridad desde cualquier parte del código.
  • Log de eventos de seguridad: Además de generar los eventos será necesario recogerlos y generar algún tipo de log. La idea es utilizar algún tipo de herramienta externa como fail2ban para reaccionar ante los eventos relativos a la seguridad.

Hay varias cosas que me gustaría ver mejoradas en Asterisk, pero esta idea que vengo siguiendo de cerca me parece muy interesante. Veremos qué pasa.

Lanzado fuzzer para IAX2

Leo en VoIP Zero Day que el descubridor de los tropecientos bugs de IAX2 ha lanzado su fuzzer IAX, con el que descubrió dichos bugs.

El fuzzer ha sido incluido en VoIPER, una site para fuzzing de SIP. ¡Vamos a probarlo!

Lo primero es descargarnos el código desde el SVN, ya que el fuzzer de IAX de momento solo está en trunk:


svn co https://voiper.svn.sourceforge.net/svnroot/voiper/trunk/ voiper-trunk

Para que el fuzzer funcione es necesario instalar la librería libnet-subnets-perl:


apt-get install libnet-subnets-perl

Para empezar nuestro ataque ejecutamos lo siguiente:


cd voiper-trunk/iaxFuzzer
./iaxFuzz.pl -h 192.168.1.112 --bruteforce --dos

Al lanzar el ataque esto es lo que pasa en servidor de Asterisk:

Como se puede observar Asterisk se pone a comerse la CPU entera, llegando al 100%. Esto, obviamente, impide a Asterisk funcionar de manera normal, ya que tiene todos sus recursos paralizados por el ataque. Tras finalizar el ataque el consumo de CPU no cesa (al menos en la prueba que hice) y tuve que reiniciar por completo Asterisk para recuperar el servicio:

El chan_sip de Asterisk no es perfecto, apesta bastante, pero ¿realmente queréis seguir usando IAX2? Yo no.

Otros 9 exploits de denegación de servicio remota en IAX2

Ya comentamos hace tiempo que en VoIP Zero Day habían publicado un exploit que provocaba un ataque remoto de denegación de servicio (DoS) en IAX.

Pues al parecer resulta que el autor se ha cansado de que en Digium no le hagan caso y ha decidido publicar ¡otros 9 exploits de denegación de servicio remota para IAX2! Resulta cuanto menos sorprendente ver que la propia compañía que ha conseguido llevar el protocolo IAX hasta un RFC tenga una implementación tan deficiente (aparentemente).

Para los que os apetezca jugar, aquí tenéis todos lo exploits. Sed buenos.

iaxControlRegReqEncryption
iaxControlNewCallingPres
iaxControlNewCallingTns
iaxControlNewCallingTon
iaxControlNewRegReqv
iaxControlNewRRJitter
iaxControlNewRRLoss
iaxControlNewRRPkts
iaxControlNewCalledno

Curiosamente hoy alguien preguntaba en la lista Asterisk-ES a ver qué protocolo era mejor: SIP o IAX. ¿Tengo que responder?

Imágen extraida de AsteriskBlog

(in)seguridad en VoIP @ voip2day

No he tenido tiempo, pero tenía este post en la recámara, así que más vale tarde que nunca 🙂 Hace tiempo que subía las dispositivas sobre la charla que dí en el voip2day a SlideShare, pero no lo había comentado por aquí.

En la charla, que titulé (in)seguridad en VoIP traté de ofrecer una visión general acerca del estado de la seguridad en lo que a VoIP se refiere. Además, y dado que era el día de la comunidad Asterisk-ES profundicé más en este software en concreto y le hice sufrir un poco 🙂

Espero que os guste, y recordad, ningún puerto 5060 está a salvo 🙂

Por otro lado, aunque ya lo comenté in situ, me gustaría felicitar a la organización por el evento.
Yo solo estuve el viernes, pero creo que (al menos) ese día fue todo un éxito. 🙂

Exploit de denegación de servicio remota que afecta a todas las versiones de Asterisk

Buceando por Internet, el otro día caí en esta interesante web: http://www.voip0day.com. Allí comentaban que hacía más de 30 días que habían notificado a Digium  una vulnerabilidad en IAX que podía dejar Asterisk inutilizado mediante un ataque de denegación de servicio.

Hoy, Manwe y yo nos hemos puesto a probarlo, para comprobar si Asterisk se quedaba efectivamente fuera de combate. Las pruebas las hemos realizado sobre un Asterisk 1.4.21.1 (la versión que teníamos en los portátiles, cuando volvamos de las vacaciones probaremos más a fondo) pero los autores afirman que el exploit funciona con todas las versiones de Asterisk.

El funcionamiento es relativamente sencillo: el script comienza a mandar paquetes incorrectos a Asterisk y éste es incapaz de seguir procesando peticiones IAX, al quedarse completamente inutilizado. Al cesar el ataque Asterisk no se recupera, por lo que es necesario reiniciar el servicio.

El exploit lo podéis descargar aquí y para lanzarlo basta con ejecutar lo siguiente:

saghul@topux:~/apps/voip$ perl iaxControlNewAuthmethods.pl -h 10.10.10.3

siendo 10.10.0.3 la dirección IP de la víctima. Al lanzar el ataque veremos cómo se van enviando los paquetes:

Y en el servidor Asterisk, podemos visualizar todos los mensajes de error que hacen que Asterisk quede inutilizado.

Cuidado con tener el puerto 4569 abierto; os vigilo 😉

Probando BackTrack 3

Para los que no la conozcan, BackTrack es una distro orientada a la seguidad y al análisis forense, que contiene decenas de herramientas para el análisis, fingerprinting, exploits, fuzzing, etc…

Desde la versión anterior, Back Track incluye herramientas de seguridad relacionadas con la VoIP, tales como SIPcrack, Vomit, PROTOSS fuzzer, SIPVicious, etc… y en esta versión, BackTrack 3, hay bastantes más!

En su web podéis bajar esta distro en 3 sabores: ISO para grabar en CD, ISO para pendrive USB e imágen para VMWare. Yo he optado por esta última y la verdad, me ha gustado mucho. Además el escritorio es KDE! 🙂

Aquí os dejo una captura, y he colgado alguna más en Flickr. Si os interesa la seguridad, os invito a probarla 🙂

backtrack3_3.png

Material de la charla sobre Seguridad en VoIP

Con motivo de la Semana ESIDE 2008, la semana pasada dí una charla sobre seguridad en VoIP.

El contenido estaba bastante enfocado a ataques prácticos, con ejemplos y tal, exponiendo ataques que se pueden realizar contra la los terminales, la red y la PBX, que en este caso fue Asterisk.

He colgado las transparencias en SlideShare, y en la sección de Documentos tenéis las transparencias también y un tar.gz con las fuentes de los programas utilizados, por si no los encontráis o dejan de estar disponibles.

Espero que os sirva 🙂

slideshare-voip-sec.png

Sobre seguridad en SIP…

Leyendo VoIPSA, me encuentro con las transparencias que utilizó Hannes Tschofenig en la 3ª ETSI Security Workshop.

En su charla, habla de la gestión de identidades en SIP y la seguridad del media (audio y/o vídeo). Les he echado un vistazo y parecen bastante interesantes, comenta cosas como el uso de TLS o MIKEY en SIP. Podéis descargarlas aquí. (están en ppt 🙁 )

sip_authentication.gif