Praise for Hacking Exposed: Unified communications & VoIP Security Secrets & Solutions, Second Edition (2014)

PART IV. UC SESSION AND APPLICATION HACKING

Case Study: An Attack Against Central SIP

ABC Company is a medium-sized retail business with about 10,000 employees in 500 retail locations across Texas. Although their business is good, it is highly seasonal, with most of the revenue generated during the holidays. They have been a big user of UC for many years, with legacy trunking at each retail site. As part of their continued deployment of UC, ABC Company outsourced the UC administration and let go a number of their network engineers. John Smith was one of the casualties of this outsourcing effort.

Right before John Smith was let go, ABC Company decided to migrate to SIP and centralize all their trunking into two data centers. They did some traffic studies for their retail and administrative sites and decided that their total peak traffic would not exceed 2,000 total sessions, load balanced across the two data centers (1,000 sessions each). They built in some resiliency, such that if one data center failed, all traffic would fail over to the other data center. Some of the network engineers were a little uncomfortable with only 2,000 total sessions, but because their traffic was so seasonal they hated to pay for more, especially because most of it wouldn’t be used throughout the year.

ABC considered multiple service providers, but decided on a Tier 2 vendor, XYZ service provider, with an all-SIP network. XYZ service provider was much less expensive than the Tier 1 providers. They touted an all-SIP network as a big differentiator. ABC Company briefly considered using multiple service providers, but again did not want to incur the expense, which would be wasted for 90 percent of the year. ABC Company decided to make the transition to this new service over the summer, test it for several months, and then have it ready to go in full production for the upcoming busy holiday season. At that time, the deployment was working well, with no major issues.

Meanwhile, John Smith was plotting his revenge. He was very familiar with ABC Company’s network design and their cost-conscious decisions. John was also aware that if he could disrupt the new central SIP architecture, he would affect the entire business, rather than just a specific retail site or two. A well-designed and timed DoS attack could totally disrupt ABC’s entire business. It was perfect.

XYZ service provider is all SIP and has significant points of presence on the Internet. John Smith realized that he could probably generate SIP fuzzing and flood attacks into their network anonymously from the Internet. It took him a while—lots of googling and asking questions on hacker forums—but he found the IP addresses of two of XYZ service provider’s SIP proxies. He then used SIPVicious to probe these proxies and found only basic authentication, which he was easily able to crack. He tried a few fuzzing attacks, but did not have much luck. He moved on to trying some INVITE flooding attacks. He found some of the DIDs from a local retail site and sent some INVITES into the XYZ service provider’s network from another retail site with public Wi-Fi. While he was doing this, he tried to make some normal calls to the same numbers and received busy signals. This convinced him that if he amped up the attack and targeted all the retail sites, he could create a major disruption. He spent a few hours Google hacking to find public numbers for 50 of ABC Company’s retail sites. He didn’t need all of them, because he knew that the design would allow multiple simultaneous calls into each site.

John tweaked a version of the inviteflood tool to randomize traffic a little more and generate spoofed “local” source numbers for each targeted site. He knew that ABC Company would be very busy during the holidays. He found several large malls in town with multiple public Wi-Fi hotspots and plenty of bandwidth.

John waited until Black Friday, right after Thanksgiving. ABC Company was running a huge promotion and was expecting a lot of business and calls. Unfortunately for them, on Friday morning, John launched his attack. He ran several copies of the inviteflood tool, repeatedly in scripts, which flooded XYZ service provider’s SIP proxies, and in turn about 50 of the ABC Company’s retail sites. Because ABC Company already had a lot of traffic, the extra traffic totally saturated their trunks and crowded out its share of legitimate traffic. As the attack progressed, the impact had a cascading effect as more potential customers tried calling the retail sites. John was careful and randomized his attack through 10 separate public Wi-Fi hotspots. Just as the XYZ service provider would try to shut down the traffic, John would move on.

ABC Company had a Session Border Controller (SBC) and did their best to shed the illegitimate traffic, but it was coming in so fast and crowding out legitimate calls. ABC Company tried shutting down one data center, but that didn’t help, because all the traffic went to one site. John continued the attack all day. The damage to ABC Company was significant. What was normally a very profitable day, accounting for 10–15 percent of sales for the entire holiday season, turned out to be a disaster. The denial of service attack prevented customers from calling the retail sites to do business, frustrating them into taking their business elsewhere.

CHAPTER 14. FUZZING, FLOODING, AND DISRUPTION OF SERVICE

There are a handful of very bright 13-year-olds out there who can do remarkable things, and there are not-so-bright 13-year-olds who have access to software designed by others to detect and explore security vulnerabilities.

—Steven Aftergood

Computers are vulnerable. Although this is by no means revelatory information, it should be obvious that any system connected to a network is a target and vulnerable to disruption of service. Whether it is a denial of service attack against an organization with a packet flood or a single packet specifically crafted to bring down a vulnerable host, the ways in which an attacker can disrupt your network are numerous. This vulnerable state is compounded for a UC system by its need to maintain a high state of availability to process calls, making the system an attractive target for attackers. This chapter focuses on the disruption of service from flooding and fuzzing. We will begin with an update for SIP and then discuss fuzzing and flooding.

Access to SIP and RTP

We have been covering SIP throughout this book. Although any signaling protocol can be fuzzed and flooded, we focus primarily on SIP because of its ubiquitous nature and the availability of attack tools. We introduced SIP and SIP trunking in Chapter 1 and then covered ways to find and identify SIP endpoints in Chapters 2–4. We covered how SIP is used to spoof calling numbers and generate inbound attack calls in Chapters 5–9. We covered various ways to eavesdrop, attack infrastructure, perform MITM attacks, and attack specific UC systems in Chapters 10–13. The application-level interception attacks were based on SIP. Chapters 14–16 largely cover how to attack SIP directly. We also cover attacks against RTP, many of which work regardless of which signaling protocol is used (although we primarily show them along with SIP for signaling).

SIP is very common in enterprise UC, and although not every UC deployment uses it, its use continues to grow. The major UC vendors are starting to use it as an alternative to their proprietary protocols. Major UC vendors such as Microsoft use it exclusively. SIP is commonly used for handset, softphone, messaging, and intercomponent communications, which means there are plenty of targets. As is the case for most of the attacks covered in Chapters 10–13, most of these targets are only accessible if you are on the internal network. Access can also be obtained physically, through unsecure Wi-Fi, as a result of a user downloading a worm or virus, and so on. An attacker with internal network access will encounter little resistance to the generation of fuzzed packets or floods and audio manipulation.

SIP is also being used more and more to connect to the Public Voice Network through SIP trunking. Enterprises are rapidly replacing legacy TDM (PRI, T1 CAS, and analog) trunking with SIP. In some cases, this is a one-to-one replacement, but in many others, enterprises are consolidating their trunking into a fewer number of sites with centralized SIP. The idea here is to bring all the traffic from the Public Voice Network into one of several locations, into large IP PBXs or a session manager, and then route the traffic around the internal network. There are many advantages to this architecture, but it does create a chokepoint that is an attractive target. External attackers with their own SIP access may be able to transmit a fuzzed packet or floods across the network and affect a target at an enterprise using SIP trunks. However, this is fairly difficult in practice. First, the Public Voice Network still has a large amount of TDM, so any protocol conversion will eliminate the attack before it reaches the enterprise. Even if the path from the attacker to the enterprise is all SIP, the fuzzed packet or floods will have to go through multiple Session Border Controllers (SBCs), which are likely to mitigate the attack or, worst case, be affected themselves before the attack reaches the enterprise.

As more and more SIP is exchanged over the Internet, the transmission path will be all IP, with fewer intermediary SIP systems, such as SBCs, so it is more likely that fuzzed packets and floods will reach their intended target.

In any case, RTP-based attacks will have a better chance of reaching their target because fewer systems will be manipulating the packets, other than conversions to TDM or operations such as transcoding.

What Is Fuzzing?

It’s no surprise that vendors have security bugs in their products. This is because it’s highly unlikely a vendor can find every security flaw before a product ships. Often, a third party such as an end user or security enthusiast uncovers these flaws. This is often acknowledged in security advisories such as those at the websites for Cisco, Microsoft, and SecurityFocus.¹^,²^,³

A popular method for discovering vulnerabilities is through black box testing—that is, when a tester has neither inside knowledge nor source code to the targeted device or application, which essentially becomes a virtual black box. Aside from reverse engineering the application itself, black box testing is usually the easiest approach for uncovering security issues. Some of those security issues may result in the application or device crashing and causing a disruption of service; others may give an attacker control of the victim application. This type of testing is called fuzzing.

The practice of fuzzing has been around since 1989. It has proven itself to be effective at automating vulnerability discovery in applications and devices that support a target protocol. You can use fuzzing to find bugs and vulnerabilities by creating different types of packets for the target protocol that push the protocol’s specifications to the breaking point. These crafted packets are then sent to an application, operating system, or hardware device, and the results are closely monitored for any abnormal conditions such as a crash condition or excess resource consumption.

Monitoring for abnormal conditions while you’re fuzzing can be tricky. This depends on what you’re testing, such as a UC software application or a UC hard phone. Sometimes simply looking at the application’s or device’s logs is sufficient to determine a system failure. Other times, a system failure might be harder to detect—for example, fuzzing a device into a state where the failure isn’t obvious, such as if a process is hung but hasn’t completely crashed.

The PROTOS project of Oulu University’s Secure Programming Group⁴ remains one of the most well-known free UC fuzzing tools. PROTOS was released in 2002, and many people are still using it today, even though it hasn’t been updated since 2003. Some PROTOS project alumni started Codenomicon Defensics,⁵ which develops many different commercial fuzzing tools, including one for UC.

UC continues to be an interesting target for security researchers as the technology becomes more widespread and popular among consumer and enterprise customers. Although it would be ideal if all UC vendors tested their own products internally for security bugs, the reality is that not all of them have the time, resources, or ability to find all bugs ahead of time.

Vulnerabilities 101

Before diving into fuzzing, let’s discuss a few of the popular classes of vulnerabilities that fuzzing tools attempt to uncover. This is by no means an exhaustive list; we recommend looking at Mitre’s Common Weakness Enumeration (CWE) project for a more comprehensive set of vulnerability types.⁶

Buffer Overflows

The classic buffer overflow (or buffer overrun) is still one of the most common types of vulnerabilities discovered today. Quite simply, a buffer overflow occurs when a program or process tries to store more data in a memory location than it has room for, resulting in adjacent memory locations being overwritten. The results can vary from the program or process crashing, to an attacker being able to run arbitrary code within the context of the victim program.

Buffer overflows are usually the result of a developer not performing sufficient bounds checking on user-supplied input. Programming languages such as C and C++ do not have built-in bounds checking routines, making them susceptible to these vulnerabilities.⁷^,⁸ Programming languages such as Java are much less susceptible (arguably immune) to these sorts of issues.

Format String Vulnerability

To understand format string vulnerabilities, some background information of the C programming language is required. In C, format strings are used with certain functions to specify how data is to be displayed or input. These functions include fprintf, printf, sprintf, snprintf, vfprintf,vprintf, scanf, and syslog—to name just a few.

A format string vulnerability can occur, for instance, when a developer wants to print a string derived from user-supplied input and mistakenly uses printf (emailaddress) instead of printf ("%s", emailaddress). In the first case, an attacker might insert special format string characters into the emailaddress field of a web input form in order to crash the service (for example, emailaddress="%s%s%s%s%s%s"). Similar to buffer overflows, exploiting format string vulnerabilities can lead to a program or process crashing or to an attacker being able to run arbitrary code within the context of the victim program. For more detailed information on format string vulnerabilities, check out the following articles on this topic:

• “Exploiting Format String Vulnerabilities”⁹

• “Format String Attack”¹⁰

• “Format String Problem”¹¹

Integer Overflow

An integer overflow occurs when an integer is placed into a dynamically allocated memory location that is far too small to store it. This could occur when two integers are added together or when a user-supplied integer leads to the overflow. Depending on the particular compiler used for the program, integer overflows can lead to buffer overflow vulnerabilities being introduced into the software that can be easily exploited.¹²^,¹³

Endless Loops and Logic Errors

Many denial of service (DoS) vulnerabilities are the result of malformed input being supplied to the target application. The impact of the malformed or unexpected input may trigger a logic error in the developer’s code that can lead to memory leaks, high CPU consumption, and outright crashing on the program or process.

Other Vulnerabilities

The few vulnerability types we have covered so far only scratch the surface. Some other types of vulnerabilities cannot be easily discovered through fuzzing techniques, but require more human interaction and advanced testing tools customized to the target application. These include configuration errors, design flaws, race conditions, access validation flaws, and information leaks—to name just a few.

Who’s Fuzzing?

Numerous people and organizations have a vested interest in fuzzing UC applications. After crashing applications with fuzzing, any discovered crashes now require further investigation to determine if they could actually lead to exploits. This type of exercise is outside the scope of the book; however, several books can provide further insight. Quite a few books can be found on fuzzing in general, including Fuzzing for Software Security Testing and Quality Assurance¹⁴ by Ari Takanen, one of the authors of the PROTOS suite and the CTO at Codenomicon Defensics, and Jared DeMott and Charlie Miller. Also check out the book Fuzzing by Michael Sutton, Adam Greene, and Pedram Amini.¹⁵

We have divided groups interested in fuzzing into three main categories: UC vendors, in-house corporate security teams, and security researchers.

UC Vendors: Internal Quality Assurance

As security becomes more of a differentiator in the UC marketplace, it is in the vendor’s best interest to test the security and robustness of their applications proactively, rather than deal with the embarrassment of a public security hole in their products. While security vulnerabilities in software applications and operating systems have been increasing, the impact of such flaws, in terms of bad publicity, support calls, and the erosion of customer confidence, has increased too. Because of these increases, vendors are acutely aware of the benefits of developing secure software and platforms. Unfortunately, the core competency of most software and device vendors has been in product development and not security, and despite vendors’ best efforts, products released to customers are often found to have vulnerabilities after deployment.

In-house Corporate Security Teams

Companies with a mature security process strive to be proactive in their efforts to reduce vulnerabilities and minimize the risk of successful compromises. Increasingly, enterprises, large corporations, and service providers are beginning to perform vulnerability assessments on any large-scale technologies they are considering installing within their organization.

Many times, the corporate security team will be charged with “shaking the tree” to find any easily exploitable security problems with potentially deployed UC applications. The problems need not be severe code execution vulnerabilities; even simple denial of service issues can easily disrupt the availability of these applications. Some larger corporations will actually leverage their buying power to force the vendor to fix any issues found in this discovery process before making a purchase. In some cases, a product with numerous security issues might be rejected in favor of another product with fewer features but more security.

