[VOIPSEC] First Major VoIP Hacking Scheme Uncovered

[John Todd]

>http://www.accessintel.com/cgi-bin/press/show.cgi?1130972376
>
>"According to Zipper, hackers have figured out a way to manipulate the IP
>stream in order to steal long-distance service. Many in the communications
>industry are keeping things quiet while they assess the full extent of the
>potential damage, but sources admit this security breach "could expose a
>lot of companies to a great deal of fraud.""
>
>-Hank


It seems that this is a flaw related to lax "audio before answer" (or 
more appropriately: "audio before billing") logic in some 
softswitches or gateways.  This is such a well-known issue that I 
didn't even really consider it before Kevin's explanation of his 
discussions with the reporter, since this article was described as 
"First Major VoIP Hacking Scheme".  I'm going to guess that this is 
an issue with a single large carrier somewhere who has managed to 
evade detection of their lack of upgrades and fraud detection until 
now, and someone has managed to discover this glaring hole and is now 
self-promoting their hax0r abilities.

This seems to be a problem that would be a result of 
hyper-sensitivity to customer billing disputes.  Is this a relic of 
the past (1 or 2 seconds of _potentially_ incorrectly billed time?) 
or is this no longer an issue?  Or am I wrong about the causal 
reasons for this problem existing in the first place?  Or, is the 
issue written about in the article not in fact what Kevin describes 
below, and is some entirely new and clever flaw exploitation?

Note: Asterisk is immune to the answer-before-billing problem on the 
VoIP side, as described.

JT


>Date: Mon, 07 Nov 2005 08:43:51 -0600
>From: "Kevin P. Fleming" <kpfleming at digium.com>
>Organization: Digium, Inc.
>To: Asterisk Developers Mailing List <asterisk-dev at arizona.digium.com>
>Subject: Re: [Asterisk-Dev] Security issue mumblings
>Reply-To: Asterisk Developers Mailing List <asterisk-dev at lists.digium.com>
>
>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.
>_______________________________________________
>Asterisk-Dev mailing list
>Asterisk-Dev at lists.digium.com
>http://lists.digium.com/mailman/listinfo/asterisk-dev
>To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev