Matasano
October 1st, 2008, 04:13
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.
<hr />
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.
<hr />
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 ("http://en.wikipedia.org/wiki/Session_Initiation_Protocol") is not the only lingua franca of VoIP. There is also the Media Gateway Control Protocol ("http://en.wikipedia.org/wiki/MGCP"), and Megaco ("http://en.wikipedia.org/wiki/Megaco"), usually used for PSTN ("http://en.wikipedia.org/wiki/Pstn") to IP or IP to IP networks. Also used on the client end are Nortel’s UNISTIM ("http://en.wikipedia.org/wiki/UNISTIM") and Cisco’s Skinny Client Control Protocol (SCCP) ("http://en.wikipedia.org/wiki/Skinny_Client_Control_Protocol").
Many of these protocols are derived from older digital switching stuff such as Signaling System 7 ("http://en.wikipedia.org/wiki/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.
<hr />
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:Â*
http://www.matasano.com/log/1117/the-wild-world-of-voip/
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.
<hr />
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.
<hr />
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 ("http://en.wikipedia.org/wiki/Session_Initiation_Protocol") is not the only lingua franca of VoIP. There is also the Media Gateway Control Protocol ("http://en.wikipedia.org/wiki/MGCP"), and Megaco ("http://en.wikipedia.org/wiki/Megaco"), usually used for PSTN ("http://en.wikipedia.org/wiki/Pstn") to IP or IP to IP networks. Also used on the client end are Nortel’s UNISTIM ("http://en.wikipedia.org/wiki/UNISTIM") and Cisco’s Skinny Client Control Protocol (SCCP) ("http://en.wikipedia.org/wiki/Skinny_Client_Control_Protocol").
Many of these protocols are derived from older digital switching stuff such as Signaling System 7 ("http://en.wikipedia.org/wiki/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.
<hr />
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?
http://www.matasano.com/log/1117/the-wild-world-of-voip/
