VoIP security auditing is becoming more and more complex ... Not!
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.
Build your tech library with our book giveaways.
Hacking Exposed, Sixth Edition
By Stuart McClure, Joel Scambray, George Kurtz; Published by McGraw-Hill/Osborne
The original Hacking Exposed authors rejoin forces on this tenth anniversary edition to offer completely up-to-date coverage of today's most devastating hacks and how to prevent them. Using their proven methodology, the authors reveal how to locate and patch system vulnerabilities. The book includes new coverage of ISO images, wireless and RFID attacks, Web 2.0 vulnerabilities, anonymous hacking tools, Ubuntu, Windows Server 2008, mobile devices, and more. Enter now!
If someone is selling you a
If someone is selling you a penetration test, and then running a vulnerability scanner and handing you a report, you're not getting what you paid for, period.Penetration Test != Audit != Assessment
Back around the turn of the century when I built a small security consulting firm in Texas, we had to explain the difference to customers on most occasions and watch their faces as they realized they hadn't been getting what they were paying for from other firms. You touch on some of the differentiating points in your article, however the differences can be summed up even more precisely:
A Penetration Test is generally exactly that. The target is attacked as a real attacker would; the approach is more stealthy, profiling is done to identify weak targets, those targets are enumerated and surgically attacked until one or more are successfully compromised, then the test is over. Penetration tests are generally limited in scope and comprehensiveness by nature, and on many occasions produce new, undisclosed vulnerabilities in the systems and software the customer employs. Penetration tests by far require the most skill of the three types I'm outlining. The differentiators here are the VARIABLE SCOPE and LENGTH of the test via selective targeting and the end of the test once the goal is reached; successful compromise.
An Audit is generally a test for some form of compliance. The scope is defined exactly by whatever documentation outlines the requirements for compliance. This can be anything from the size of HIPAA to a simple checklist of specific vulnerabilities. If all the requirements are met, the target is compliant and has passed the audit. The differentiation here is that you have something to audit the target AGAINST.
An Assessment is what you get from stock tools like vulnerability scanners, custom tools to identify vulnerabilities, and nice pretty reporting software to tie all the results together and provide mitigation and remediation guidance. Assessments are essentially a test of the target for, and this is the important differentiation, KNOWN vulnerabilities.
My firm was happy to provide all three, given that the customer understood what they were getting when they asked for one or the other.
Thank you for the
Thank you for the definitions for each of these. Unfortunately still today, there are as many definitions as there are security consultants. As my background is in fuzzing, I do not really agree with these definitions. If we do an assessment, we run tools (our own fuzzers, and other available fuzzers and non-fuzzers from other companies) to mostly find unknown vulnerabilities. We can find known issues also, but that is not the purpose of the assessment. This in most cases is an "audit" (or assessment, or test, or review) against a carefully designed test specification, sometimes dictated by the industry and in almost every case pre-run in similar form by an another party. Often this is part of a certification process. And yes, the tools are very similar to what a hacker would use in what you call "penetration test".