Defenses against DHCP attacks

After reading @chemaalonso‘s post about DHCP Ack Inyector, I remembered my college years back in 2005 when you just needed to go to the library, plug-in your laptop to the network and voilà, just “listening” network traffic you saw all those vulnerable or misconfigured protocols such as STP, HSRP, DTP, etc..

Not only that. There wasn’t any type of control over the information the users could send, and using tools such as Gobbler, dsniff, ettercap, yersinia, etc., you could perform any man-in-the-middle attack. The most interesting part was that the networking devices used for traffic management were almost entirely Cisco. I.e. devices fully able to control and mitigate virtually most of these attacks, but that were configured to perform basic networking functions: routing, VLANS, ACL, QoS, etc. Either because of ignorance or carelessness, they were not being taken the performance that actually justified his acquisition.

Over time I have realized that this situation is quite common: it is really hard to find a company with strict configuration policies to secure the local network environment. I personally think that many organizations are unaware of the damage that a disgruntled employee could do in a network “poorly controlled”. Without using any sophisticated tools like Loki or Yersinia, it is possible to bring down an entire network with just a couple of packets. Using Scapy, you can perform MitM using ARP / DHCP / VRRP / HSRP or without much effort even more entertaining things like getting a pool of shells with Metasploit browser_autopwn and etterfilters.

In this case, following Chema’s post, I would like to address certain security measures, well known for some time that would help protect against tools like DHCP Ack Injector and other tools that do a misuse of the DHCP protocol (IP Spoofing Attacks, Discover DoS attacks, etc.). As stated in his blog, DHCP Ack Injector behaves somewhat different from tools like Ghost Phisher or any other fake DHCP server that could be installed (dhcp3, auxiliary / server / dhcp in Metasploit, etc.) to send false information to the DHCP client. Instead of using packets DHCPOffer, it uses DHCPAck that has the added advantage of knowing the data previously provided by the server, obtained thanks to the DHCPRequest broadcast emitted by the victim, a pretty clever technique.

However this it is not enough to avoid VACLs (VLAN Access List) that control UDP traffic directed to ports 68 and 67, or more serious countermeasures implemented such as DHCP Snooping, implemented in Cisco devices. In the first case, any switch that supports VACL could be configured to block UDP traffic coming from port 67 for those ports whose destination is the end user. The problem with this countermeasure is that can be evaded just spoofing the MAC and IP of the packets (what it is possible in the case of DHCP Ack Injector). For a more reliable protection we need to use other security mechanisms such as DHCP Snooping.

The idea of this feature is to differentiate between two types of ports in a switched environment: a reliable port side (trusted port) and, secondly, untrusted ports (untrusted host). The first have no restrictions on the type of DHCP messages that can receive, as they will be those connected to a controlled environment (in this case the server / DHCP servers). However, the latter can only send those packets that under normal conditions a client needs to send to get its DHCP configuration (DHCPDiscover, DHCPRequest, DHCPRelease). Therefore, the untrusted ports will correspond to those ports connected to end users, and in the case that one of those ports receives a spoofed DHCPoffer packet, a DHCPack or DHCPNack (this is the case of DHCP Ack Injector), it will be blocked.

To carry out this process, the switch maintains a table (binding table) that it is will built as it receives the information from the legitimate DHCP server during the clients negotiation (although it is also possible to automatically add entries; see ip dhcp snooping command). This table stores the following information related to the untrusted ports: MAC address, IP address, lease time, binding type, VLAN, and interface. This information may also be used by other security features such as DAI (Dinamic Arp Inspector) to mitigate arp-spoof or IP Source Guard that will be discussed later. Here is a sample configuration:

Switch(config)# ip dhcp snooping
Switch(config)# ip dhcp snooping vlan 10
Switch(config)# interface Fastethernet 0/5
Switch(config-if)# ip dhcp snooping trust
Switch(config-if)# ip dhcp snooping limit rate 10

Switch# show ip dhcp snooping
Switch DHCP snooping is enabled
DHCP snooping is configured on following VLANs:
10
Insertion of option 82 is enabled
Interface                    Trusted     Rate limit (pps)
------------------------     -------     ----------------
FastEthernet0/5              yes         unlimited

Binding Table:

Switch#show ip dhcp snooping binding
MacAddress          IpAddress        Lease(sec)  Type           VLAN  Interface
------------------  ---------------  ----------  -------------  ----  --------------------
00:01:02:03:04:05   10.0.0.1         86250       dhcp-snooping  10    FastEthernet0/5

DHCP Snooping allows not only to mitigate such attacks (rogue server), but also to defend against DHCP exhaustion attacks, where an attacker is able to finish with the pool of free addresses of the DHCP server in seconds, by sending DHCP Discover packets requesting new IP addresses.

Although one might think that countermeasures such as as Port Security would be more than enough to prevent such attacks, that is not true with tools like Yersinia or dhcpstarv. This is because Port Security only considers the MAC source of the frame to create filters and then set accordingly what MAC addresses are allowed on a specific port (useful against MAC flooding attacks). The problem here is that these tools do not change this MAC (as eg macof does), but randomize the field Client Hardware Address (CHADDR) inside the DHCP payload. This field, along with the client identifier, is of great importance as it will be used (see RFC 2131) by the server to distinguish between the various requests of different customers. Without that, it would be difficult to distinguish between the various users when using a DHCP Relay Agent.

If you suspect that there is a misuse of DHCP it is possible to capture traffic within the broadcast domain of the clients, using VACL, port-mirroring, etc.. and then filtering by the DHCPOffer and DHCPAck packets. Let’s see the output generated from Wireshark:

As we can see there are two answers DHCPAck sent almost at the same moment, what is a strange behavior. In the case of DHCP Ack Inyector, for some reason it doesn’t keeps some fields such as “Server Host Name” so it could serve as a filter (bootp.server == "" && bootp.option.type == 03) to seek for suspicious DHCPAck answers.

Finally, it is worth to mention that the binding table generated by the DHCP Snooping can also be used to detect IP Spoofing thanks to IP Source Guard. This feature prevents the equipment connected to untrusted ports to send packets until they dynamically negotiate its IP thru the process of DHCP Snooping, or a static entry is added to the binding table (see command ip verify source vlan dhcp-snooping port-security). Later, once assigned the IP address, an ACL will be applied to that port and any IP packet with a source other than the one stored in the binding table will be deleted.

A Layer 2 device that implement techniques similar to DHCP Snooping, DAI, IP Source Guard, Port Security, 802.1x authentication, can save real headaches to network administrators. The investment in this kind of switch, as long as all these features are really used, is totally justified in an environment in which the security (confidentiality, integrity and availability) information is critical.