The Wild World of VoIP

Wes Brown | September 30th, 2008 | Filed Under: Bitching About Protocols, Feature, Industry Punditry, Reversing

I have a confession to make.

I’m Deaf.  As in, American Sign Language is my native language along with English.  I don’t hear very well either, though I fake it pretty well.

I have also been working on Voice over IP security for a number of months.

Yes, you may laugh now.  A Deaf man working with VoIP.

In the past, I was relatively disinterested in the whole idea, until I was tossed onto a large scale VoIP assessment project.  After all, I would never use these systems being Deaf.  Little did I know that I was shutting myself out of a fascinating and byzantine world.

VoIP is just a method of streaming data, and signalling where the data is to go, over an IP network infrastructure.  That’s all.  There is nothing complicated about this.  The fact that it carries voice does not make it magical.  Data is data.

And it is for this reason that I was able to assess, manipulate and break VoIP components in interesting ways.  It is just data over a network that can be observed, and altered.

However, there were times when I had to use a VoIP hardphone to make calls and troubleshoot.  Speakerphone mode and the volume button came in handy.  There was also always grabbing the unwary coworker and asking him what the voice error message from the switch was.  Fortunately this was a very rare instance over the months long engagement.

While the concept of VoIP is inherently simple, infrastructure implementations are often not.  Large-scale enterprise infrastructure are on an entirely different scale from Joe User using Vonage on his DSL connection.  These enterpise VoIP solutions typically include a signalling proxy or gateway, voicemail servers, voice recognition switchboard, conferencing, E-911, and various other components.

On top of that, SIP is not the only lingua franca of VoIP.  There is also the Media Gateway Control Protocol, and Megaco, usually used for PSTN to IP or IP to IP networks.  Also used on the client end are Nortel’s UNISTIM and Cisco’s Skinny Client Control Protocol (SCCP).

Many of these protocols are derived from older digital switching stuff such as Signaling System 7.  And the mindset that comes from completely controlling the communications mechanism carries over, creating huge exposures.  These systems were never designed to be on an open untrusted network, and the inheritors of these legacy protocols are essentially digital switching carried over IP instead of the control channel of a T1.  There are plenty of issues to be found during testing because of this.

Not only that, but the telecommunications vendors are their own worst enemies. I had one vendor, when provided with a Unix-based system that had been hardened and secured, to install their management tools on, they insisted on an unsecured vanilla installation.  They refused to consider installing on anything but a virgin operating system.  Unsurprisingly, in the security audit that followed, the system completely failed.

With another vendor, I found severe issues in their SIP stack by fuzzing with the protos test suite.  When confronted with this, their answer was to use a SIP proxy or firewall, because the system was never meant to be talking SIP with anything but the trunking server.  They were not willing to put in the engineering effort to harden their SIP stack.

To these telecommunications vendors, despite being on an IP based network, security is a feature, not a core requirement.

VoIP is a wild and byzantine world! Join in, and help make it a better place.  If I can do this, so can you — here’s some tips to get started:

  • Use a fuzzer.  Matasano Security uses our own Ruby framework, Ruckus, to define protocol fields and headers.  Until we release it, you might use peach fuzzer, sulley, or spike.
  • Read a lot of RFCs.  I read hundreds of pages of RFCs until my eyes bled.
  • Get intimately familiar with Wireshark.  Wireshark was a huge help in allowing us to write our own custom implementations of the VoIP protocols.  The dissector source code is rather handy.  Use other people’s work, don’t reinvent the wheel!
  • A general purpose TCP/UDP switchboard proxy is also very helpful.  We typically start with just proxying.  And then as we understand the protocol more and more and implement it, the stream can be redirected through our Ruckus implementation for testing and debugging.
  • Remember: VoIP is data and signalling of how the data gets there.  Think of how to suborn the switching.  Can we spoof a signal?  Can we redirect streams?

Viewing 6 Comments

    • ^
    • v
    yes, voip services by large carriers or inside enterprises are horridly built (from a security standpoint at least). One very large telco has/had (they are migrating away finally as I recall) a SBC implementation built by them before the 'SBC" even really existed. That's nice, it's innovative, it sucks rocks... more than 30 call setups/second and poof it dies. This from a company that does more than a billion minutes a month on their network, so the ought to understand call setup rates, scaling, etc...

    One of the prime vendors for this telco actually, when asked to help design a solution for a particular VoIP problem turned over a set of documentation (very thorough and long) for the solution... They forgot to search/replace the competitors name in the documentation, they also couldn't be bothered to understand that in the original specifications there were large flashing notes about: "This will be deployed on the public network". Most of the docs, when they danced around 'security' would say: "and this must be deployed on a private network or behind a sip aware firewall", fine... got any firewalls that have ATM/oc-12 interfaces?

    Security isn't even a 'feature' for the vendors, and the operators rarely care about anything other than 'fraud' issues... 'Jane calls Joe, Joe tells the SIP gateway that the call ends prior to the 1min mark, since the media goes peer-to-peer jane/joe talk for a month for free on an open line, giant-telco loses 1mon of call time charges, boo!' No current production telco (and even enterprises rarely do this) voip system does p2p media, they all push everything through an SBC so that CALEA and other 'features' can be enabled on calls.

    ugh... voip-security-hotbutton.
    • ^
    • v
    Yeah, I've noticed that the standard vendor response is to use a SBC, or a SIP proxy. But it doesn't really solve issues with the protocol stack or implementation. They're not going to be doing deep packet inspection on the headers, mainly just rewrite them. So if there were overruns or other issues discovered, the SIP proxy or SBC is not going protect you.

    And the marketing of such devices seem to be as a magical bandaid, much like firewalls. And they're priced accordingly, in the hundreds of thousands of dollars.
    • ^
    • v
    I just want to say: Hooray! The blog is back.
    • ^
    • v
    Well I think it's great that you're working on VoIP. Just don't go reading my voicemail!

    In any case, great to have Matasano back, although I hate this commenting system and the new look and feel. Posting comments off-site to disqus forums is creeping me out. And the flash is double-creeping me out. Kthx.

    I'm curious if there are any libraries or component frameworks out there to help VoIP implementers. I know you speak of Wireshark as a guideline, but I was thinking of something more commercial, such as Coverity Extend (particularly for embedded devices). Or maybe something in between. I guess asterisk with PaX/GRSec wouldn't be a poor implementation choice, but I'm looking for something with a bit more assurance.
    • ^
    • v
    You're safe from me listening to your voicemail -- not like I can do so without jumping through some pretty serious hoops!

    Good question. My slant on things has mainly been from the perspective of attacking existing VoIP implementations. Apparently there are VoIP implementations out there, such as Trolltech's Qtopia -- http://osdir.com/Article7982.phtml -- but I can't attest to their security, as I've never looked at this particular implementation.

    Most of the freely available implementations are oriented towards being a client, rather than being a VoIP switch and router. Perhaps there's a market here!
    • ^
    • v
    Hear hear, welcome back from the hiatus. You’ve been missed!

Trackbacks

close Reblog this comment
Powered by Disqus · Learn more
blog comments powered by Disqus