[Asterisk-Dev] Security issue mumblings

[Kevin P. Fleming]

John Todd wrote:

> http://www.accessintel.com/cgi-bin/press/show.cgi?1130972376
> 
> Can anyone here speak more clearly on this otherwise un-useful list of 
> assertions as to "security flaws with VoIP" specifically referencing 
> Asterisk?  The lack of a protocol discussion is suspicious - VoIP is not 
> homogenous.  The other term of "billing code" is also suspicious - I 
> can't recall a "billing code" field in my SIP packets.  CCM is mentioned 
> - is this an SCCP issue?
> 
> Perhaps most importantly (and relevant to -dev) is this an issue that 
> can be resolved or patched within Asterisk, or is it that Asterisk is 
> being used as the toolset to wedge into other platforms?

As one of the two employees of Digium who spent time talking with the 
reporter, I'll communicate my understanding of the situation :-)

First, I still take issue with the reporter saying this is 'VOIP 
hack'... that's a significant overstatement of the facts as I believe 
them to be, but he's got to sell magazines <G>

As far as we are aware, there are two possible methods of exploit here. 
One of them, as already mentioned by Tilghman, is that some SIP 
softswitches don't begin call billing for outbound calls until they 
receive an ACK to their 200 OK. Depending on how long they will allow 
the call to stay up without the ACK being received, the call will be 
'up' and in two-way audio mode without being billed. Asterisk does not 
work this way, and never will (nor should it)... it begins the call 
billing when the 200 OK is sent. A similar technique is reportedly 
possible on PRI links, by never sending an CONNECT ACKNOWLEDGE for a 
CONNECT received from the switch; however, the amount of time the call 
can stay up in this condition is much less than in the SIP scenario.

The other possible exploit appears to be a vulnerability in some ISDN 
switches; it is not known how widespread it is (if at all), and whether 
the vulnerability is dependent on software releases, configuration or 
some other combination of variables. The essential point in the story is 
correct, though it uses the wrong terminology ('billing code'). Without 
going into specifics, it appears that some switches can be convinced to 
mark a call as 'not billable', even though it completed and was up for 
any amount of time the caller wished. This is not possible using 
traditional CPE that connects to PRI circuits, since their Q.931 
handling is not modifiable, but Asterisk (obviously) and possibly CCM 
can be convinced to take advantage of this vulnerability.

However (and this is an important point), even if a customer finds a way 
to take advantage of this vulnerability, any reputable carrier's fraud 
detection systems will notice the change quite quickly and raise alarms. 
Given this, it's doubtful that anyone will be able to make a significant 
amount of calls using this technique, but it's certainly possible that a 
poorly-managed carrier network would be susceptible to some losses.