August 15, 2008, 7:14 AM — I am curious how people can conduct penetration tests of a complex VoIP system when they barely understand how VoIP infrastructure works. Today, security people are still stuck to auditing practices from 1990s. When asked to do a penetration test, a consultant often is only looking at past issues that can be detected using various vulnerability scanners. Very few of them know that vulnerability scanners have extremely bad coverage of vulnerabilities in VoIP solutions. And even if the tools did know VoIP, who really cares about past issues that might have been relevant several years ago.
Relying on vulnerability scanners and detection of past flaws is not very professional, but it is understandable practice when you study the skill-sets of individual consultants conducting penetration testing. Although nowadays every security consultant can do a web audit (some of them can even read HTTP), very few of them can even name the different network components used in a VoIP infrastructure ("What is this MGW here?"). Most security consultants have no idea what a widely used signaling protocol such as SIP (Session Initiation Protocol) can do. Even less people are aware of the encryption techniques available for both VoIP signaling and media, nor would they pay any attention on the lack of encryption in your VoIP.
When entering the VoIP auditing practice, the first target for all security experts is to understand VoIP. Maybe you have been postponing this because VoIP sounds complex? Fortunately VoIP is so much fun to learn! VoIP is such a perfect example of deployment where you need to know all the basics of communication technologies including all security techniques. VoIP does not re-invent the wheel, but reuses all best practices from both IP communications and legacy telephony. But where to start?
That is what we tried to do in the book I wrote with Peter: A complete analysis of various security aspects of VoIP. The feat was not easy, especially given the limited time we had for the project. In order to teach future academics and network engineers, Peter and I tried to systematically go through the security risks and vulnerabilities associated with VoIP networks and offer proven, detailed recommendations for securing them. Even when drafting those chapters, we noted that it is not enough to just list exploits and security techniques, but instead we had to explain at least the basics of the actual techniques that make VoIP work. You cannot secure something that you do not really understand.
Reactive versus proactive
But then what? Now you know your VoIP, but are still trapped to using reactive tools such as Nessus. Security testing needs to be more proactive. What is the difference?
A reactive security testing tool is based on past data on vulnerabilities. As hackers and security consultants find and disclose flaws, the tool vendors add these hostile tests, or even worse just fingerprints of the attacks or vulnerabilities into their products. The tool "reacts" to a third-party discovery. That means the tool can detect known mistakes in widely used legacy products. Sometimes the result often is that the testing solution only detects flaws in a limited number of products. If one SIP product has an overflow in a specific header, the same test can potentially miss the exactly same flaw in an another product. This is because some of these tools only do "header grabbing", i.e. they check what product version is actually being tested, and do the verdicts based on that data only.
A proactive tool on the other hand will always have a range of tests for each vulnerability. Let's look at a simple example:
INVITE sip:target@foobar SIP/2.0
To: "target" <sip:target@foobar>
From: "source" <sip:source@foobar>;tag=00001470
Via: SIP/2.0/TCP 10.10.2.54:57878;branch=z9hG4bK1470t1209536613507
Call-ID: s0c00001470i0t1209536613507@10.10.2.54
Contact: "source" <sip:source@10.10.2.54;transport=tcp>
Content-Length: 179
Content-Type: application/sdp
CSeq: 1 INVITE
Max-Forwards: 70
aaaaaaaaaaaaa-VERY-LONG-OVERFLOW-aaaaaaaaaaaaa
v=0
o=source 1 1 IN IP4 10.10.2.54
s=Codenomicon SIP UAS Test Tool 3.2 (http://www.codenomicon.com/)
c=IN IP4 10.10.2.54
t=0 0
m=audio 49158 RTP/AVP 0
a=rtpmap:0 PCMU/8000
(Note that this test might or might not be crippled, or even imaginary, as I also could have imagined the crash. And no, we are not going to report the flaw, even if it is true. What product? I forgot its name.)
Although exactly the same test broke tens and tens of VoIP products in 2002, this test will still find a flaw that is not discovered by any vulnerability scanners. This test has been included in all fuzzing tools since PROTOS SIP test-suite release in early 2002 (some of you might notice why PROTOS is not enough to catch this flaw though). This test still crashes commercially available VoIP products, when varying length strings are used. A single test case for such a vulnerability would never catch all these problems though. A range of carefully designed tests is needed.
While developing our fuzzers, we have noticed that we have covered about 70-80% of all known vulnerabilities reported by various parties in different communication products. Does this sound like a bad score? Maybe so (it is still best in the fuzzing industry!). But if you think that all these problems were covered much much earlier than they were ever reported publicly? Our commercial security testing tool, when released in 2002, could already then find 70-80% of all SIP vulnerabilities found afterwards. That sounds completely different doesn't it! That is what proactive security test is about. Detecting the flaw(s) before anyone knows about it.
