VoIP security testing fundamentals

Testing your VoIP security system against all the threats that exist on the network can be a full time job. This guide documents how a VoIP system can be tested and suggest some of the available tools to use -- with a focus on fuzzing tools and methods.

Can VoIP security be tested using fuzzing?

Voice over IP security is a popular topic lately, and there is good reason for concern. VoIP is becoming more and more popular and the more widely used it becomes, the more of a target it will be to those interested in wrongdoing.

There are many attack vectors when it comes to VoIP. It relies on the IP infrastructure so any attack that targets a network can be a potential hazard for VoIP. There is concern regarding VoIP components like the OS a soft-phone is running on or the firmware of a device. There are configuration concerns like devices with exposed TCP and UDP ports. There are the aforementioned IP infrastructure attacks in the form of DoS attacks or SYN flooding. Eventually, no matter what the specific attack, there is a good chance that the attacker is exploiting a weakness in the VoIP protocol that is being used.

The two most popular protocols are SIP and H.323. Each of these has their pluses and minuses in terms of security and overall effectiveness.

First let's take a look at SIP. SIP is easier to use since it uses textual encoding like HTTP. It's extensible and it can be paired with other protocols. As far as security goes, textual coding makes debugging easier, but it also makes spoofing easier. Since it is a relatively simple protocol, there is less chance of coding errors. Its open nature does create some concern, as easily integrated and extensible protocols can have more implementation errors.

What about H.323? H.323 uses a binary encoding, which makes it difficult to debug and subject to buffer overflow attacks. Its complexity can also lead to implementation errors. It is not very extensible which actually helps the security-wise and it has a monolithic architecture, which means it does not need to borrow functionality from other protocols.

As you can see, each protocol has its pros and cons. Regardless of the protocol your VoIP implementation is using there are some ways you can test the security of these protocols.

One way to test your implementation protocols is with fuzzing. Fuzzing, or functional protocol testing, is a good way to find bugs and vulnerabilities. Fuzzing works by creating different packets for a given protocol and injecting the packets with data that will test the limits of the protocol. The packets are sent to a device, app or OS and the results are observed.

The PROTOS group at the University of Oulu in Finland is responsible for identifying a number of protocol weaknesses. They've published papers that describe methods for testing SIP and H.323.

The more widespread VoIP becomes the more it will come under attack. By taking some initiative now and testing your VoIP implementation, you might be able to prevent a failure in the future.

Are there free fuzzing tools to test VoIP security?

Fuzzing is a form of stress testing using malformed packets. Fuzzing is also known as functional protocol testing or robustness testing. It is usually used to automate vulnerability discovery. It finds bugs and vulnerabilities by producing different packet types that target a protocol. The fuzzing attack pushes the protocol's design specifications to the breaking point. It is often used by developers and vendor internal QA groups to test their protocol implementations.

It is dangerous to assume that the protocol implementations produced by a vendor are all identical. The protocol software can vary by software release and version. Chapter 11 of "Hacking VoIP Exposed," www.hackingvoip.com, provides a more in-depth discussion of the technique.

The electrical engineering department at Finland's University of Oulu has been working on VoIP security issues and has a good site to access. This site deals with specific signalling protocol attacks. Another resource is a long presentation by Hendrik Scholz, "SIP Stack Fingerprinting and Stack Difference Attacks," which was given at the 2006 Black Hat conference. This security conference now has a separate track discussing VoIP security.

Any tools that attack an enterprise's security will of course cause damage to the operation of VoIP if they are used improperly. The links listed below usually have instructions covering the proper use of the tool, but even following the instructions may not eliminate damage.

This list contains free and commercial tools. There are many other free and commercial tools that are used by developers that can also be used to attack VoIP components. This tool list is not exhaustive; other free and commercial tools are available. The primary source for the tool list is www.voipsa.org from the VoIP Security Alliance. The tools in this tip deal only with fuzzing attacks.

Can VoIP security be tested by attacking the system?

This tip covers tools that can be used to create packet flooding and signalling manipulation.

