The flaws that make WEP vulnerable were documented back in 2001, prompting development of dozens of cracking tools. Until recently, those attacks focused on traffic captured from active networks, requiring proximity to the targeted business. But lately, focus has shifted to off-site clients that are not connected to any network. By exploiting driver flaws, exposed fileshares, and user mistakes, one can easily and invisibly attack Wi-Fi laptops and phones in public venues like airplanes, hotels, and cafes.
This year, insidious new tools like Caffe Latte and Wep0ff have learned how to crack the keys stored on those off-site clients, expanding the reach of WEP crackers far beyond office walls. Now, no matter where employees go, they just might unwittingly “spill the beans” on your corporate WEP key.
Come to me
Most client-side attacks take advantage of two fundamental vulnerabilities:
Wi-Fi clients actively probe for all networks they have associated with in the past. When any AP is found with a known network name (SSID), clients automatically associate to it.
This common-but-promiscuous behavior is the culprit behind well-known evil twin or honeypot attacks we have written about before (see Getting Phished: Why SSID Spoofing Still Matters).
In fact, those older attacks provide the launch pad for new client-side WEP crackers, creating the perfect conditions in which to grab any corporate WEP keys cached by those clients.
Talk to me
All WEP crackers use statistical analysis to guess the key used to encrypt captured traffic. Given enough encrypted traffic, WEP crackers can always derive the key. A WEP-cracking attack therefore starts with locating a source of encrypted packets. It turns out that phished Wi-Fi clients are an awfully convenient and plentiful source.
Specifically, all TCP/IP devices send a least a few packets whenever they connect to a WLAN.
A station using a static IP immediately broadcasts a few gratuitous ARP packets to the entire WLAN. Each ARP packet carries the sender’s MAC address and IP address so that other stations will know how to route traffic.
A station using a dynamic IP also sends ARP, after first requesting an IP address from a DHCP server. If no server is found, the station assigns itself an Automatic Private IP Address from the 169.254.0.0/16 subnet and then sends gratuitous ARP.
Tell me your secrets
If a client associates to an AP that uses WEP, it may or may not be required to authenticate itself before associating, using a shared WEP key. However, the AP is never required to prove that it, in fact, possesses the WEP key. This means that a phony AP (aka evil twin) can be configured with the SSID of a corporate WLAN and any key to lure clients. After a client associates to the phony AP, it will send a few ARP packets—encrypted with the corporate WEP key.
A handful of encrypted ARP packets won’t be enough to crack the corporate WEP key. So something must cause the client to repeatedly send encrypted ARP packets. One approach is to disconnect or deauthenticate the client, over and over again, but that would take a long time.
According to Vivek Ramachandran, co-author of the Caffe Latte attack demonstrated at Toorcon this October, cracking a WEP key this way takes between 1.5 and 6 days, depending upon the client’s use of DHCP. That’s theoretically interesting, but of little practical value, since a true hotspot attack must be completed in a much shorter time period—preferably in the few minutes that it takes to purchase an espresso.
Hurry it up, will you?
Ramachandran and colleague Md Sohail Ahmad decided to search for ways to make the client much more verbose. The Caffe Latte paper that the pair submitted to Toorcon described multiple ways to accelerate this attack.
By applying different WEP cracking techniques (FMS, Korek, PTW) to various frames (DHCP, ARP, 802.11), the authors had managed to bring the average cracking time down significantly. The worst-case configuration (client using static IP and no authentication) ran about nine hours, while the best case (client using DHCP and shared key authentication) took as little as 20 minutes. “That was better, but still not fast enough to be a coffee shop attack,” said Ramachandran.
Then Ramachandran and Ahmad noticed a vulnerability that could be exploited more consistently across every client configuration. Any station that receives an ARP request automatically responds with an ARP reply. It must be possible to generate a valid encrypted ARP request without knowing the WEP key, but how?
Upon connecting, the client transmitted several correctly encrypted gratuitous ARP requests.
An attacker can flip a few bits in one of those captured packets, changing that gratuitous ARP into an ARP request, addressed to the client.
By sending that forged ARP request repeatedly, the client can be stimulated into replying with thousands of correctly-encrypted ARP replies.
The final version of the Caffe Latte tool developed by Ramachandran and Ahmad can use this refined methodology to recover cached 128-bit WEP keys from any client in roughly six minutes.
I’ll tell you no lies
This attack works because not only is WEP vulnerable to statistical analysis, but it does nothing to cryptographically protect packet integrity. In other words, recipients have no way to detect when a valid packet has been captured and replayed, as-is or with modification.
Every WEP-encrypted packet carries a Cyclic Redundancy Check (CRC) that is used to spot transmission errors. But, it has long been known that a sender could change both the data payload and the CRC to create a valid packet. Caffe Latte uses this bit-flipping technique to modify the Sender MAC and Sender IP Address contained in a gratuitous ARP header, turning that captured packet into an encrypted ARP request, addressed to the victim client.
Because the victim cannot tell that those forged ARP requests are bogus, it replies with a WEP-encrypted ARP response, as defined by the ARP protocol. Over and over and over again.
Ramachandran and Ahmad demonstrated Caffe Latte on October 21, 2007, at Toorcon [PPT]. With fellow AirTight Networks employee Rick Farina, they also produced a real-time video of the attack being launched against an Apple iPhone. With their permission, several snapshots from that video appear below to help us illustrate the Caffe Latte attack.
1. Monitor hotspot WLAN traffic to identify potential corporate SSIDs.
2. Start capturing all traffic generated by target clients.
3. Use phony AP with corporate SSID and any WEP key to lure target client.
4. Extract gratuitous ARP Request from capture file.
5. Send ARP Request to Caffe-Latte, generating bit-flipped ARP Request flood.
6. Run Aircrack-NG (or your favorite WEP cracker) on corporate SSID and capture file.
7. After analyzing roughly 55-60K ARP Responses, crack 128-bit WEP key.
“We wanted to educate people by demonstrating that this threat exists,” said Ramachandran. “But we did not want to give a point and click tool to hackers. The best defense is to stop using WEP.”
That is sound advice. But for corporate users, decisions about whether to use WEP are made by the employer not the employee, so individual users should take the following precautions to avoid falling victim to Caffe Latte:
1. Narrow the window of opportunity by disabling Wi-Fi adapters when not in use. Many laptops and other devices now have a physical on/off switch for Wi-Fi. Use it.
2. Reconfigure your client to avoid reconnecting automatically to Preferred Networks. That way, you won’t be tricked into connecting to any AP without your consent, and you will realize that a corporate SSID showing up in a public hotspot is not legitimate. (This is particularly important for iPhone users and other with devices that lack an on/off switch for Wi-Fi.)
3. If manual connection management is too inconvenient, then run a host-resident Wireless IPS. A host WIPS like those described here can profile SSIDs and APs used in specific situations. For example, a “Work” profile could let you connect to your corporate SSID at the office, while switching to a “Hotspot” profile could make sure that you ignore that corporate SSID outside the office.
4. Install the Wireless Client Update for 32-bit versions of Microsoft Windows XP with Service Pack 2 (KB 917021). This update stops clients from probing for Preferred Networks that broadcast their SSIDs when the configuration option “Connect even if the network is not broadcasting” is disabled.
As corporate WLANs migrate away from WEP, what can employers do to deter this attack? Caffe Latte does its dirty work outside the office, well beyond the reach of an Enterprise WIPS. However, there are a few Band-Aids that can be applied to stem the blood loss.
To use a Caffe Latte-cracked WEP key, attackers must determine the geographic location of the corporate WLAN. Opaque (random) SSIDs make that just a little bit harder, although geographic coordinates for many SSIDs can be obtained from WiGLE.net.
WEP key rotation can reduce the time period during which a cracked key remains useful. But realize that someone running Caffe Latte against workers lunching at your local sandwich shop will probably use a cracked key in minutes or hours, not days or weeks.
Never depend exclusively on WEP for network access control or data confidentiality. For example, combine WEP with SSL captive portal or VPN authentication to stop an attacker with your WEP key from entering upstream networks.
Be smart, be safe
Ultimately, the most effective way to neutralize Caffe Latte is to stop using WEP altogether.
Wi-Fi Protected Access uses cryptographic integrity checks to detect bit-flipping. And neither WPA nor WPA2 are directly vulnerable to data key cracking. While not impervious to other attacks, WPA and WPA2 are very strong when used correctly. Even WPA PSK dictionary attacks pale in comparison to the gross simplicity and speed of WEP cracking.
Corporate WLAN administrators have now been warned—again. Hopefully, Caffe Latte will put the final nail in WEP’s coffin, encouraging foot-draggers to finally migrate away from that fatally flawed protocol.
Lisa Phifer owns Core Competence, a consulting firm focused on business use of emerging network and security technologies. She has been involved in the design, implementation, assessment, and testing of NetSec products and services for over 25 years.
This article was first published on WiFiPlanet.com.