Panoramisk / The VoIP druid 

On peut être passionné par la téléphonie et prendre soin de soi : "Faites du sport, faites du vélo" est la devise du site d'e-commerce lancé par l'un des auteurs de Panoramisk : bikeo. Si vous faites du vélo, que ce soit en ville, sur la route ou sur les chemins plus accidentés, n'hésitez pas à aller faire un petit tour sur www.bikeo.fr pour vos prochains achats verts.
En plus leur plate-forme de téléphonie utilise Asterisk, comme quoi on peut la convergence est une réalité.

When looking at the published SIP exploit over a Grandstream IP phone¹, one could quickly arrive to the conclusion this was more a feature than a bug, for what purpose is the real question to be asked.
The exploit schematic² is really simple and SIP text message format ease these kind of attacks, but also our comprehension:

What we can see is that a 183 message is sent back to the phone but the session hadn’t been confirmed (when user hooks up) by an OK message. The 183 message is described in the RFC3261 as

The 183 (Session Progress) response is used to convey information
about the progress of the call that is not otherwise classified.  The
Reason-Phrase, header fields, or message body MAY be used to convey
more details about the call progress.
 

We are talking here about the « call progress », not the call established. So why pushing the RTP flow afterwards, it is a very strange reaction in the process itself, isn’t it?

This is the reason why I do not think it is a bug, maybe a side effect. We will probably never know.

Anyway, in order to avoid such exploit, not the attack itself since the code could be present, the best thing if probably to turn on the security features around SIP: TLS for the SIP transport with certificates and SRTP for the voice transport. These are not yet fully implemented on most equipments but it is the only way to quickly avoid such bad publicity and continue the adoption of VoIP.

1. see slashdot for example [↩]
2. see “Remote eavesdropping with SIP Phone GXV-3000” [↩]