Praise for Hacking Exposed: Unified communications & VoIP Security Secrets & Solutions, Second Edition (2014)
PART III. EXPLOITING THE UC NETWORK
CHAPTER 12. UC NETWORK INFRASTRUCTURE DENIAL OF SERVICE (DOS)
We had no idea that this would turn into a global and public infrastructure.
—Vint Cerf, one of the founding fathers of the Internet
Although there is an average of 7,000 DDoS attacks each day, most online customers have no idea what is happening.
—Prolexic on defending against DDoS attacks, 2012
UC applications such as voice and video are much more sensitive to network bandwidth issues than most other applications in your environment. Why? Because all UC conversations have specific bandwidth and latency requirements in order to sound clear, as compared to traditional network data applications such as email and web applications, which are a little more forgiving. In this chapter, we will examine the tools and techniques used in infrastructure denial of service (DoS) attacks and explain why UC applications are so susceptible to them. As you will see, a DoS attack can be successful against a UC system by just adding a little bit of latency or jitter to the UC network traffic to degrade phone calls to the point where they are unintelligible. We will also cover some traditional network DoS attacks that can originate from inside or outside your perimeter, depending on the level of access an attacker might have obtained. We will also cover other types of malicious UC DoS attacks that target your supporting infrastructure, such as DNS poisoning, DHCP exhaustion, and ARP table manipulation, to name a few.
Call and Session Quality
Adding UC technology to traditional data networks includes a requirement known as quality of service (QoS). QoS describes your network’s ability to prioritize traffic so that, regardless of bandwidth utilization by other applications, voice and video traffic have excellent quality and also are nearly indistinguishable from traditional PSTN calls. For instance, most home users have at one time or another noticed that while downloading a large file from the Internet, an ongoing UC conversation sounded jittery or scratchy or a video chat degraded until the download finished.
You’ll likely remember the concept of network availability as a basic tenet of data network information security. This also applies to your UC applications. It should be obvious that if your data network is down, from either a DoS attack or a faulty router, your UC capabilities are down as well. On their own, QoS and network availability are often hard enough for an IT staff to ensure across an entire enterprise, without also having to worry about unintentional internal threats such as bandwidth oversubscription, resource exhaustion, network device crashes, and misconfigured devices.
Measuring UC Call Quality
One of the roadblocks for UC adoption pointed out in the first edition of this book was ensuring call quality is comparable to calls made from the traditional PSTN, but this is no longer a problem. However, poor call quality can still be an issue for UC networks. UC network quality can cause phone conversations to skip, sound tinny or choppy, or become unintelligible such that the talking parties have no choice but to disconnect the call. As you would expect, network attacks and congestion problems affect the signaling aspect of UC by delaying dial tone or initial call setup after dialing.
The media codecs inherent in UC applications are very sensitive to network delays and congestion. Depending on the particular compression algorithms, a one-second network outage may actually impact several seconds of speech. UC call degradation is generally categorized by three root causes: network latency, jitter, and packet loss. The International Telecommunication Union (www.itu.int) has developed two documents that provide some general requirements for the clear transmission of UC calls:
• ITU-T G.113 Transmission impairments due to speech processing
• ITU-T G.114 One-way transmission time
Another great resource, from Dialogic, that describes network latency, jitter, and packet loss is “Overcoming Barriers to High-Quality Voice over IP Deployments.”1
Network Latency
Quite simply, latency is the amount of time it takes for a packet to travel from the speaker to the listener. In the traditional PSTN world, there’s usually a slight speech delay due to latency when making an international call because of the traversed distance involved. UC latency is affected by things such as the physical distance of network cabling, a large number of intermediate Internet hops, network congestion and oversubscription, and poor or no internal bandwidth prioritization. The aforementioned G.114 ITU recommendation states that a one-way UC latency of more than 150 ms will be noticeable to the speaking parties. The majority of this latency measurement will probably be incurred from the Internet because your enterprise network will typically have low network latency. Many Internet service providers will uphold a service level agreement to maintain a maximum latency through their network. Table 12-1 details a few sample numbers taken from some of these service providers’ service level agreements, as of this book’s publication.
Table 12-1 Latency, Jitter, and Packet Loss Service Level Agreements for Several ISPs
Jitter
Jitter occurs when the speaker sends packets at a constant rate but they are received by the listener at a variable rate, resulting in a choppy or delayed conversation. Jitter most often occurs in networks with no bandwidth or QoS management, resulting in equal prioritization of the UC traffic with all other data traffic. IETF RFC 3550, “RTP: A Transport Protocol for Real-Time Applications,” and RFC 3611, “RTP Control Protocol Extended Reports (RTCP XR),” describe how to calculate jitter. If a caller experiences jitter greater than 25 ms, it will be noticeable to the speaking party.
Many UC applications and devices try to compensate by building a jitter buffer, which stores a small amount of the UC conversation ahead in order to normalize packets received later. Jitter buffers are typically only effective when the amount of jitter is less than 100 ms. Similarly, many ISPs also build maximum jitter restrictions into their service level agreements, also shown in Table 12-1.
Packet Loss
Packet loss in a data network generally occurs under heavy load and congestion. In most traditional TCP/IP data applications, lost packets are typically retransmitted and there is no noticeable disruption in service. With UC applications, however, resending a lost UC packet is useless because the conversation has already progressed beyond that point. Today, virtually all UC applications use UDP, which has no capacity for loss detection. A mere 1-percent packet loss can seriously impact any UC applications on the network. Table 12-1 lists the service level agreements from some ISPs pertaining to packet loss.
UC Call Quality Tools
A variety of tools can be used for measuring and monitoring the health of UC traffic in your network. Some tools are free software downloads, whereas others are fairly expensive appliances you can place at strategic points within your network. Some network switch vendors also provide the ability to leverage existing infrastructure to measure UC quality. Cisco, for instance, provides several tools that interface with your Cisco routers, switches, and UC gear to keep tabs on your network’s UC health. One tool is the Cisco Prime Collaboration Manager, shown in Figure 12-1, which is a “web-based user application for managing and troubleshooting” that “provides service and network operators with a real-time unified view of all Cisco TelePresence sessions that are in progress.”2
Figure 12-1 Cisco Prime Collaboration Manager session monitoring screen
Voice quality tends to be a fairly subjective characteristic to measure, in part because no one hears the same sound in quite the same way. The Mean Opinion Score (MOS) defined in ITU P.800 is measured subjectively by having a group of listeners rate different voice selections through the same circuit on a scale from 1 (unintelligible) to 5 (very clear). Another ITU recommendation, ITU-T G.107, defines a more mathematical way of predicting the MOS through some of the objective network characteristics of latency, jitter, and packet loss mentioned earlier. This more scientific measurement is known as the R-value, which is calculated from 1 (unintelligible) to 100 (very clear) and tends to be a fairly accurate measure without having to go out and survey 20 of your cubicle mates. Table 12-2 is a general mapping of R-values to MOS values.
Table 12-2 R-Value to MOS Mapping from the Telecommunication Industry Association (“Telecommunications—IP Telephony Equipment—Voice Quality Recommendations for IP Telephony”)
The following broad categories of UC-health-measuring tools may help you get a handle on degradation issues. Many attempt to calculate R-value or estimate MOS in addition to latency, jitter, and packet loss statistics.
UC Software Network Sniffers and Analyzers
Several network sniffers are available for analyzing UC RTP media packets. Wireshark (www.wireshark.org) is a free packet analyzer that has the ability to collect raw packets and decode them on a variety of predefined protocols. Wireshark includes a specialized Telephony menu containing many UC-related features (see Figure 12-2).
Figure 12-2 Wireshark raw packet capture
By selecting Telephony | RTP | Show All Streams, you can see a tabulation of Packet Lost, Max Jitter, and Mean Jitter, as shown in Figure 12-3.
Figure 12-3 RTP streams overview
You can also graph these statistics by selecting the Graph function, as shown in Figure 12-4. This view is useful in detecting anomalies or spikes in jitter. This particular graph shows a very slight amount of jitter.
Figure 12-4 Graph of jitter over time
Commercial analyzers typically provide more reporting features, including R-value and MOS values, as shown in Figure 12-5. Tools such as Cisco Prime Collaboration Manager offer a significant amount of functionality and provide a view of QoS across the network (whereas Wireshark tends to have a view isolated to one part of the network).
Figure 12-5 Cisco Prime Collaboration Manager showing statistics for an individual session
UC Quality Measurement Appliances
Many appliances have the ability to passively analyze real-time UC traffic. Many of these appliances also have the ability to generate calls and simulate various network conditions to stress test your network. Here’s a brief list of traffic quality appliance vendors:
Tip
When you’re performing some of the following attacks on your own network, many of the packet analyzers we’ve mentioned are useful in gauging how susceptible your UC applications are to network disruption. It makes sense to first baseline your normal UC application performance and then monitor any deviations once you try some of the following techniques.
What Are DoS and DDoS Attacks?
Denial of service (DoS) attacks can range from single-packet attacks that can crash applications and servers to streaming packet floods from the same attacker. In single-packet attacks, a carefully crafted packet is formed that exploits a specific operating system flaw or application vulnerability. Malformed or “fuzzed” packet attacks are covered in more detail in Chapter 14, later in the book.
In a DoS flood attack, the servers or network resources are exhausted by a flood of packets. Because a single attacker sending a flood of packets can be identified and isolated fairly easily, the approach used by most attackers is the distributed denial of service (DDoS) attack. In a DDoS flood attack, an attacker uses multiple machines that he controls to flood a target, as described in the upcoming “Botnets” sidebar. Since the first edition of the book, DDoS attacks have become even more devastating. According to a Prolexic report, in 2009 the average duration of a DDoS attack was 8.41 hours using .01 Gbps of bandwidth with an average attack speed of 1,241 pps, whereas in 2011 the average duration was 80 hours while using .6 Gbps of bandwidth with an average attack speed of 185,404 pps—a significant increase in all the data points.3
As you’ll recall, we covered TDoS attacks in Chapter 7. TDoS attacks only differ from DoS/DDoS attacks in that they involve malicious calls instead of malicious packets. TDoS attacks are arguably the most disruptive, because they can originate over the public untrusted network, but DoS and DDoS are also extremely disruptive if the attacker has the ability to create these attacks within the enterprise. These attacks can occur over SIP trunks, UC used over the Internet, or as described in Chapters 10 and 11, within an internal enterprise network.
Flooding Attacks
Flooding is a fairly self-explanatory DoS attack. An attacker attempts to consume all available network or system resources (bandwidth, TCP/UDP connections, and so on) such that legitimate applications are unusable. Almost everyone remembers the DDoS attacks launched against eBay and Yahoo! in February of 2000, when DDoS first hit the public radar. Since this first attack, we have seen a significant increase in the number of DDoS attacks. These attacks have been used for many different purposes, ranging from hacktivism (by groups such as Anonymous) to financial gain (by individuals targeting banks and other institutions). Flooding attacks have been more common because DoS tools are available to everyone, including script kiddies. For example, 255 exploits were available at www.packetstormsecurity.org/DoS/at the time this book was written. The proliferation of botnets (see the upcoming sidebar) has also led to a large increase in DDoS attacks launched by armies of malware-infected zombie hosts. The intentions of DoS and DDoS attackers range all the way from organized crime extortion to simple juvenile fun.
Flooding attacks can impact your UC applications differently, depending on the targets. For instance, launching a SYN flood against a UC phone is quite different from filling up all available bandwidth on the local network by flooding the entire LAN. In the following sections, we’ll discuss the impact of several different types of DoS attacks on a UC call.
Botnets
A botnet is a large army of compromised computers controlled by an attacker. Individual computers can be initially infected by any of a variety of malicious software, including worms, Trojans, email spam, and web browser vulnerabilities. Each type will connect back to an attacker, usually through IRC or peer-to-peer networks when a new infection takes place. The attacker can use the infected drone army to search out and infect other vulnerable hosts by exploiting vulnerabilities over the network like worms do or by sending virus attachments to random email recipients. One such example of a bot worm is Conficker (http://en.wikipedia.org/wiki/Conficker).
The person who controls a large botnet is typically called a bot herder. More and more law enforcement agencies in different countries are starting to crack down on bot herders, with some fairly high-profile arrests hitting the press. One such case involved the arrest of ten people in Bosnia and Herzegovina, Croatia, New Zealand, Peru, the United Kingdom, as well as the U.S. in connection with the Butterfly botnet that targeted Facebook users and caused over $850 million in losses to financial institutions. The Butterfly botnet infected over 11 million computers according to an Ars Technica article.4
Some of the more sinister functions of a botnet include the following:
• Launching DDoS attacks
• Sending spam
• Installing spyware/adware/scareware on additional systems
• Manipulating online ad revenue
• Sending phishing emails
• Self-propagation through worms
Bot infections are still on the rise. According to a report from Kindsight for the third quarter of 2012, “13 percent of home networks in North America are infected with malware, 6.5 percent of which are tainted with bot malware, rootkits, and banking Trojans.”5 If you refer back to the quote at the beginning of the chapter, you’ll also notice a corresponding rise in the number of DDoS attacks on the Internet. Correspondingly, botnets are the leading source of DDoS attacks on the Internet today. DDoS attacks, in general, are challenging to isolate because the source IP addresses of the botnet zombie hosts can originate from all over the world and from unpredictable source addresses such as infected home computers in the United States, which leads the world in infected computers. The following sources may be dated, but they still provide a good summary of botnets and bot worms:
• www.honeynet.org/papers/bots/
• www.niscc.gov.uk/niscc/docs/botnet_11a.pdf
• www.nanog.org/mtg-0410/kristoff.html
UDP Flooding Attacks
User Datagram Protocol (UDP) flooding is a preferred type of bandwidth flooding attack because UDP source addresses can be easily spoofed by the attacker. Spoofing often allows an attacker the ability to manipulate trust relationships within an organization to bypass firewalls and other filter devices (for example, by crafting a DoS stream to appear as a DNS response over UDP port 53).
Almost all SIP-capable devices support UDP, which makes it an effective choice of attack transport. Many UC devices and operating systems can be crippled if a raw UDP packet flood is aimed at the listening SIP port (5060) or even at random ports.
A variety of UDP flooding tools are freely available for download from the following sites to test the susceptibility of your applications and network:
• www.mcafee.com/us/downloads/free-tools/udpflood.aspx
• http://packetstormsecurity.org/exploits/DoS/
TCP SYN Flood Attacks
TCP SYN flood attacks subvert the TCP connection three-way handshake in order to overwhelm a target with connection management. See the background on TCP ping scanning in Chapter 3 for more on information on how TCP connections are set up. A standard TCP three-way handshake includes the following steps:
1. The TCP client sends a SYN packet to the server.
2. The server replies with a SYN-ACK packet.
3. The client sends an ACK packet back to the server.
The actual attack typically involves the attacker sending a flood of SYN packets with spoofed source IP addresses. The victim will then respond with a SYN-ACK to the unsuspecting or nonexistent spoofed source. To complete the TCP connection, the victim is then left waiting for a period of time for the ACK packet from the spoofed source. This is the crux of the attack because the final ACK is never sent, and subsequently the victim’s connection table quickly fills up and consumes all available resources with these invalid requests. The end result is that a server, phone, or router will not be able to distinguish between bogus DoS SYNs and legitimate SYNs related to actual UC connections. Our tcpsynflood tool can be found on our website at www.voipsecurityblog.com. Also, a variety of tools can launch a simple SYN flood attack. These tools are available at www.packetstormsecurity.org/DoS or can be found online through creative web searches.
ICMP and Smurf Flooding Attacks
The Internet Control Message Protocol (ICMP) is often allowed through most firewalls and routers for diagnostic purposes, such as ping and traceroute. However, ICMP also provides the capability to send large amounts of ICMP traffic. A more sinister use of ICMP traffic involves spoofing the source IP address and pinging broadcast addresses of a variety of networks that allow IP directed broadcasts. This is called a Smurf attack and involves a flood of legitimate ICMP responses from these networks to the victim who was spoofed. By overwhelming the victim’s network bandwidth with spurious ICMP responses, most legitimate Internet applications will sputter under the attack. One easy way to prevent this attack is by disabling IP router addressing because it’s typically not used. See www.cert.org/advisories/CA-1998-01.html for more information on how to mitigate this attack.
Established Connection Floods (or Application Flooding Attacks)
This type of attack is covered in much more detail in Chapter 14, which covers UC application-level DoS attacks. Essentially, an established connection flood is an evolution of the TCP SYN flood attack, but a full connection is made to the targeted service or device and then quickly torn down. This attack may go even further to make an actual application request to try to overwhelm the target. In the case of a target web server, this could take the form of thousands of botnet zombie hosts hammering away at a web server with legitimate GET requests. For a SIP PBX, it could take the form of thousands of REGISTER/INVITE/BYE requests received at the same time, overwhelming the incoming connection queue. Conversely for a SIP client, this attack could take the form of thousands of bogus incoming calls, rendering your phone useless.
Worm and Virus Oversubscription Side Effect
Oversubscription simply means your application’s bandwidth needs have exceeded your network’s capabilities. This can occur from any number of flooding DoS attacks or poor QoS management. However, worm and virus outbreaks within your network can easily consume all available bandwidth as a side effect of scanning for other vulnerable hosts to infect. Even just a few worm-infected machines within an organization can clog all available bandwidth with the spurious traffic spewing from the victims.
QoS Manipulation with Targeted Flooding
A much more advanced type of flooding attack involves subverting the quality of service mechanisms within a network in order to degrade UC applications. Assuming that an organization’s QoS technologies are configured to prioritize RTP traffic over all other traffic, this normally means that a simple internal flooding attack would be mostly ineffective. However, if an attacker can flood a phone, proxy, or PBX with legitimate-looking RTP traffic, the QoS mechanisms would be unable to determine which conversations are bogus and which ones are real and deserve network priority. Depending on the QoS mechanism being applied, it may also be necessary for the attacker to know two actively talking parties in order to spoof the proper ports and sequence numbers.
Flooding Attack Countermeasures
Many approaches can be taken when defending against the variety of DoS and DDoS flooding attacks. It’s important to keep in mind that there is no silver bullet to completely eliminate your susceptibility to DoS and DDoS attacks. The best solution is to adopt a defense-in-depth approach to protect your UC-dependent devices, network components, and servers.
Quality of Service Solutions
From among the variety of QoS solution approaches implemented today, the most common is DiffServ (for differentiated services). Using the DiffServ approach, network packets are tagged according to their priority, generally based on the type of application they are. Network devices are then able to manage how they deliver and prioritize these incoming packets. For example, RTP packets would generally receive a higher network priority as compared to email or P2P traffic.
The packet priorities can be tagged in a couple of ways. The differentiated services code point (DSCP) is applied at the IP layer. Equally as effective and more commonly used at the MAC layer are IEEE standards 802.1P and 802.1Q. (VLAN tagging was discussed in detail in Chapter 10; also see http://standards.ieee.org/getieee802/.) 802.1P defines a scheme for prioritizing network traffic, and the 802.1Q (VLAN) header contains the 802.1P field, so you need VLANs to implement QoS with 802.1P.
Anti-DOS/DDoS Solutions
An entire security market is devoted to DoS and DDoS mitigation. Most of these vendors sell appliances that can be deployed at the perimeter as well as the core of your network. These appliances are able to detect and either block or rate-limit an active DoS or DDoS attack. Here’s a list of some of these vendors:
Session Border Controllers (SBCs) also provide DoS/DDoS protection at the SIP and RTP layers. We cover SBCs in more detail in Chapters 14 and 15.
Hardening the Network Perimeter
Much of your preexisting network equipment can be configured to resist the most basic DoS and DDoS techniques that attackers use. Each vendor’s equipment is different, however. For some great pointers regarding Cisco-specific recommendations, check out “Strategies to Protect Against Distributed Denial of Service (DDoS) Attacks” at www.cisco.com/image/gif/paws/13634/newsflash.pdf. Other vendors have similar documents and guides, most often found online in support forums. Although the guidelines in the aforementioned document are specific to Cisco devices, they generally apply to most organizations regardless of networking vendor. Some of the guidelines include such things as ingress and egress filtering, SYN rate limiting, and ICMP blocking, to name a few.
Hardening UC Phones and Servers
Hardening your UC phones and servers includes some very basic across-the-board recommendations, regardless of the particular vendor:
• Change the default passwords and remove all guest and nonauthenticated accounts.
• Disable unnecessary services (telnet, HTTP, and so on).
• Ensure the device or operation system is up to date with the latest patches and/or firmware.
• Develop a strategy for keeping up to date with patches.
VLANs
Virtual LANs (VLANs) are used to segment network domains logically on the same physical switch and can provide some protection for your UC servers and devices. Many switches support the ability to create several VLANs on the same switch and help to protect your core UC servers and devices by separating them from the regular LAN traffic and most DoS traffic threats such as worm and viruses. Although VLANs can provide some protection, they should be used with other security mechanisms as part of a defense-in-depth deployment. Most VoIP manufacturers provide best-practice implementation guides such as “Cisco Unified Communications Security”6 and Avaya’s “Security Best Practices Checklist.”7 Although softphones make it challenging to separate your UC applications logically from the data network due to the desktop’s need for access to data network resources, having QoS properly configured will ensure that “if/when the PCs go south because of some virus or malware, the voice packets still get priority over the data (LAN) traffic and don’t get stuck in queue.”8
Network Availability Attacks
Another variety of network DoS attacks involves an attacker trying to crash the targeted network device or underlying operating system. The following are the most popular and prevalent of these types of attacks.
Stress Testing with Malformed Packets (Fuzzing)
As we discussed in Chapter 3, the TCP/IP stack implementations for different operating systems are unique enough that they can be differentiated in their responses to network traffic. This illustrates the point that all vendors implement their device IP stacks in various ways, and in some cases implementations vary across different versions of the same product. Whereas some operating systems are robust and able to handle a variety of error conditions, others are not quite as resilient. Often, developers don’t take into account network input that deviates from “normal” traffic, which in some cases can lead to the device or application crashing when processing this abnormal traffic. We’ve seen this a million times in the security industry, and it is typically the cause of most denial of service vulnerabilities on routers and switches.
To adequately test the robustness of a network stack implementation, you typically want to devise as many “evil” test cases as possible that stress the boundaries of your support protocol. You can find bugs and DoS vulnerabilities in network devices simply by crafting different types of packets for that protocol that contain data that pushes the protocol’s specifications to the breaking point. This is known as “fuzzing,” of course.
A useful free fuzzing tool suite for testing the robustness of underlying IP stack implementations is IP Stack Integrity Checker (ISIC, at http://isic.sourceforge.net/). ISIC is “a suite of utilities to exercise the stability of an IP stack and its component stacks (TCP, UDP, ICMP, et al.).”9 ISIC comes with five individual tools that manage their respective protocols in different ways: isic (IP), tcpsic (TCP), udpsic (UDP), icmpsic (ICMP), and esic (Ethernet). You can also find some free and commercial fuzzing suites that go beyond the IP stack, all the way to the application layer.Chapter 14 covers UC protocol fuzzing and will discuss the many ways to break the application layer.
Packet Fragmentation
Although packet fragmentation is an older attack, it is still relevant. By fragmenting TCP and UDP packets in unique ways, it is possible to render many operating systems and UC devices useless. There are many variations of fragmentation attacks. Some of the most popular tools are Scapy, Metasploit, teardrop, opentear, nestea, jolt, boink, and the ping of death, most of which can be found at http://packetstormsecurity.org or through some simple web searches. Here’s a list of some memorable, well-known fragmentation-based vulnerabilities:
• ISS RealSecure 3.2.x Fragmented SYN Packets DoS Vulnerability www.securityfocus.com/bid/1597
• CERT Advisory CA-1997-28 IP Denial-of-Service Attacks www.cert.org/advisories/CA-1997-28.html
• Cisco Security Advisory: Cisco PIX and CBAC Fragmentation Attack www.cisco.com/en/US/products/csa/cisco-sa-19980910-pix-cbac-nifrag.html
Launching a fragmentation attack is a matter of simply finding the right target and choosing the proper tool for the job. For instance, to launch a fragmented UDP flood against our SIP proxy, we can download and run the tool opentear, like so:
Underlying OS or Firmware Vulnerabilities
Another major category of DoS attacks against UC infrastructure involves an attacker leveraging vulnerabilities in the underlying application or operating system, which can lead to a system crash or overwhelming resource consumption. For instance, any new vulnerability in your Linux system may correspondingly affect the Asterisk application running on top of it. In the same vein, any IOS DoS vulnerability will directly affect Cisco Unified CallManager Express, which runs on top of it. As an example of the underlying application providing potential vulnerabilities, we can look at each of the following Linux vulnerabilities for RHEL 5, which is the operating system for Cisco Unified Communications Manager 8.6:
• GNU glibc Multiple Local Stack Buffer Overflow Vulnerabilities www.securityfocus.com/bid/54982
• Red Hat Enterprise Linux NFSv4 Mount Local Denial of Service Vulnerability www.securityfocus.com/bid/50798
• Linux Kernel SCTP Remote Denial of Service Vulnerability www.securityfocus.com/bid/49373
• Linux Kernel SSID Buffer Overflow Vulnerability www.securityfocus.com/bid/48538
Network Availability Attack Countermeasures
The countermeasures listed previously in the “Flooding Attack Countermeasures” section are also applicable here and can ensure network availability. We should also discuss an additional countermeasure specific to the attacks we just covered: network intrusion prevention.
Network Intrusion Prevention Systems
Network-based intrusion prevention systems (NIPSs) are inline network devices that detect and block attacks at wire speed. A NIPS can be deployed in a network in much the same way as a switch or a router. The NIPS inspects each packet that passes through it, looking for any indication of malicious activity. When the NIPS detects an attack, it blocks the corresponding network flow. As an element of the network infrastructure, it must also identify attacks without blocking legitimate traffic. NIPSs also buy IT administrators time to patch enterprise-wide by providing a sort of virtual patch for any exploits that may emerge soon after a new vulnerability is discovered in the public domain. There are many NIPS vendors, including the following:
Supporting Infrastructure Attacks
Basic UC architecture elements such as phones, servers, and PBXs rely heavily on your supporting network infrastructure (DHCP, DNS, or TFTP, for example). If one of these support elements crashes or is disabled, a potential side effect is that your UC applications are crippled or severely limited in usability. The following are just a few examples of attacks on dependent data infrastructure elements.
DHCP Exhaustion
Many UC phones are configured, by default, to request an IP address dynamically every time they are powered on. If the DHCP server is unavailable at the time they boot up, or the maximum number of IP addresses has already been allocated, the phone might not be usable on the network. Several tools can be used for exhausting DHCP addresses: yersinia (www.yersinia.net); dhcpx, which is included with the Internetwork Routing Protocol Attack Suite (IRPAS) by Phenoelit (www.phenoelit.org/fr/tools.html); and even Metasploit, which has a module specifically designed for DHCP exhaustion.
DHCP is a broadcast protocol, which means that REQUEST messages from DHCP clients such as IP phones are seen by all devices on the local network, but are not forwarded to additional sub-networks. If the DHCP server is present on a different network, DHCP forwarding must be enabled on the router. DHCP forwarding converts the broadcast message into a unicast message and then forwards the message to the configured DHCP server. DHCP forwarding is offered on most routers and Layer 3 switches.
DHCP messages are bootp (bootstrap protocol) messages. UDP port 67 is the bootstrap server port, and port 68 is the bootstrap client port. bootp message payloads may be carried over UDP and TCP; however, we only witnessed UDP/IP messages being exchanged during our experiments.
On our test network, the DHCP server is configured on the Cisco CME, which is installed on a 2620XM router. The 2620XM’s DHCP server was configured to lease up to 30 consecutive IP addresses, far more than we needed for the six phones on VoIP VLAN. We used our Cisco IP model 7940 and 7960 phones to demonstrate the DHCP exhaustion attack, although we could have used other IP phones because this attack is not unique to Cisco.
For our exploit tool, we downloaded yersinia version 7.1 from www.yersinia.net and installed it on a CentOS 5.5 laptop. According to the website, yersinia was “designed to take advantage of some weakness in different network protocols,”10 one of which is DHCP. We connected the attack laptop to the Cisco phone VLAN, acquired an IP address, and started the tool using the following command:
./yersinia -I
This command started the semi-graphical user interface that allows an attacker to prepare the tool for the DHCP attack. Once the tool had initialized, we entered g to choose the protocol targeted for the attack, as shown in Figure 12-6.
Figure 12-6 Yersinia DHCP attack protocol specifi cation
After selecting DHCP using the cursor keys, we configured yersinia to send DISCOVER packets, as shown in Figure 12-7, and launched the attack by typing 1.
Figure 12-7 Yersinia DISCOVER packet confi guration
Once the attack was started, we could immediately see the tool sending out DISCOVER messages to the DHCP server and using up the available DHCP leases, as shown in Figure 12-8.
Figure 12-8 Yersinia sending DHCP DISCOVER messages
In order to force the Cisco IP phones to erase the assigned IP address, we accessed the network configuration settings on the phone and changed the “DHCP Address Released” field from “no” to “yes,” causing the phone to drop the assigned IP address and all of the other configuration information on the phone, such as the TFTP server IP address, the CME IP address, the router IP address, and the VLAN info.
After changing the configuration on the phone, we rebooted it by disconnecting the PoE cable and allowed the IP address lease to expire. We had configured the leases to two minutes to facilitate testing, which caused the phone to reacquire the DHCP leases frequently. Yersinia easily exhausted IP addresses available for OFFERs on the VoIP VLAN by sending multiple DISCOVER messages and receiving multiple OFFER messages from the server. The tool produced a random source MAC address for each DISCOVER message. While the attack was underway, the phone was unable to acquire an IP address, could not connect to the CME, and could not place calls until the attack ended, the fake leases expired, and the phone was able to connect to the CME normally.
DHCP Exhaustion Countermeasures
You can do a couple things to mitigate a DHCP exhaustion attack. You can configure DHCP servers not to lease addresses to unknown MAC addresses and also to untrusted network segments. Cisco switches even have a feature called “DHCP snooping” that acts as a DHCP firewall between trusted and untrusted network interfaces (www.cisco.com/en/US/docs/switches/lan/catalyst4500/12.1/13ew/configuration/guide/dhcp.html). See Chapter 13 for more information.
DNS Cache Poisoning
DNS cache poisoning attacks involve an attacker tricking a DNS server into believing the veracity of a fake DNS response. The purpose of this type of attack is to redirect the victims dependent on that DNS server to other addresses (for instance, redirecting all traffic destined towww.cnn.com to www.playboy.com); this type of attack has traditionally been used in phishing schemes to redirect a user trying to surf to his banking site to a fake site owned by the hacker.
A DNS SRV record assists SIP phone dialing in much the same way that MX records help map email addresses to the appropriate mail servers. Some sites are beginning to use DNS SRV records to forward certain SIP requests to particular proxy addresses, potentially outside of the organization. This has particularly dangerous implications if an attacker can poison these resource listings to redirect all calls going to your domain to her external proxy.
A simple DNS cache poisoning attempt, shown here, is taken from the documentation of the DNS auditing tool, DNSA (www.packetfactory.net/projects/dnsa):
DNS Cache Poisoning Countermeasures
DNS cache poisoning is almost entirely avoidable if you configure your DNS server properly. This includes forcing it to scrutinize any forwarded DNS response information passed by other nonauthoritative servers and dropping any DNS response records passed back that do not relate to the original query. Most recent DNS servers are immune to this attack in their default configurations. A decent overview on DNS security can be found at www.cert.org/archive/pdf/dns.pdf.
DNS Flood DoS
As you learned in the previous section, DNS servers can be critical in relaying SIP calls through your organization. It is possible to perform any of the aforementioned flooding attacks on DNS servers in order to consume all available network traffic or available connections. UDP floods are particularly effective at crippling exposed DNS servers simply because most firewalls cannot differentiate between bogus DoS traffic and a legitimate DNS request/response traveling to/from the server.
DNS Flood DoS Countermeasures
Protecting your internal DNS server from flooding is a matter of practicing good network security. Protecting your vital network infrastructure with network-based or host-based intrusion prevention systems can help to stop flooding events when and if they occur inside your network. You can also harden your internal Linux servers. Ensuring the server is patched and updated against vulnerabilities is a great start and you can also configure it to resist flooding attacks such as configuring iptables and making other changes to the kernel and network interfaces.11
Summary
As you can see, numerous types of DoS and DDoS attacks can cripple your UC environment. Therefore, a holistic view of security is required to secure your UC applications from these attacks—you need to protect not only your UC devices and servers, but also the entire data network and supporting infrastructure.
References
1. “Overcoming Barriers to High-Quality Voice over IP Deployments,” Dialogic, www.dialogic.com/~/media/products/docs/media-server-software/8539_Overcoming_Barriers_wp.pdf.
2. “Cisco Prime Collaboration,” Cisco Systems, www.cisco.com/en/US/docs/net_mgmt/prime/collaboration_manager/1.0/user/guide/intro.pdf.
3. “Strategies for Surviving a Cyber Attack This Holiday Season,” Prolexic, Knowledge Center, www.prolexic.com/knowledge-center-white-paper-strategies-holiday-ddos-cyber-attack.html.
4. Sean Gallagher, “FBI Snares $850 Million Butterfly Botnet Ring with Help of Facebook,” ArsTechnica, http://arstechnica.com/tech-policy/2012/12/fbi-snares-850-million-butterfly-botnet-ring-with-help-of-facebook/.
5. Kindsight Security Labs, “Malware Report Q3 2012,” Kindsight, www.kindsight.net/sites/default/files/Kindsight_Security_Labs-Q312_Malware_Report-final.pdf.
6. “Unified Communications Security,” Cisco Systems, www.cisco.com/en/US/docs/voice_ip_comm/cucm/srnd/9x/security.pdf.
7. Avaya, Security Best Practices Checklist, http://downloads.avaya.com/css/P8/documents/100070101.
8. Matt Brunk, “How to Handle Softphones When Keeping Voice and Data on Separate VLANS,” SearchUnifiedCommunications.com, http://searchunifiedcommunications.techtarget.com/answer/How-to-handle-softphones-when-keeping-voice-and-data-on-separate-VLANs.
9. ISIC—IP Stack Integrity Checker, http://isic.sourceforge.net/.
10. Yersinia, www.yersinia.net.
11. Ramil Khantimirov, “Protecting Your Linux Server from SYN Flood Attacks: Nuts and Bolts,” Ramil’s Tech Corner, www.ramil.pro/2013/07/linux-syn-attacks.html.