Archivo de la etiqueta: IAX2

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! 🙂

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 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
./ -h --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.


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

IAX2 ya es el RFC5456

Tras mucho tiempo en estado de draft IAX2 ha sido publicado como estándar: el RFC 5456.

IAX2 es un protocolo un protocolo diseñado específicamente para interconectar sistemas Asterisk aunque su uso se ha extendido a algunos softphones y hardphones por no sufrir problemas de NAT, como ocurre en SIP. Hay que aclarar que esto no es del todo cierto, ya que al unificar señalizacion y flujo multimedia (como ocurre en las lineas analógicas) no afronta el NAT. No obstante, su simplicidad lo hace idóneo para las interconexiones entre servidores Asterisk.

Esta es sin duda una buena noticia dado el numero creciente de Asterisk dispersos por el mundo, pero no tenemos que olvidar que IAX2 es un protocolo solo para unir servidores Asterisk, para terminales ya disponemos de un protocolo mucho mejor: SIP (RFC3261).