Security Researchers

No one can deny the number of capable security researchers as well as the advancement of publicly available security researching tools. Many of these researchers are gainfully employed by security vendors or information security consulting firms, whereas others are independent or self-styled hobbyists who enjoy picking apart software for its own sake. Regardless of the particular motivations, more and more security holes are discovered today by third parties rather than the affected vendor.

SIP Fuzzing Attacks

The goal of fuzzing is to discover as many potential bugs and vulnerabilities as possible in a target application. To comprehensively test every single possible input combination for a specific protocol would take decades and would duplicate a lot of effort with similar test cases. Instead, the key to efficient fuzzing involves creating representative instead of all-inclusive tests.

Let’s walk through a fuzzing exercise against the SIP CounterPath X-Lite SIP softphone (www.counterpath.com/eyebeam.html) using the VoIPER (http://sourceforge.net/projects/voiper/) fuzzing tool. VoIPER is Python based and has several types of fuzzers and other tests, including the SIP RFC 4475 torture tests, with each testing feature having multiple command-line options. VoIPER also has a GUI, shown in Figure 14-1, but we will use the command line. We are going to use the fuzzer.py tool that has the following options:

Figure 14-1 VoIPER GUI

The target for this fuzzing exercise is an X-Lite softphone. The specific SIP URI of our softphone is sip:2001@10.1.13.110. Before we begin, we need to know the listening UDP port for the softphone so we can target it correctly. One way to do this is by sniffing the traffic between the softphone and the proxy server, as seen in this REGISTER message:

As you can see, the softphone is using UDP port 60326 to communicate with the Kamailio proxy server. This port is randomized each time the X-Lite phone is launched. Now that we know the port, we can begin fuzzing. The VoIPER tool can generate up to 55,985 test cases just for the SIPInviteCommon fuzzer we will use. The command-line arguments are listed here, followed by a portion of VoIPER’s output while the test is in progress:

The VoIPER tool sends OPTIONS messages after each INVITE test case to make sure the targeted host is up and capable of responding to SIP traffic. Because these tests take hours or even days to complete, we chose to log all of the potential crash events using the c 1 command-line option into the test1 directory so we can examine the results when the testing is complete.

You will notice in a portion of our sample output that one potential crash, 1_50. crashlog, was created. To test this potential crash and any others that were generated, we have the crash_replay.py tool, which can replay all of the cases in a designated directory or a specific case that may have caused the fuzzed application to crash. This tool is executed with the following options:

In our fuzzing example, we ran through all of the test cases, but didn’t crash the X-Lite application. If we were able to crash the application, we could replay any of the generated crashlogs with the crash_reply.py tool. With this tool, we can replay the entire contents of the test1 folder to see if the application crashes again ensuring the fuzzer found a defect, we can test each generated crashlog file individually to determine which case may have crashed the targeted application, or we can do both. During previous testing cycles, we have tested all of the cases together to see if there was actually a crash generated and then tested each individually to find the specific case.

If you don’t want to use PROTOS or VoIPER, many more UC fuzzing tools are available, including SIPFuzzer, Asteroid, Interstate, Kif, and Snooze—just to name a few. There is also a tool in development called viproy, which is creating its own fuzz library and can be used in conjunction with other UC fuzzing tools.

Commercial Fuzzing Tools

The commercial fuzzing market has changed somewhat since the first edition of this book. Several vendors are no longer in business. Here are some of the remaining commercial offerings:

Choosing the right fuzzing tool can be complicated, but doesn’t have to be. Whereas many of the commercial tools can get rather pricy, some open-source alternatives may suit your purposes. Many commercial fuzzing tools provide support for protocols other than UC, but require you to license each suite for an additional price.

We compared the free PROTOS tool against the commercial Codenomicon tool. The PROTOS test tool has about 4,500 test cases and only includes INVITE message fuzzing. The Codenomicon SIP test tool has over 35,000 test cases and also covers OPTIONS and REGISTER messages, including a graphical frontend. Clearly they are not the same, but which fuzzer you use will be a function of your organization’s needs.

If you are in the market for a commercial fuzzer, you should try all of them against your target application to see which fuzzer achieves the most code coverage.

RTP Fuzzing Attacks

RTP fuzzing has the potential to be very disruptive because it is used in virtually all VoIP and UC systems. Although many different signaling protocols are used, RTP is used for virtually all audio (and video) today. RTP primarily carries simple values, including information in the RTP and audio (and video) values in the payload, depending on the codec being used. Fuzzed values can cause load sharp/disruptive sounds and possibly crash the software interpreting the values. However, to date there have been no reported real-world vulnerabilities reported.

An open-source inline RTP fuzzer is available called ohrwurm, created by Matthias Wenzel.¹⁶^,¹⁷ Because ohrwurm runs inline, a real-time conversation is necessary in order for it to work. This requires you to use the attacking computer running ohrwurm as a gateway and then to run arpspoof or some other man-in-the-middle tool discussed in Chapter 11 against each of the phones, such that all traffic is forwarded through the attacking computer. The RTP traffic flowing through the host running ohrwurm will be modified in real time and fuzzed before being sent to the receiving phone.

For example, if you wanted to fuzz the RTP communication between two phones in your network with the IP addresses 192.168.0.1 and 192.168.0.2, you would first run arpspoof twice in two different xterm sessions on your own computer:

Then on your box, you would start ohrwurm with the IP addresses of the two phones:

Note

We provide a more in-depth coverage of RTP attacks and manipulation in Chapter 16. We considered placing this section on RTP fuzzing in Chapter 16, but elected to leave it here with the other protocol fuzzing tools.

Fuzzing Countermeasures

You can employ the countermeasures addressed here to prevent an attacker from fuzzing your UC systems, especially those using SIP.

Use TCP for SIP Connections

To be compliant with RFC 3261, SIP proxies and SIP endpoints must support both UDP and TCP. When TCP is used, SIP endpoints generally establish persistent connections with each other. For example, SIP endpoints will establish persistent connections to the SIP proxy. Because of features inherent in TCP, such as the use of sequence numbers, it is more difficult for an attacker to inject a spoofed fuzzed message.

Note

Some attacks against TCP are still possible, as discussed in Chapter 11.

When TCP is used, it is also possible to use Transport Layer Security (TLS).¹⁸ TLS uses encryption to provide privacy and strong authentication and prevents attackers from injecting spoofed fuzzed messages. TLS is used to secure single connections between SIP proxies and SIP endpoints; however, TLS is not an end-to-end protocol. For a call to be secure, TLS must be used for all connections between SIP endpoints participating in the call.

Use VLANs to Separate Voice and Data

As we have discussed throughout the book, manufacturers recommend using VLANs to separate the voice and data traffic for UC deployments. Although VLANs will not prevent attacks, they will add another layer of security in a traditional defense-in-depth security model, as we discussed in Chapter 10. There are several ways to implement VLANs, including MAC filtering, configuring the switch ports to allow traffic to specific VLANs only, and 802.1x port authentication.

The use of softphones and UC messaging clients on PCs can also defeat the use of VLANs as a security measure. When a softphone is used, packets (presumably from the softphone) must be accepted by the SIP proxy, thus opening up the possibility that a rogue application can generate spoofed fuzzed messages.

Change Well-Known Ports

The SIP proxies allow the default SIP port of 5060 to be changed. Although this is a “security through obscurity” technique, it does provide some limited protection.

Use Session Border Controllers (SBCs) and SIP Firewalls

An SBC and/or SIP firewall can be deployed to inspect all signaling sent to the SIP proxy. The SIP firewall can detect various forms of attacks, including fuzzing. An SBC or SIP firewall is essential when connecting to a public network. SBCs and SIP firewalls are available from numerous vendors, including the following:

Some traditional firewalls, intrusion detection systems (IDS), and intrusion prevention systems (IPS) also support some basic detection of SIP attacks. Companies such as SecureLogix offer application-level firewalls and IPSs that support SIP. Some companies such as Redshift and VibeSec offer more general UC firewalls and IPSs that monitor for attacks on protocols other than SIP and RTP.

Other Individuals and Groups Performing Fuzzing

In addition to customers trying to protect their UC systems from fuzzing, other individuals and groups may use fuzzing techniques to test their or other UC products. Some of the individuals and groups, and how they might mitigate and/or report vulnerabilities, are described in this section.

Vendors and Developers If the bug was discovered internally as a part of normal QA or a security audit, the appropriate test case should be logged and documented so that the responsible developers can address the root cause of the flaw. All historical test cases should be retested through regression testing to ensure none of the flaws creep back into subsequent builds. If a bug is found in a released version of software, the issue should be disclosed and a patch provided as soon as possible (although vendors often don’t do this and hope no one identifies the same issue).

In-house Corporate Security Testers If you are a customer or potential customer of a product and you find a security flaw in it, the first thing you should do is share the information with your support or sales engineer. More and more vendors are starting to form assigned security response groups whose job is to receive these types of issues from the outside world. The response and receptiveness to your bug report will speak volumes as to the maturity of that vendor’s in-house security processes.

A good set of guidelines covering vulnerability disclosure is available from the Internet Corporation for Assigned Names and Numbers.¹⁹

Security Researchers and Enthusiasts For an independent bug hunter, there are currently no laws governing the disclosure of security issues. The disclosure debate has raged on for years as to whether it’s better to keep quiet about a security issue while the vendor fixes it or announce the security bug publicly to the world at the same time. Also, bug bounty programs such as through the Zero Day Initiative (http://www.zerodayinitiative.com) will pay for discoveries in a widely used product.

Flooding

In the previous section, we discussed a form of service disruption where fuzzed packets are used to disrupt SIP proxies and phones. In this section, we cover overwhelming SIP proxies and phones with a flood of various types of UC protocol and session-specific messages. These types of attacks can partially or even totally disrupt service for SIP devices such as phones, proxies, and other SIP systems while the attack is underway. Some of the attacks can even cause the targeted system to fail, requiring the application to be restarted. The attacks described in this section are simple to execute, in many cases lethal, and often quite fun.

Flood-based attacks are most effective when the target can be tricked into accepting and processing requests. If enough illicit requests are sent, valid requests from other SIP devices, such as SIP phones, may be lost, ignored, or processed very slowly, resulting in some level of service disruption. Figure 14-2 illustrates this sort of attack.

Figure 14-2 Flood-based disruption of service

SIP proxies, SIP phones, and other UC devices can use either UDP or TCP as transport for signaling, whereas UDP is used exclusively for RTP (audio/media). TCP offers more security than UDP does, but UDP is still widely used. Because UDP is a connectionless protocol and lacks sequence numbers or other means for identifying rogue traffic, it is much easier to generate packet floods using this protocol. Attackers can simply send a flood of packets to a target IP and port. An attacker may also need to spoof the source port, IP address, or MAC address to avoid detection, but this is trivial.

TCP is a connection-oriented protocol where, for example, SIP phones establish persistent connections with their SIP proxies. The packets exchanged as part of a TCP connection use sequence numbers and other means that make it more difficult to introduce rogue packets. It isn’t impossible, as we discussed in Chapter 11, but it is more difficult to generate effective packet floods using TCP.

The intent of the flooding section is to demonstrate some flooding attacks and how they can affect your UC network. This section describes various flood-based attacks you can perform against SIP proxies, SIP phones, and other devices and how making small changes to the command line can affect how effective each attack can be.

For our targeted systems, we used the same testbed as described for the application-level MITM attacks described in Chapter 11. This testbed includes Asterisk and Kamailio/OpenSER SIP proxies, each of which manage several SIP phones. Figure 14-3 illustrates the testbed.

Figure 14-3 SIP testbed

In each attack, we run a rogue application on an attacking system connected to the SIP test network and use it to target various devices. Figure 14-4 illustrates this basic setup.

Figure 14-4 Basic setup for fl ood-based attacks

The SIP proxy, call processor, or IP PBX is a key resource in a SIP-based system. The SIP proxy processes all requests between SIP endpoints, including SIP phones, media gateways, and other resources. If the service for the SIP proxy is affected, the entire voice network can be disrupted. Many of the attacks discussed here can prevent all or most of your users from making or receiving calls.

Another target on a UC network is the SIP phones. A typical SIP network will contain many SIP hard and softphones, perhaps from multiple vendors, although that is not often the case. SIP phones are vulnerable to a number of attacks, in some cases because of weak security, limited processing power, and lack of protection by dedicated security products.

These attacks can partially or fully disrupt operation of your SIP proxy, phones, and other systems, thus preventing users from placing or receiving phone calls reliably. This could affect your customer interaction lines, customer support lines, executive lines, and so forth. As you can see, these attacks can have a serious impact on your business. This is especially true considering that dropping even a few calls is unacceptable in most enterprises.

Target SIP Proxies with UDP Floods Using the udpflood Tool

As we’ve discussed, SIP endpoints can use either UDP or TCP for signaling. Although SIP requires support for TCP, UDP is still more commonly used, meaning UDP-based floods are possible against SIP endpoints. In the first edition of the book, we modified the udpflood tool developed by Robin Keir, available at our website www.voipsecurityblog.com. This is still a viable flooding tool, and the usage information for this tool is as follows:

We used udpflood to send 1,000,000 packets to the Asterisk and Kamailio SIP proxies. We also flooded the CUCME. Each flood attack took slightly less than two minutes to complete, meaning approximately 8,333 packets were put on the wire per second, each of which was 1,414 bytes long (this is the Ethernet frame size), for a total of approximately 12,000,000 bytes. The following commands were used to generate the packet floods:

and

We ran the first flood attack against our CUCME on a Cisco 2621XM router. This lab environment is the router depicted in Figure 3-1 in Chapter 3. After executing one flood against the CUCME, we were able to prevent calls between all of the phones during the attack. We executed the attack multiple times to reinforce our findings, and each time had the same results. The CUCME recovered when the attack was stopped.

Next, we ran the udpflood attack against our Asterisk server. During the attack, the Asterisk SIP proxy CPU was elevated, but still processed calls. Manual calls, at a rate of one per ten seconds, were completed with no failures. Active calls were not affected at all because the media flows from phone to phone. The Asterisk server recovered from the attack immediately, and we didn’t observe any lingering artifacts from the attack.

We ran the last udpflood proxy attack against the Kamailio server. The Kamailio SIP proxy CPU was only slightly elevated, but it was able to process calls reliably. Manual calls, at a rate of one per ten seconds, were completed with an occasional lag, but still completed. The Kamailio SIP proxy recovered from the attack immediately without any noticeable lingering effects.

To determine what it would take to affect the Asterisk and Kamailio servers, we increased the number of instances from one to four simultaneous identical attacks. Four simultaneous attacks were able to prevent calls from being processed on both of the servers until the attacks were stopped. Again, there were no lingering effects after the attacks were stopped.

We also used the udpflood tool to target other ports on the CUCME, Asterisk, and Kamailio SIP proxies. Floods directed at other well-known ports, such as 7 (echo), 9 (discard), and so on, had no effect on the SIP proxies. All calls were completed normally.

Target SIP Phones with UDP Floods Using the udpflood Tool

We can use udpflood to target SIP phones. Like the attacks on the SIP proxies, we sent 1,000,000 packets to the SIP phone using the udpflood tool. Running Wireshark on a system bridged between the Ethernet switch and the SIP phone showed that approximately 25 percent to 30 percent of the packets were received. The commands for these attacks used the following basic form:

During our experiments, we attacked the phone “on-hook” (indicating that the phone is waiting for a call) and “off-hook” (indicating that the phone has a call in progress). Here are the functions we examined during the testing:

• Interface Indicates whether the SIP phone user interface/buttons were usable

• Calls Out Indicates whether the SIP phone could make outbound calls

• Calls In Indicates whether the SIP phone could receive inbound calls

• Callee Media Indicates the quality of inbound media

• Caller Media Indicates the quality of outbound media

• Recover Indicates whether the SIP phone recovered after the attack was stopped

Table 14-1 summarizes the results for each SIP phone tested with on-hook and off-hook attacks.

Table 14-1 UDP Flood Attacks

As you can see, the udpflood attack is very effective against the SIP phones. The Cisco SIP phones are able to make and receive calls, but the media isn’t usable. The X-Lite phone is able to make and receive calls, and the media is present but is affected.

You can also target the media ports on SIP phones using udpflood. As you know, a call’s media is carried by the Real-Time Protocol (RTP) on either a static or dynamic port, depending on the phone. The SIP phones we tested allow you to configure a port or range of ports to use. The default ports for each SIP phone are as follows:

• Cisco 7940 and 7960 SIP phone The default port range is 16384 to 32766. For each call, the Cisco SIP phone uses a port number that is four greater than that used for the previous call.

• X-Lite phone This phone uses a dynamic port when it registers with the proxy, and you can determine the port number sniffing the SIP INVITE request and/or the SIP OK response.

The following Wireshark trace shows only the relevant portion of the SIP/SDP packets containing the media ports:

Determining the media ports can be tricky for some proxies that operate as B2BUAs, including Asterisk. In this case, media ports are established initially with each SIP phone and the SIP proxy/B2BUA and then changed so that the two SIP phones exchange media directly with each other.

When we identified the media ports on either or both SIP phones, we generated the flood. As with the other attacks targeting phones, the udpflood tool sent 1,000,000 packets directly to each SIP phone. Wireshark showed that approximately 25 percent to 30 percent of the packets were received by the targeted system. Each of the attack commands used the following basic form:

Target SIP Phones with the rtpflood Tool

The rtpflood tool was made by modifying the udpflood tool where it builds an RTP header with 160 bytes of payload on top of a UDP packet. The usage information for this tool is as follows:

To use the rtpflood tool effectively, you will need to be able to sniff the traffic between the two SIP endpoints to identify the ports on either or both SIP phones, the SSID, and the Sequence Number and Timestamp values. Although the SSID is static, the Sequence Number and Timestamp values will increment during the call and you will have to choose values. We sent 1,000,000 packets to each SIP phone directly using the rtpflood tool. The command for these rtpflood attacks used the following basic form:

Table 14-2 displays the results for each of the udpflood and rtpflood attacks against the media ports on the SIP phones. Like the flood attacks targeting signaling ports, these attacks are also effective against the targeted SIP phones. The Cisco SIP phones are able to transmit media but not reliably receive it in both cases, and the X-Lite SIP phone is able to process inbound and outbound media, but the quality of the inbound media is poor.

Table 14-2 rtpflood Attacks

The results are almost identical for the most part between the two attacks against the media ports on the phones. These results hopefully show that some flooding tools may have either wildly different or identical results. You won’t know how the targeted systems are going to behave against specific attacks until you try them. Now let’s look at the inviteflood tool and see how it will affect our targeted systems.

Target SIP Proxies with INVITE Floods Using the inviteflood Tool

The INVITE request is used to initiate calls in SIP communications. The INVITE request is key because it initiates call processing within the SIP proxy or phone. When SIP systems are tricked into accepting a flood of INVITE requests, a partial or full disruption of service can occur. As discussed, most SIP networks use UDP, which simplifies an attacker’s ability to flood a SIP proxy or phone. Many scenarios exist for INVITE floods attacks, targeted at both SIP proxies and phones. To demonstrate these attacks, we created the Linux-based inviteflood tool, which floods a target with INVITE requests, as its name implies. This version of inviteflood has some additions from the version in the first edition of the book, the most interesting command-line option being support to use TCP for transport. The usage information for this tool is as follows:

The inviteflood tool builds an INVITE request, where the CSeq header field value is incremented in each subsequent message and the new value is also used to replace the last ten characters of the following header field values:

• The Via branch tag

• The From tag

• The Call-ID

A change in these values influences the target to interpret each INVITE request as an independent call dialog initiation event, as opposed to a redundant request. For speed reasons, updates to the ID/tags are performed “in place” (that is, the SIP/SDP request content is not synthesized each time). The size of the resulting Layer 2 packet varies depending on the command-line inputs, but in general is approximately 1,140 bytes. Here we have included a SIP INVITE request generated by the inviteflood tool:

The inviteflood tool is “transmit only” and incapable of responding to authentication challenges or call dialog handshaking. The flood of signaling messages is actually worsened by not responding to call dialog handshaking from the targeted SIP proxy or SIP phones because they retransmit messages. By targeting the SIP proxy, SIP phone, or both, the inviteflood tool can be used to generate a number of different disruptions of service conditions.

For our sample attacks, the inviteflood tool was used to send 1,000,000 packets to a target. Each command took approximately 90 seconds to complete, indicating about 11,111 packets were put on the wire per second, each packet being 1,140 bytes long, for a total of about 12,000,000 bytes. We ran Wireshark on the attacking system during a sample attack to capture the flood packets and showed that approximately 25 percent to 30 percent of these packets were received. Here is the basic command line used for these attacks:

For each attack, we observed the following data points on the platform:

• Process calls Indicates whether the SIP proxy was able to process new calls.

• Responses Lists the types of responses received from the SIP proxy.

• SIP proxy errors For one attack, debugging was enabled for each SIP proxy. Any significant errors are reported here.

Note

For all tests, the SIP proxies appeared to fully recover, so this is not documented in the summary tables that follow.

We performed several tests on the SIP servers to demonstrate how changing the attack parameters can have significantly different results. Here are the test scenarios:

• Target a SIP proxy with a nonexistent SIP phone

• Target a SIP proxy with an invalid IP domain address

• Target a SIP proxy with an invalid domain name

• Target a SIP proxy with an invalid SIP phone in another domain

• Target a SIP proxy with a valid SIP phone in another domain

• Target a SIP proxy for a valid SIP phone

• Target a SIP proxy when authentication is enabled

The results from our tests are summarized in Tables 14-3 and 14-4, each corresponding to the targeted server. We have provided a basic description of each scenario, the testing parameters, and our results in the event that you would like to reproduce them in your own network.

Table 14-3 Asterisk inviteflood Results

Table 14-4 Kamailio inviteflood Results

Target a SIP Proxy with a Nonexistent SIP Phone

This attack floods a SIP proxy with requests containing a nonexistent SIP phone. Although this is not a targeted attack, attackers might use this scenario if the address of a SIP phone is unknown. Figure 14-5 illustrates this attack.

Figure 14-5 Targeting a SIP proxy with a nonexistent SIP phone

Here are the sample command-line arguments for this attack:

Both proxies respond with “404 Not Found” responses. Because the proxies are also acting as SIP registrars, they know that the target “fake_extension” doesn’t exist and therefore return a 404 response. Although both SIP proxies are generating 404 responses, they can still process the majority of call requests, although a few calls are not processed.

Target a SIP Proxy with an Invalid IP Domain Address

This attack floods targeted SIP proxies with requests intended to be forwarded to another domain, which is an invalid IP address. This is a naïve attack, but it can be quite effective. Figure 14-6 illustrates this attack.

Figure 14-6 Targeting a SIP proxy with an invalid IP domain address

Here are the sample command-line arguments for this attack:

The Asterisk SIP proxy appears to recognize that there is no valid SIP proxy at the “fake_target_domain” IP address and quickly returns a “404 Not Found” response. The Kamailio SIP proxy, however, attempts to contact the SIP proxy at the “fake_target_ domain” IP address. This causes it to allocate internal resources, attempting to establish calls that are never completed. Eventually, it runs out of memory trying to establish and track all the attempted calls.

Target a SIP Proxy with an Invalid Domain Name

This attack floods the SIP proxies with requests intended to be forwarded to another domain that is nonexistent. This is an unsophisticated attack, but it can be quite effective. Figure 14-7 illustrates this attack.

Figure 14-7 Targeting a SIP proxy with an invalid domain name

Here are the sample command-line arguments for this attack:

The Asterisk SIP proxy is more resilient to this attack and quickly returns a “404 Not Found” response. The Kamailio SIP proxy, however, attempts to contact the SIP proxy at the invalid domain. This causes it to allocate internal resources, attempting to establish calls that are never completed. Eventually, it runs out of memory trying to establish and track all the attempted calls.

The Kamailio SIP proxy is unable to process calls for some period of time after the attack is over. Eventually, all of the attempted calls time out, internal data structures are deleted, and the SIP proxy recovers and is able to process calls normally.

Target a SIP Proxy with an Invalid SIP Phone in Another Domain

This attack floods the SIP proxies with requests for an invalid SIP phone in the other proxy’s domain. This attack attempts to load up multiple proxies with one attack. Figure 14-8 illustrates this attack.

Figure 14-8 Targeting a SIP proxy with an invalid SIP phone in another domain

Here are the sample command-line arguments for this attack:

This attack significantly disrupts both SIP proxies. The requests are received by the first proxy, which returns a “100 Trying” response. The request is passed to the second proxy, which then returns a “404 Not Found” response, which is returned to the attacker. The first proxy also returns “408 Request Timeout” responses because it receives no response to many of its requests. The Asterisk and Kamailio SIP proxies allocate internal resources, attempting to establish calls that are never completed. Eventually, each SIP proxy runs out of memory or other resources (open files) trying to establish and track all the attempted calls.

Target a SIP Proxy with a Valid SIP Phone in Another Domain

This attack floods the SIP proxies with requests for a valid SIP phone in the other proxy’s domain, attempting to load up multiple proxies with one attack. It has the side effect of affecting the targeted SIP phone. Figure 14-9 illustrates this attack.

Figure 14-9 Targeting a SIP proxy with a valid SIP phone in another domain

Here are the sample command-line arguments for this attack:

This attack significantly disrupts both SIP proxies. The requests are received by the first proxy, which returns a “100 Trying” response. The request is passed to the second proxy, which returns yet another “100 Trying” response. The requests are passed to the SIP phone, which rings but is unusable. The Asterisk and Kamailio SIP proxies allocate internal resources, attempting to establish calls that are never completed. Eventually, each SIP proxy runs out of memory or other resources, such as open files trying to establish and track all the calls.

The Kamailio and Asterisk SIP proxies are unable to process calls for some period of time after the attack is over. Eventually, all of the attempted calls time out, internal data structures are deleted, and the SIP proxies recover and are able to process calls normally. SIP phones behave differently under this attack; typically, if the call is answered and then the SIP phone is hung up, it will start ringing again immediately.

Target a SIP Proxy for a Valid SIP Phone

This attack floods a SIP proxy with requests for a valid SIP phone within its domain, attempting to load up the SIP proxy. This attack has the side effect of affecting the SIP phone. Figure 14-10 illustrates this attack.

Figure 14-10 Targeting a SIP proxy for a valid SIP phone

Here are the sample command-line arguments for this attack:

This attack significantly disrupts each targeted proxy. When the SIP proxy receives the request, it returns a “100 Trying” response and forwards the INVITE to the phone. A “180 Ringing” response is also returned. If the call is answered, a “200 OK” response might also be sent. The SIP phone generally rings and rings and is completely unusable. The Asterisk and Kamailio SIP proxies allocate internal resources, attempting to establish calls that are never completed. Eventually, each SIP proxy runs out of memory or other resources (open files) trying to establish and track all the calls.

Targeting a SIP Proxy when Authentication Is Enabled

This attack attempts to flood a SIP proxy when authentication is enabled for INVITE requests. Authentication won’t normally be enabled for INVITE requests, but it is possible. With authentication enabled, when the SIP proxy receives an INVITE request, it responds with a “407 Proxy Authentication” response. The inviteflood tool doesn’t respond to these requests. The INVITE requests generated are for a valid extension in the targeted SIP proxy’s domain. Figure 14-11 illustrates this attack.

Figure 14-11 Targeting a SIP proxy when authentication is enabled

Here are the sample command-line arguments for this attack:

This attack significantly disrupts the target SIP proxy. The SIP proxy receives the requests and returns a “407 Proxy Authentication Required” response. The SIP phone isn’t affected because the INVITE request is not proxied to the SIP phone. The Asterisk and Kamailio SIP proxies allocate internal resources to track the INVITE requests for which authorization is required. Eventually, each SIP proxy runs out of memory or other resources trying to track and request authentication for all the calls.

Targeting SIP Phones with INVITE Floods Using the inviteflood Tool

This next set of attacks is intended to disrupt service for SIP phones. A number of attacks are possible, including attacks executed through the proxy and targeting the SIP phone directly. For our attacks, we targeted the SIP phone directly. Direct attacks against the SIP phone are more interesting because the SIP proxy is not aware of the attacks and it is very easy to overwhelm a phone. First, we flooded each SIP phone with 1,000,000 INVITE requests. For each phone, the commands used were based on the following:

We attacked both on-hook and off-hook SIP phones. For each attack, we tested the SIP phone’s ability to perform the following functions:

• Behavior Indicates whether the SIP phone just rings or is completely dead.

• Interface function Indicates whether the SIP phone user interface and buttons were usable. During some attacks, the SIP phone appeared “dead.”

• Receive calls Indicates whether the SIP phone could receive calls. Note that it is not applicable to test whether the SIP phone can make calls because it is constantly ringing with inbound calls.

• Recovery Indicates whether the SIP phone recovered after the attack was stopped.

Table 14-5 summarizes the results for the SIP phone tests.

Table 14-5 SIP Phone inviteflood Test Results

Disruption Attacks Using the inviteflood Tool

There are a number of more subtle ways in which inviteflood attacks can be used to disrupt SIP endpoints on a UC network. For example, you could generate smaller floods of INVITE requests at random intervals against SIP proxies or phones. Imagine how users would react after getting 100 calls ranging from every ten minutes to an hour while still trying to get work done. This attack might be harder to detect by staying under IDS flood thresholds. Here are the sample command-line arguments for this attack:

The inviteflood tool has an additional parameter, -s, that can be used to set the number of seconds between transmitted INVITE requests. By setting this value to 10 or 20 seconds, you can target a SIP phone directly, causing it to ring and then ring again a few seconds after the user would have picked up the call. Here are the sample command-line arguments for this attack:

This command will send 100 INVITE requests to a SIP phone, with a 20-second interval between the requests. This attack will continue for about 30 minutes, essentially ringing the targeted extension almost as soon as it is answered and the user hangs up. There are many interesting possible attacks. For example, the following command causes a SIP phone to ring once a minute for an entire workday:

You could also execute multiple commands to cause any or all SIP phones to start ringing, or easily write a script to read extensions from a file and target hundreds or thousands of SIP phones.

These sorts of attacks are particularly nasty because the packet attack rate is very low and is unlikely to be detected by a LAN switch or firewall/IDS/IPS. Also, because the attack bypasses the SIP proxy, there will be no alert that the attack is going on.

TCP SYN Flood Attacks

You can also generate TCP SYN flood attacks against SIP phones or SIP proxies. Because TCP isn’t commonly used, we did not test these attacks; however, SYN flood attacks can be quite lethal, so it would stand to reason that they would be no different against SIP systems using TCP.

Targeting a Media Gateway

A media gateway converts between UC and TDM calls. Media gateways are present in virtually all UC systems to allow communication with analog devices and the PSTN. Single-port/low-density media gateways are commonly used to connect analog phones and fax machines to a UC network.

Media gateways are almost always used to connect a campus UC network to the PSTN. These critical, high-density media gateways are used to convert internal UC/SIP calls to TDM so they can be carried over the PSTN. Media gateways will continue to be used for some time, until enterprises use SIP trunks to connect to the public voice network. Figure 14-12 illustrates the operation of a media gateway.

Figure 14-12 Operating a media gateway in a SIP network

Media gateways are configured in different ways. Some may not have “public” signaling interfaces to the LAN because they don’t exchange signaling with SIP phones. Media gateways must, however, always have “public” media interfaces because SIP phones communicate with them in order to send media to the PSTN for external calls. A variety of signaling protocols are used for media gateways, including MGCP, H.323, and SIP. If the media gateway has a public SIP interface to the LAN, it can be attacked with the same tools used for SIP proxies and SIP phones. These attacks can be lethal because they can tie up resources and trunks used for access to the public network, possibly preventing inbound and outbound calls.

We did not have a media gateway in our testbed, so we did not perform actual testing. However, we provide the following commands that you can use to attack media gateways. First, you can use the udpflood tool to attack the SIP signaling port:

If you observe the RTP ports used for one or more of the media sessions, you can target them as well using either the udpflood or rtpflood tool:

You can also use the inviteflood tool:

You could also create your own tool that takes advantage of proprietary media gateway protocols such as MGCP. We demonstrate such a tool in the next section.

Targeting Media Gateways Using the crcxflood Tool

Media gateways can use several different protocols for communication within the UC environment, including H.323, SIP, and MGCP. The crcxflood tool creates a flood of CRCX or “create connection” messages targeted at one or more endpoints in an MGCP media gateway. The usage information for this tool is as follows:

We tested crcxflood by sending 1,000,000 packets to a media gateway during an assessment (after business hours, of course). Each flood attack took less than two minutes to complete, meaning approximately 8,333 packets were put on the wire per second. The following command was used to generate the packet floods:

After executing one flood against the media gateway, we were able to prevent it from processing inbound or outbound calls during the attack. The gateway had to be restarted after the attack for it to recover fully and start processing calls again.

Other SIP Flood Generation Tools

A number of other packet flood-generation tools are available on the Internet. These offer various pros and cons. SIPp is one we commonly use for load testing—it offers the benefit of being able to generate RTP as well.

We have created several other tools that can generate various SIP request message floods. The tools are available for download at the www.voipsecurityblog.com website. Each tool has the option to use TCP as the transport and is described here:

• byeflood Sends a flood of SIP BYE requests

• optionsflood Sends a flood of SIP OPTIONS requests

• regflood Sends a flood of SIP REGISTER requests

• subflood Sends a flood of SIP SUBSCRIBE requests

Each of these tools has a varying degree of effectiveness against targeted systems, but provides some alternative attack vectors if other tools we demonstrated prove to be ineffective.

Flooding Countermeasures

You can employ several countermeasures to address these flooding attacks against your SIP systems. These countermeasures are very similar to those for SIP fuzzing and are described next.

Use TCP and TLS for SIP Connections

RFC 3261–compliant SIP proxies and SIP phones must support both UDP and TCP. When TCP is used, SIP endpoints generally establish persistent connections with each other. For example, two SIP proxies will establish a persistent connection between themselves. Likewise, SIP phones will establish persistent connections to the SIP proxy. Because of features inherent in TCP, such as the use of sequence numbers, it is more difficult for an attacker to trick a target into accepting packet floods. A target will still consume resources processing the flood packets, but it will be able to discard them at a lower protocol layer. This, for example, would prevent a SIP proxy from ever “seeing” an INVITE flood.

For TCP to be an effective countermeasure against floods, it must be used for all SIP phones communicating with the SIP proxy. If some SIP phones use TCP, but others don’t, then the security model breaks down. For example, if an enterprise uses a SIP proxy that supports TCP for some SIP phones, but not for others, then an attacker can spoof packets for the SIP phones that do not use TCP and flood the SIP proxy. Taking this example to an extreme, if the SIP proxy communicates to 10,000 SIP phones and a single one uses UDP, then if the attacker determines that endpoint, he can easily flood the SIP proxy. The fact that the SIP proxy uses TCP for “some” of the SIP phones is irrelevant.

Caution

Attacks against TCP are still possible, however, as discussed in Chapter 11.

If TCP is used, you can also employ Transport Layer Security (TLS; www.rfc.net/rfc2246.html). TLS uses encryption to provide privacy and strong authentication. TLS prevents attackers from eavesdropping on signaling. TLS also provides strong authentication, which makes it very difficult (if not impossible) for an attacker to trick a SIP proxy into accepting packet floods. As with TCP, this means that spoofed packets will be discarded at the TLS layer and the SIP proxy will not “see” an INVITE flood. Because it uses encryption for authentication, TLS is superior to TCP alone, thereby making it even more difficult to spoof packets.

TLS is used to secure single connections between SIP proxies and/or SIP proxies and SIP phones. TLS is not an end-to-end protocol. For a call to be secure, you must employ TLS for all connections between SIP endpoints participating in the call. Of course, TLS also requires that you trust the SIP proxies that interact with the call.

TLS shares a disadvantage with TCP, in that if some SIP phones use TLS, but others don’t, then the security model breaks down. For example, if an enterprise uses a SIP proxy that supports TLS for some SIP phones, but for not others, then an attacker can spoof packets for the SIP phones that don’t use TLS and flood the SIP proxy. The fact that the SIP proxy uses TLS for “some” of the SIP phones is irrelevant. Asterisk started supporting TCP and TLS in version 1.8. Kamailio started supporting TCP and TLS in version 3.0.

Many of the major UC vendors offer support for SIP, although it is not their primary offering. Many of these implementations support the use of TCP. Some support the use of TLS. You can probably expect these “enterprise-class” SIP offerings to be more secure. However, this security can break down if you mix in components from other vendors that don’t support security features.

Use Other Encryption Protocols

For protocols such as RTP and MGCP, which ride on UDP, you can use other encryption protocols to provide privacy and authentication. The Secure Real-time Transport Protocol (SRTP)²⁰ can be used to provide security for RTP and address flooding (and fuzzing) attacks. We cover SRTP in more detail in Chapter 16. SRTP is supported by virtually all UC vendors.

IPSec can be used to secure UDP-based protocols such as MGCP. For example, Cisco supports the use of IPSec to secure MGCP connections to their media gateways.

Use VLANs to Separate Voice and Data

Most enterprise-class SIP systems use VLANs to separate voice and data. Although VLANs are designed primarily to assist with performance, they also provide a layer of separation and security. With VLANs and properly configured LAN switches, you can block a DoS attack from a compromised PC. MAC filtering and 802.1x port authentication are additional countermeasures. The use of softphones on PCs can defeat the use of VLANs as a security measure. When a softphone is used, packets (presumably from the softphone) must be accepted by the SIP proxy, which opens up the possibility that a rogue application can mimic the softphone and generate flood attacks. One solution to this problem is to use TLS for strong authentication to the softphone.

It is also possible to get flood packets onto the voice VLAN if a rogue PC is added to the LAN switch port configured for the voice VLAN, or you can make use of tools such as voiphopper.

Use DoS Mitigation in LAN Switches

Many LAN switches offer DoS detection and mitigation. You can use this feature to detect various types of floods and prevent the packets from reaching the target.

Enable Authentication

RFC 3261–compliant SIP proxies must support digest-based authentication. This authentication can be enabled for different types of requests, such as INVITE, REGISTER, OPTIONS, BYE, and so on. For example, when authentication is enabled, if a SIP phone sends a REGISTER request, the SIP proxy responds with a “401 Unauthorized” response. For INVITE requests, the SIP proxy responds with a “407 Proxy Authentication Required” response. The SIP proxy provides a realm and nonce that the SIP phone uses to calculate a digest from the username and password, which is sent along with a new request.

We highly recommend authentication for REGISTER requests; therefore, this should be a best practice. You can also enable authentication for INVITE requests. Note that authentication for INVITE requests received from an external network is not practical because the SIP proxy will not have username and password information for external users.

Remember from the section “Target a SIP Proxy when Authentication Is Enabled” that use of authentication can create an additional DoS vulnerability. An attacker can send INVITE requests and never respond, causing resources to be allocated in the SIP proxy, which will remain until they time out. The attacker could also listen for the 401 and/or 407 responses and reply multiple times, also potentially creating a DoS condition.

Change Well-Known Ports

The SIP proxies allow the default SIP port of 5060 to be changed. Although this is a “security through obscurity” technique, it does provide some limited protection. Note that some of the SIP phones use a different port by default.

Use Session Border Controllers (SBCs) and SIP Firewalls

Some traditional firewalls, intrusion detection systems (IDSs), and intrusion prevention systems (IPSs) also support some basic detection of SIP attacks. Companies such as SecureLogix offer application-level firewalls and IPSs that support SIP. Companies such as Redshift and VibeSec offer more general UC firewalls and IPSs that monitor for attacks on protocols other than SIP and RTP, as we mentioned previously.

Summary

Although the security of UC systems continues to improve, they’re still vulnerable to a disruption of service—whether it is from fuzzed packets capable of bringing down a server or a flood of INVITE requests. Because these systems must maintain a degree of network exposure, they are vulnerable.

As UC continues to grow in enterprise networks, the accessibility and interest of fuzzing UC technology will increase. This means that many more vulnerabilities may or may not emerge, depending on who discovers them.

SIP-based systems, including SIP proxies, SIP phones, and media gateways, are vulnerable to various types of fuzzing and flood-based attacks. This is especially true of systems using UDP, which are very easy to trick into accepting spoofed packets. Some of these attacks completely disrupt operation of the target, which in the case of a SIP proxy can affect voice service for an entire site. Attacks against SIP phones, although less disruptive, are easy to perform and can be very annoying to users. Countermeasures are available but must be applied across the entire system to be truly effective.

References

1. Cisco Security Advisories, www.cisco.com/security/.

2. Microsoft Security Advisories, www.microsoft.com/technet/security/current.aspx.

3. SecurityFocus, www.securityfocus.com/.

4. PROTOS project of Oulu University’s Secure Programming Group, www.ee.oulu.fi/research/ouspg/protos/.

5. Codenomicon Defensics, www.codenomicon.com/.

6. Mitre’s Common Weakness Enumeration (CWE), http://cwe.mitre.org.

7. Himanshu Arora, “Buffer Overflow Attack Explained with a C Program Example,” June 4, 2013, www.dsis.com.ar/goodfellas/docz/bof/xpms.pdf.

8. Kelly Burton, “The Conficker Worm,” www.sans.org/security-resources/malwarefaq/conficker-worm.php.

9. “Exploiting Format String Vulnerabilities,” http://crypto.stanford.edu/cs155/papers/formatstring-1.2.pdf.

10. “Format String Attack,” Web Application Security Consortium, www.webappsec.org/projects/threat/classes/format_string_attack.shtml.

11. “Format String Problem,” OWASP, www.owasp.org/index.php/Format_string_problem.

12. blexim, “Basic Integer Overflows,” Phrack, Issue 60, Chapter 10, www.phrack.org/issues.html?issue=60&id=10#article.

13. “Buffer Overflow: Off-by-One,” www.hpenterprisesecurity.com/vulncat/en/vulncat/cpp/buffer_overflow_off_by_one.html.

14. Ari Takanen, Jared DeMott, and Charlie Miller. Fuzzing for Software Security Testing and Quality Assurance, Artech House, 2008.

15. Michael Sutton, Adam Greene, and Pedram Amini, Fuzzing: Brute Force Vulnerability Discovery, Addison-Wesley, 2007.

16. “ohrwurm – RTP Fuzzing Tool (SIP Phones),” www.darknet.org.uk/2008/09/ohrwurm-rtp-fuzzing-tool-sip-phones/.

17. ohrwurm, https://github.com/mazzoo/ohrwurm.

18. Transport Layer Security (TLS), www.ietf.org/rfc/rfc5246.txt.

19. Coordinated Vulnerability Disclosure Reporting at ICANN, www.icann.org/en/about/staff/security/vulnerability-disclosure-11mar13-en.pdf.

20. Secure Real-time Transport Protocol (SRTP), www.ietf.org/rfc/rfc3711.txt.