Packet flooding can cause various forms of Denial of Service (DoS) -- the endpoints don't work, the network is overloaded, phones are disconnected and other malicious acts occur. Signalling manipulation can cause calls to be directed to other locations, add a second listener to the call, create a rogue call manager and force phones to reboot. Another good presentation on VoIP attacks is VoIP Attacks! by Dustin Trammell presented at ToorCon 2006.

How to use this information (disclaimer)

Any tools that attack an enterprise's security will probably cause damage to the operation of VoIP if the tools are used improperly. The links listed below usually have instructions covering the proper use of the tool. Even following the instructions may not eliminate damage or harm. The links are to other sites and are not part of TechTarget ANZ, so there is no guarantee that everything will work as expected. The links are for information purposes only.

Now that the disclaimer is out of the way, this list contains free tools. There are many other free and commercial tools on the market that are used by developers that also can be used to attack VoIP components. This tool list is not exhaustive. The primary source for the tool list is VoIPSA from the VoIP Security Alliance. Several of these tools were developed by David Endler and Mark Collier, the authors of Hacking VoIP Exposed.

There are also scanning, enumeration and miscellaneous tools as well as commercial development tools that are available. As VoIP becomes more pervasive and the number of individuals using VoIP increases, so will the attack tools. Keep checking the sites mentioned in these tips for further additions to the attack tools list.

How can fuzzing be used to deter VoIP protocol attacks?

Researchers at the University of Oulu discovered many of the known SIP and H.323 vulnerabilities using functional test methods to assess protocol implementation security. Functional protocol testing, also known as "black-box testing" or "fuzzing," sends many diverse input messages to a vendor's implementation, exercising error handling routines and generating conditions never anticipated by the protocol designers or software developers. Fuzzers systematically send test messages, randomly or sequentially, within the framework defined by a given protocol specification. The implementation undergoing testing is observed for buffer overflows, unhandled exceptions and unexpected behaviour.

To demonstrate the effectiveness of this methodology, the University of Oulu's PROTOS project developed functional test suites for several Internet protocols, including HTTP, LDAP, SNMP, SIP and H.225. The PROTOS Test-Suite: c07-sip exercises SIP proxy and user agent INVITE handling, using more than 4,500 test messages. The PROTOS Test-Suite: c07-h2250v4 tests devices that handle H.225.0/Q.931 Setup-PDU messages, including H.323 endpoint terminals and gateways, VoIP-aware firewalls and multi-point control units.

When these test suites ran against several representative SIP and H.323 implementations, product failure rates were alarming. Fortunately, many of these vendors used test results to correct identified vulnerabilities. Test case definitions and Java code for sending these test messages are available for downloading on the PROTOS project Web site, at no charge.

The PROTOS SIP and H.323 test suites clearly demonstrated the value of functional protocol testing, but they only scratched the surface of each protocol. Further testing of other VoIP protocol messages may uncover more vulnerabilities. Nonetheless, enterprises rolling out VoIP would be wise to take one of these PROTOS suites out for a test drive. Running functional tests against VoIP products under consideration or already installed in your company's network can identify vulnerabilities before attackers compromise them. The following are some key tactics for successfully testing products:

• Test all devices that send, receive or parse VoIP protocols, including handsets, softphones, SIP proxies, H.323 gateways, call managers and firewalls that VoIP messages pass through. Exercise care because some tests may result in DoS.
• When vulnerabilities are found, search CVE databases and apply any related patches, or report test results for unpatched problems to your vendor for remediation.
• Re-run tests to verify that applied patches have fixed identified vulnerabilities and have not created new vulnerabilities. Also re-run tests after installing software/firmware updates to VoIP products.
• Companies that already have a network security audit process may want to add VoIP functional tests to the list of penetration tests run during each audit.
• Enterprises with significant investment in (and dependence on) VoIP may want to create more extensive functional protocol test cases, using PROTOS test suites as a guide.

Testing alone cannot defeat all attacks against VoIP. How you choose to deploy, configure and use your VoIP products is equally important. However, tests like these can help you reduce the inherent risk posed by SIP and H.323 protocols.