[VOIPSEC] Anyone aware of public disclosures of security incidents related to SIP trunks?

[J. Oquendo]

Dan York wrote:
> VOIPSEC readers,
>
> Can anyone point me to any public disclosures of security incidents
> related to SIP trunks?  (i.e. SIP connections from an on-premise
> IP-PBX/callserver to a SIP service provider)  Companies that lost phone
> service due to a DoS against a SIP service provider?  Disclosure of
> information related to info captured from a SIP trunk?  Reported toll
> fraud due to abuse of a SIP connection?  (The famous Pena/Moore case of
> 2006 was toll fraud over H.323.)
>
> I've been doing some digging but so far haven't found any public
> mentions of actual incidents.  So either I'm not searching on the right
> terms or I suspect any incidents aren't being reported publicly (or are
> being classified as some other kind of incidents).
>
> I ask because I'm doing some writing and would like to include a "real"
> incident related to SIP trunking security instead of making up a
> fictitious "hypothetical" scenario.
>
> Any pointers would be greatly appreciated.
>
> Thanks,
> Dan
>

I haven't seen any public disclosures and I doubt you will find any
instances to be honest. For a more rapid response on the amount of
these types of incidents, you may shoot a message off to the
VoiceOPS mailing list:

https://puck.nether.net/mailman/listinfo/voiceops

Now for the rambling ;) (as usual)

When my colleagues and I configure a trunk with someone, there are
a multitude of methods to do so. Username/Password authentication
which is a horrible design due to programs like Hyrda, sipvicious,
etc., IP based authentication and a few others means to achieve
this. We choose to use IP authentication based (with another mode
I won't publicly disclose).

In an IP based authentication exchange, the odds of being hit
with a high toll fraud bill are lower than that of a username and
password based exchange. This is due to the fact that in order to
generate a conversation (traffic) to pass off a call (illegal call
without it dropping) the caller needs to receive data to keep the
call open. In IP based authentication, the most someone can do is
blind spoof. Sure you can shoot off hundreds and thousands of
calls but as an attacker, you'd never be able to truly initiate
a call. You could do some proxy voodoo, but its highly unlikely
to take place.

Remember: SIP messaging --> 5060 followed by the convo (RTP) which
is ranDumb (most of the time).

This is all based on a standard SBC trunk. Say it were an Asterisk
trunk. The topology would usually be as follows:

IP Phone --> Asterisk --> Internet --> Trunk --> Carrier --> etc.

This would NOT stop someone from trunking with a vulnerable
Asterisk box in which from the carrier end, all we'd see is this:

Rogue * --> Trunk --> Legit Asterisk Box --> Net --> Trunk Carrier

In this instance, the carrier doesn't know or care about anything
other than a legitimate trunk sending traffic. This is where it
would get fuzzy... On to the compromise...

A few months ago I performed an incident response for a trunked
client of ours who was compromised, backdoored and used as a
botnet. In all 30+ Asterisk machines. The attackers were able to
perform about 18k in toll fraud and I quote from my email:

- We also experienced two major traffic leaks this year, accounting
for unauthorized calls that used our servers, by breaking into them
- 10,000 in unauthorized traffic termination to Australia - CellPhones
-  8,000 in unauthorized traffic to hot lines in Austria

However that cost pales in comparison to what was ultimately dished
out: (quoting again)

- DoS attack that degraded severely service to customers, which
costed us at least:
- $25,000 in direct credits to customers for intermittence and
non-confirming service
- $150,000 in at least 300 customers that cancelled their service,
due to the problems experienced (considering 12-month revenue)
- $25,000 in time spend internally and with external consultants

/ End quote

$218,000 estimated. This did not include any additional charges
after the clean-up, programming and installation of Asterisk based
IPS I concocted, system hardening, training and post-monitoring.
Quarter of a million and I say it without having to think twice.

So again, from the carriers perspective, its not that it isn't
being reported, the fact is that when you have clients making
trunks, if someone is trunking to them, from the carriers eyes
it will not be seen. As for anyone trying to trunk to us,
they'd need to know a lot of things. 1) Which trunk we're
sending a client to 2) to compromise our SBC and enter their
IP space for authentication + another variable 3) a method to
overwhelm my SBC with enough events to hide their attempts.



-- 

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
J. Oquendo
SGFA, SGFE, C|EH, CNDA, CHFI, OSCP

"It takes 20 years to build a reputation and five minutes to
ruin it. If you think about that, you'll do things
differently." - Warren Buffett

227C 5D35 7DCB 0893 95AA  4771 1DCE 1FD1 5CCD 6B5E
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x5CCD6B5E