WLAN DISCUSSION
 

DHCP Starvation Attacks: Dynamic Threat Update Release Note

DHCP Starvation Attacks: Dynamic Threat Update Release Note

Postby AM_WirelessSecurity » Mon Nov 07, 2011 5:41 pm

Fluke Networks’ AirMagnet Enterprise 9.0 in the only WIPS on the market to support an automated update capability for threat detection signatures, called Dynamic Threat Update (DTU). This allows all users’ systems to be updated in the background to detect the newest WLAN security problems.

Via a new threat signature update, AirMagnet Enterprise now has the ability to detect DHCP Starvation attacks.

Stopping DHCP Starvation Attacks

Wired and wireless networks use the Dynamic Host Control Protocol (DHCP) as an on-demand, as-needed way to allocate available IP addresses to clients. DHCP eliminates manual configuration while enabling shared use of a limited resource. Unfortunately, malicious clients can take advantage of DHCP to launch a denial of service (DoS) attack known as DHCP Starvation.

Using DHCP to DoS a network

Freely-available point-and-shoot hacker tools such as Yersina or Gobbler can easily launch a DHCP Starvation attack against any vulnerable network.

Consider a Wi-Fi hotspot that allocates IP addresses from the subnet 192.168.0.0/24. That hotspot can serve more than 250 users at once by assigning a unique address to each newly-connected DHCP client. These addresses are said to be leased because the network essentially loans IPs to clients, usually for a finite period – perhaps one hour or one day.

After every available IP address has been leased, the DHCP “pool” is exhausted. Even if other clients connect, they will be unable to lease an IP address to send TCP/IP traffic. The hotspot is therefore unavailable to new clients until existing leases expire or existing clients release addresses. As long as the pool is large enough and each client takes just one address, DHCP works well.

Unfortunately, DHCP cannot stop a single hacker from consuming the entire pool. A hacker need only generate a large number of spoofed DHCP requests, each sourced from a different MAC address. Tools like Yersina can easily generate and send hundreds of DHCP requests from random MAC addresses, thereby exhausting an address pool and starving other legitimate clients.

Using authentication to stop DHCP Starvation attacks

Note that a client must connect to a network before it can send DHCP requests (legitimate or otherwise). One basic way of stopping DHCP Starvation attacks is therefore to prevent hackers from connecting. In a wireless network, this can be done by requiring robust authentication and encryption – specifically, WPA2-Enterprise (802.1X) or WPA2-Personal (PSK) with strong user credentials. Unless the hacker cracks the PSK or knows user passwords, he will not have the crypto keys needed to send correctly-formed DHCP requests containing random MAC addresses.

Unfortunately, this tactic cannot be applied to open or group shared key wireless networks, such as those used to carry guest Internet traffic or commercial Wi-Fi hotspot services. Even in a hotel or office, which changes its guest PSK every day, the fact that every guest uses the same PSK leaves the network vulnerable to DHCP Starvation. Consequences can range from lost productivity for visitors and contractors who depend on the guest WLAN to lost revenue for a commercial hotspot provider.

Deterring DHCP Starvation in hotspots

Simply enlarging a hotspot’s address pool or shortening lease time cannot stop this attack; hackers can easily generate spoofed DHCP requests very quickly.

Rate-limiting the number of DHCP requests accepted from a specific switch port or AP can help. While dropping excess requests can slow a DHCP Starvation attack, this may have unintended side effects such as blocking legitimate users during busy periods. Also, dropping DHCP requests could give an attacker with a phony DHCP server a chance to respond to legitimate client requests, thereby maliciously redirecting traffic.

A more effective method can be to verify that the sending device’s MAC address matches the MAC address carried inside the DHCP request. For example, Ethernet switches may check for this when “DHCP snooping” is enabled. However, clients can still send spoofed DHCP requests that carry the same MAC address in both fields.

