Supporting Infrastructure Attacks

Basic VoIP architecture elements such as phones, servers, and PBXs rely heavily on your supporting network infrastructure (DHCP, DNS, TFTP, and so on). If one of those support elements is attacked or taken offline, a side effect may be that your VoIP applications are crippled or severely limited in usability. The following are just a few examples of attacks on dependent data infrastructure elements.

Attack DHCP Exhaustion

Popularity:	4
Simplicity:	5
Impact:	8
Risk Rating:	6

Many VoIP phones are configured, by default, to request an IP address dynamically every time they are turned on or rebooted. If the DHCP server is unavailable at the time they boot up, or the maximum number of IP addresses have already been allocated by that DHCP server, then the phone might not be usable on the network. A tool for exhausting DHCP addresses, called dhcpx, is included with the latest version of the Internetwork Routing Protocol Attack Suite (IRPAS) by Phenoelit (http://www.phenoelit.de/irpas/download.html).

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 subnetworks. 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 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.

DHCP Resource Exhaustion Case Study

We configured two DHCP servers. The first one was the dhcpd daemon bundled with the Linux Red Hat Fedora Core 4 distribution and running on a PC we connected directly to the subnet switch. The second was the DHCP server delivered with a Cisco 2821 router. We chose to demonstrate this attack using the Avaya Communication Manager IP phones. We could have used other IP phones though, because this attack is not unique to Avaya.

We configured the dhcpd.conf file on the Linux-based PC's DHCP server to permit it to lease up to two IP addresses. These happened to be the same IP addresses that had been statically assigned to the Avaya H.323 IP phones up to this point in time. We also modified the dhcpd.conf file so the DHCP server would respond to DHCP DISCOVER broadcasts with Option 176 information particular to Avaya IP phones. DHCP Option 176 is a "private" option (in other words, a manufacturer may supply information particular to their devices). The Avaya 4602 H.323 IP phones required the following particular information in Option 176:

• IP address of their TFTP server

• IP address of their call server (the Avaya Communication Manager)

• Call server port

The TFTP server and the call server were the same, 10.1.14.100 (the Avaya Communication Manager S8300 module).

We configured the Cisco 2821 router's DHCP server to lease up to ten consecutive IP addresses that did not overlap with the two addresses that could be leased from the Linux-based PC. However, we did not configure the Cisco DHCP server to supply Option 176 information.

We downloaded the Internetwork Routing Protocol Attack Suite (irpas) toolset from http://www.phenoelit.de/irpas/download.html and built the toolset to use the Dynamic Host Confusion Program tool (dhcpx) to exhaust DHCP IP address leases.

One technique to motivate an Avaya 4602 IP phone with a H.323 load to provoke DHCP operations during its boot cycle is to zero out its statically assigned IP address. We unplugged and plugged in each phone. When the boot sequence got to the point where the phone prompted the user (via its LCD) to press * to permit configuration parameters to be entered through the keypad, we pressed the * key and zeroed out all of the configuration parameters presented on the LCD. These included the file server (TFTP) IP address, the call server (Communication Manager) IP address:port, the subnet mask, the router gateway IP address, VLAN info , and so on. We saved the new values and the phones recycled.

After recycling, the H.323 IP phones each broadcast (subnet broadcast) a DHCP DISCOVER message. Both DHCP servers responded to the broadcasts with DHCP OFFER messages. Because the DHCP server running on the Linux-based PC supplied values for Option 176, each of the phones selected the respective OFFERs from the Linux-based PC as opposed to the OFFERs from the Cisco DHCP server. Each phone completed its respective handshake and then registered with the Avaya Communication Manager. Calls could then be exchanged between them in a normal fashion.

We then unplugged the IP phones and permitted their IP address leases to expire. To facilitate the test, we had configured the leases to a brief interval (two minutes). We employed the dhcpx tool in two trials. It accomplished the goal each time (in other words, exhausting IP addresses available for OFFERs); however, it behaved differently in each trial. The command-line info for this tool is

 ./dhcpx ./dhcpx [-v[v[v]]] -i <interface> [-A]         [-D <destination ip>]         [-t <discovery time in secs>]         [-u <ARP time in secs>] 

The command we used was:

 ./dhcpx -vvv -i eth0 -D 10.1.14.110 

In the first trial, dhcpx initially attacked the DHCP server on the Linux-based PC at 10.1.14.110 as instructed. It sent multiple DISCOVER messages to provoke multiple OFFERs from the server. Because there were only two IP address leases available, each was quickly offered up by the targeted DHCP server. The DISCOVER messages were unicast to the targeted DHCP server (10.1.14.110)that is, the destination MAC address was the address of the targeted DHCP server. However, the destination IP address was the subnet broadcast address (255.255.255.255). This does not matter because the IP address is irrelevant if the MAC address is not also a subnet broadcast address (255.255.255.255.255.255). The tool produced a random source MAC address for each DISCOVER message. A DHCP server responded to that MAC address.

Unexpectedly, the tool began to actually broadcast DISCOVER messages (in other words, MAC and IP addresses were both subnet broadcast addresses). The DHCP server running on the Cisco router responded with OFFER messages. The dhcpx tool never completed the Discover Offer Request Acknowledge (DORA) handshake. It simply continued to broadcast DISCOVER messages. Because the servers reserved their offered IP addresses for a brief interval (for example, for seconds or minutes), this had essentially the same effect as if the dhcpx tool had actually gone ahead and accepted the OFFERs. It exhausted the IP address leases that could be offered from both DHCP servers. We stopped the tool and permitted the OFFERs to expire on both DHCP servers so they would once again have leases to offer. The H.323 phones remained unplugged.

On the second trial, the tool restricted its attack exclusively to the targeted DHCP server identified by the command line -D option. It also sealed the deal for each lease offered. Having browsed the tool's code, this performance is what we expected to see on the first trial. At this point, we reattached each phone's combined Ethernet/power connector into the back of the phone. They booted and broadcast DISCOVER messages. The DHCP server on the Linux-based PC did not respond because it had no available IP address leases to offer. The DHCP server on the Cisco router responded with OFFERs. These OFFERs were accepted by the phones, but were quickly released. Remember, the Cisco DHCP server was not configured to offer Option 176 containing the Avaya peculiar values. The phones essentially entered a DISCOVER loop, each repeatedly broadcasting DISCOVER messages accepting the Cisco DHCP IP address lease and then immediately releasing it. The phones also scrolled the same message across their LCD's complaining about L2Q (Layer 2 Quality) parameter conflicts and a "looping condition." Regardless, telephony service was effectively denied .

We terminated the dhcpx tool attack. Because we had configured the leases on the Linux-based PC to expire every two minutes, the two IP addresses that had been consumed by the dhcpx tool soon became available for lease from that DHCP server (in other words, it began to respond to DISCOVER messages from the phones). One of the Avaya phones (the one with the newer H.323 loadR2.3) quickly received an OFFER from the DHCP server on the Linux-based PC. It accepted the OFFER and registered with the Avaya Communication Manager. The H.323 phone with the older load (R1.82) remained in its DISCOVER loop. We're uncertain what was happening with that load. We unplugged and plugged in that phone. On the first DISCOVER cycle of the boot process, it received and accepted the OFFER from the Linux-based DHCP server, whereupon it registered with the Avaya Communication Manager and calls could once again be exchanged in a normal fashion. The phones renewed their IP address leases every 70 seconds with the Linux-based DHCP server.

Several times since then we have observed that the R1.82 loaded phone displays

 Discover...... 

on its LCD. Perhaps there is a bug in that load regarding DHCP functionality. We unplugged and plugged in the phone. It booted, obtained an IP address, and operated normally for an undetermined amount of time. The expectation is that DHCP servers are typically configured to offer leases for days. A bug in the R1.82 H.323 load might be asserted when the lease is for a rather short duration compared to what is typically encountered in the field.

Countermeasurs DHCP Exhaustion Countermeasures

There are a couple of things you can do to mitigate an 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 (go to http://www.cisco.com/univercd/cc/td/doc/product/lan/cat4000/12_1_13/config/dhcp.htm). See Chapter 7 for more information.

Attack DNS Cache Poisoning

Popularity:	4
Simplicity:	4
Impact:	8
Risk Rating:	5

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 to www.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 their 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 (http://www.packetfactory.net/projects/dnsa):

 ./dnsa -3 -D the_host_IP_which_is_asked_for -S normal_host_IP -s DNS_server_which_is_doing_the_request -a host_in_additional_record -b ip_in_the_additional_record -i INTERFACE ./dnsa -3 -D hacker.pirate.org -S 100.101.102.103 -s 194.117.200.10 -a www.microsoft.com -b 1.2.3.4 -i eth0 

Countermeasurs 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 http://www.cert.org/archive/pdf/dns.pdf.

Attack 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.

Vulnerabilities in Underlying OS or Firmware

Like many VoIP applications, most supporting infrastructure services run on top of popular operating systems (Windows, Linux, and so on) or firmware (IOS, VxWorks, and so on) that are also widely known to be vulnerable to a plethora of newly discovered vulnerabilities each day. It goes without saying that if the underlying operating system can be compromised, then any of these components is at risk for affecting your VoIP applications as well. The most vulnerable support components are typically the TFTP, DHCP, DNS, and authentication servers.