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! 🙂
2 thoughts on “Entrevista con Blake Cornell, descubridor del bug AST-2009-006”
«No entiendo SIP, así que creo mi propio protocolo de VoIP. No separo señalización de media porque para mí la VoIP sólo existe del teléfono a la centralita. Intento a toda costa tener un RFC sobre mi protocolo VoIP. Me la suda la implementación de dicho protocolo en mi propia centralita que yo mismo he desarrollado.