Ultimately, network operators should monitor the air for DHCP Starvation attacks. Only by reliably recognizing that an attack is underway can appropriate steps be taken. A Wireless IPS such as AirMagnet Enterprise can combine traffic analysis with spatial awareness to conclude that a hacker’s device is responsible for sending a large volume of spoofed DHCP requests. A WIPS can not only alert administrators to this kind of active DoS attack, but map the hacker’s location to enable physical intervention.
AM_WirelessSecurity
Trial Account
 
Posts: 12
Joined: Fri Apr 29, 2011 9:35 am

Re: DHCP Starvation Attacks: Dynamic Threat Update Release Note

Postby LPhifer » Tue Nov 22, 2011 9:18 am

Denial of Service attacks can be tricky to detect accurately and mitigate efficiently, whether they exploit PHY/MAC layer vulnerabilities or try to exhaust network resources (as DHCP starvation attacks do).

PHY layer DoS "attacks" are very often not malicious attacks at all, but rather competition for scarce RF resources. Recall the now-infamous Apple WWDC 2010 keynote where Steve Jobs had to ask the audience to disable personal Wi-Fi devices so that he could finish his iPhone4 demo. New 5GHz-capable clients can escape to cleaner air, but personal hotspots, Windows 7 virtual APs, and a plethora of Wi-Fi enabled consumer electronics are making "accidental DoS attacks" more frequent, raising the stakes on accurate detection. But this does not mean ignoring non-malicious interference; it means putting interference into context and delivering actionable information (such as interferer type and location).

Accidental DoS differs from MAC protocol-based DoS attacks that have long been detected using rate and state-based WIPS signatures. Examples include 802.11 Control frames used to "busy out" a channel (Queensland DoS), 802.11 Deauthenticate floods used to disconnect one or all stations, 802.11 Associate floods used to busy or crash APs, and spoofed Block Acknowledgement frames used to interfere with 11n high-throughput stream delivery. 802.1X packet floods and crafted frames can also be sent to exploit 802.1X DoS vulnerabilities, including EAP Logoff Floods, EAP Start Floods, and EAP-of-Death attacks. In recent years, these generic attacks have been joined by client-specific attacks which exploit device and driver bugs to cripple or crash hosts. While protocol-based DoS attacks may be easier to recognize accurately, the challenge is keeping up with flaws in new devices so that vulnerabilities can be eliminated prior to exploit.

And then there are the many MANY DoS attacks that can be launched against networks by taking advantage of Wi-Fi as a convenient and perhaps less-well-guarded entry point. Many higher-layer protocol DoS attacks can be detected by wired network IDS/IPS. But sometimes -- as in DHCP Starvation -- the attack is aimed at WLAN infrastructure or resources. A wired network IDS/IPS sensor located inside the corporate network may never see network-edge attacks -- and of course could not help to physically locate Wi-Fi senders like a WIPS can. Detecting these DoS attacks over-the-air gives the network operator a chance to harden WLAN resources and shut down entry points to avoid future incidents.

In short, wireless DoS attacks come in many different forms. Recognizing this is important both to enable early accurate detection and to facilitate efficient business-appropriate risk mitigation. Anyone involved in wireless vulnerability assessment should examine a variety of DoS attack types and vectors, identifying configuration changes or firmware/driver updates that can reduce vulnerability while verifying IDS/IPS visibility and response.
-- Lisa Phifer
User avatar
LPhifer
Registered User
 
Posts: 169
Joined: Fri Jun 25, 2010 10:42 am
Location: Pennsylvania, US


Return to WLAN Security



Who is online

Users browsing this forum: No registered users and 1 guest

 

 

 

 
Read
»
Whitepaper: WLAN Design and Site Survey
 
»
Site Survey Check List
 
»
802.11n Reference Guide
 
Watch
»
RF Basics
 
»
Planning for 802.11n
 
»
Voice-over-Wireless Best Practices
 
 
Home  |  Security Center  |  All Things Wi-Fi  |  Blog  |  Library  |  AirMagnet.com  |  FlukeNetworks.com
© 2006-2013 Fluke Corporation. All rights reserved.