VoIP security auditing is becoming more and more complex ... Not!

August 15, 2008 —

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.

VoIP Security Testing Tools

VoIP security testing is not only about fuzzing. Therefore, I will next give you a brief overview of different security auditing tool categories listed in the VOIPSA web pages ( http://www.voipsa.org/Resources/tools.php ). All these tools look at different aspect of security in VoIP. Some of them are really just proof-of-concept exploitation tools, only good for customer demonstrations where the seriousness of the issues needs to be explained.

VoIP Sniffing Tools are just that, network analyzers that understand VoIP protocols. The tools will discover use of bad password handling, providing you with pairs of user-names and passwords of VoIP users. Some of these tools will re-construct media streams into audio files, enabling you to easily eavesdrop the on-going calls. These are mainly useful only for demo purposes, as any VoIP aware security engineer will immediately catch the same weakness by just looking at the traffic captures.

VoIP Scanning and Enumeration Tools will scan a VoIP network detecting VoIP enabled devices, and sometimes automatically performing some simple attacks such as password brute-force attacks. Some of these tools will try to enumerate details of the found VoIP devices, including some known vulnerabilities based on the version details.

VoIP Packet Creation and Flooding Tools will send VoIP messages to the end-points either trying to cause a denial of service, or to just annoy the recipients of the messages. These can actually be a very good option to expensive stress-testing or performance testing frameworks. Some of these tools can help in crafting specific test cases or message sequences.

VoIP Fuzzing Tools will either automatically generate huge amount of tests to crash a VoIP device, or they can act as modeling frameworks that will let you design your own fuzzers for VoIP. An intelligent fuzzer will systematically go through all VoIP and IMS specifications, augmenting each protocol element with inputs that are known to cause problems. A random fuzzer will just mutate a captured VoIP stream, and with luck (a lot of it), breaking it in unexpected ways.

VoIP Signaling Manipulation Tools are simple tools that re-create common mistakes in message signaling. They typically either blindly inject brute-forced messages into existing calls, or based on captured VoIP traffic will send spoofed messages (impersonating either calling party) to reach the desired result. With these tools, calls can be redirected, disconnected, or the quality of the call can be impacted.

VoIP Media Manipulation Tools are similar as above, but target the media streams. Audio streams can be injected into existing calls. Media protocols can also be used to transfer files, or even provide shell access to the target system (the unauthorized stream would look like a valid VoIP call to anyone analyzing it).

Other tools in the Miscellaneous category include password brute-forcing tools, which try a range of passwords attempting to guess the correct password. In this category you can also find specific exploitation tools for some vulnerabilities, and tools that help you through questions and answers against a predefined security policy.

Word of warning

Building a VoIP penetration test around availability of tools only will limit the scope of the assessment. Although tools such as those listed above are easily available, the used tools need to be chosen based on the assignment, not the other way around. In the past, security assessment almost always required that the consultant built proprietary tools. Today you can find a range of tools for almost every need, and often you will also find commercial options for many of the open source proof-of-concept tools. Note that the tools will often blind you. Let's look at two examples.

A packet crafting tool can make it easy to create SIP message sequences, and enable you to change the packet structures in each message. Still, other protocols also need evaluation. A security assessment built around SIP mutations will leave a wide number of other protocols outside the scope. The tool should be used to make tests faster to create, not to limit the tests. Thorough analysis of the target system is always required, and even if you decide to focus in only one or two protocols with deeper analysis, you should let the customer know also what was not tested. This can actually give you new consulting opportunities for the future.

Both fuzzing tools and scanning tools are always snapshots in time. A tool that was developed years ago might not be the right choice for your current task. Understanding the limitations of the tools can help you pick the right tool for each task. A free tool such as PROTOS can be the right choice if the goal is to find one flaw as a proof-of-concept, whereas a commercial solution can provide much better test coverage, but with a price. Give the customer some choices, and let them decide what they really need, instead of getting stuck of using a standard toolkit for every assignment.

Complexity killed the consultant

Don't be scared of VoIP assessments. VoIP is really interesting and simple to understand. There is nothing complex in a carefully built VoIP infrastructure (well, IMS is a different story, I promise to talk about that later).

The know-how for VoIP security is easily available. There are several good books about VoIP security, written by numerous experts in both breaking the networks and securing them. I am a bit biased having authored one of them, but (if asked) I could do a quick analysis of the different books and their pros and cons later here in this blog.

The tools are there. VoIP security testing tools have been developed by both the security community and also by commercial security companies. And they are extremely easy to use. Again, if some of you so desire, I could do a more detailed analysis of one or two tool categories here later on.

VoIP security is both a business opportunity for consultancies, but also an enabling aspect that will speed up the adoption of VoIP. Without building security into the VoIP deployments, the end-users will stay away from the technology. We are still at a phase where we need to build customer confidence in VoIP.

VoIP solutions are really bad quality still. It is extremely easy to crash most VoIP solutions with even the simplest fuzzers. What does this tell you? It just means that some poor manufacturer STILL does not use any form of fuzzing in their quality assurance process. A simple flaw like the one shown above should be caught in all penetration testing assignments. We still need to educate the vendors in proactive security practices, and what is better way than arming their end-customers with information on the real reliability of the used devices.

Misc

Last time I checked at least 28 people had actually read my earlier blog entry, and actually liked it, which is amazing! Thank you for the feedback! You are also free to email me at my Codenomicon email address (ari.takanen@codenomicon.com), as I would look forward to receiving any questions or comments on VoIP security.

English is not my native language, so I apologize for any mistakes here and in future texts. I rather have these up here fast than tinker with the text indefinitely!

Enter to win a copy of Securing VoIP Networks: Threats, Vulnerabilities, and Countermeasures by Peter Thermos, Ari Takanen, Published Aug 1, 2007 by Addison-Wesley Professional.