More WPA2 Hole 196 Reflections and TCP/IP Stack (Mis)Behaviors

This year I had the opportunity to gather the details of the latest vulnerability in Wi-Fi technologies before it's announcement during the BlackHat and DefCon conferences, dubbed "(WPA2) Hole 196", however at that point, I didn't have the time to analyze it and publish the details. I always like to perform an in-depth analysis and share my comments on the current Wi-Fi security threats, as I did during the last years in our original RaDaJo blog with the PTW WEP cracking attack (104 & 40-bit), WEP cloaking, autoimmunity disorder in WLANs or the WPA/TKIP ChopChop attack. (WPA2) Hole 196 couldn't be left apart!

My last WPA/TKIP ChopChop attack analysis emphasized the temporary nature of TKIP, recommending WPA2/AES as the reference security technology for Wi-Fi networks. However, the first well-known vulnerability for WPA2-Enterprise has been released. During BlackHat and Defcon 2010, MD Sohail Ahmad senior wireless security researcher from AirTight Networks, presented "WPA Too!", demonstrating an inherent flaw in the design of WPA(2). Apart from the original presentation, whitepaper, blog post, webinar and FAQ, there is a great analysis by Glenn Fleishman available here.

So, let's start this quick analysis emphasizing a security principle the infosec industry does not fully assimilate yet: "If something is shared, it cannot be secret" ;) Hole 196 exploits this principle attacking the GTK, the Group Temporal Key shared by all Wi-Fi clients to exchange broadcast and multicast traffic. This principle is also what makes WPA(2)-PSK solutions vulnerable, as the Pre-Shared Key is known by all Wi-Fi clients, so any legitimate user can easily decrypt the Wi-Fi traffic from other users.

Why "Hole 196"? Because it exploits a security weakness in the GTK pointed out on page 196 of the current IEEE 802.11-2007 specification. As this is a design flaw, fixing Hole 196 will require an update to the current IEEE 802.11 spec.:

To sum up, I agree with my friend Josh Wright that this new vulnerability won't make people to switch off their Wi-Fi networks (as WEP flaws did a few years back). What makes this finding more interesting is that it affects the most secure Wi-Fi environments nowadays, those based on WPA2/AES-Enterprise (802.1X). To put things in context, there are still thousands, or even millions, of Wi-Fi deployments that are based on WEP or WPA(2)-PSK vulnerable to much more relevant flaws than this one.

(My personal) Hole 196 reflections:

• All WPA and WPA2 environments, independently of the encryption technology used (TKIP or AES) or the authentication method (Personal, PSK or Enterprise, 802.1X) are vulnerable. Hole 196 is particularly relevant on WPA2/AES-Enterprise.
• Hole 196 is an insider attack, meaning the attacker needs to be a legitimate Wi-Fi user to get access to the GTK. It therefore affects security conscious organizations concerned about the insider threat (unfortunately, still today not everybody is concerned) or the few Wi-Fi hotspots based on WPA(2)-Enterprise (where other legitimate users are not trusted users implicitly).
• It allows stealthier ARP poisoning (MitM) attacks, as the malicious ARP frames won't be seen on the wired network segments and, therefore, on a wired IDS/IPS. This could be a good reason for security conscious organizations, already using WPA2-Enterprise, to deploy a wireless IDS (WIDS).
• An attacker can use ARP poisoning techniques to get access to (decrypt) other users Wi-Fi traffic, as in a default WPA(2)-PSK setup or wired LAN, manipulate that traffic, or launch DoS attacks. Less-stealthier ARP poisoning attacks are possible on any Wi-Fi network (not just through Hole 196), and quite honestly, still today lots of organizations are unable to detect ARP poisoning attacks on their networks (LAN or WLAN) or even enforce secure wired or wireless network access through 802.1X authentication.
• A new kind of DoS is possible through Hole 196 by increasing the value of the packet number (PN) field, used by WPA2 to detect replay attacks. This attack joins the long list of Wi-Fi DoS attacks still possible today.
•  In essence, Hole196 allows the injection of fake broadcast or multicast frames in the Wi-Fi network that all users will accept as legitimate. Therefore, an attacker can launch any kind of attack that implies the usage of broadcast or multicast traffic at layer 2, being ARP poisoning the best example. This is what the FAQ refers to as "Other attacks such as port scanning, exploiting OS and application vulnerabilities, malware injection, DNS manipulation, denial of service, etc. are possible by misusing GTK."

In the absence of a WIDS, client-based detection capabilities are specially relevant to detect ARP spoofing attacks launched through Hole 196. This opens the door for a future blog post focused on analyzing nowadays ARP poisoning detection solutions on the client side (and in case you ask, Snort is not a client side solution for me), such as arpwatch by LBNL (already analyzed in 2003 on my "Real Worl ARP Spoofing" GCIH paper), DecaffeintID by IronGeek (Windows) or XArp by Christoph P. Mayer (Windows and Linux). What are the solutions available for other Wi-Fi clients, such as mobile devices?

Hole 196 has favored new research focused on how the current TCP/IP stacks behave and respond to layer 3 (IP) unicast packets encapsulated in layer 2 (802.11 or Ethernet) broadcast or multicast frames. Josh opened Pandora's box on his Packetstan blog post. Although still it is not clear how this misbehavior can be fully exploited on any network, apart from bypassing layer-2 filters, it is particularly relevant for one-way attacks on Wi-Fi PSPF (Publicly Secure Packet Forwarding, aka "client isolation") environments through Hole 196.

Following Josh research, I did a few extra tests with OS & platforms, and (in particular) mobile devices common in Wi-Fi networks, and confirmed the following facts:

• Josh mentioned Windows Vista and 7 accept LAN broadcast traffic sent to unicast IP addresses. I confirmed that Windows Vista SP2 under VMware Fusion 3.1.1 (LAN) in fact does accept this kind of traffic for ICMP, TCP or UDP for broadcast and multicast layer-2 addresses. The most surprising fact is that Windows Vista and 7 accept TCP broadcast traffic. New TCP/IP stack implementations can always include hidden gifts!
• Windows XP SP3 (WLAN) does not accept it for any of the protocols (ICMP, TCP or UDP), no matter the layer-2 address used, broadcast or multicast. So, does this mean XP is "more secure regarding Hole 196" than Vista & 7? ;)
• Linux 2.6 (2.6.30.9), for the records running inside VMware 6.5.4 (LAN), accepts both broadcast and multicast traffic for ICMP and UDP. It rejects it for TCP. From a layer 2 vs. protocol perspective it makes sense, as ICMP and UDP protocols can make use of broadcast and multicast communications, while TCP cannot. However, the key question about this misbehavior is: should the layer 3 address be verified against the layer 2 address by the OS TCP/IP stack before processing a frame/packet?
• iPhone 3.1.3 and 4.0.2 (WLAN) accept both broadcast and multicast traffic for ICMP and UDP, but rejects both layer-2 addressing types for TCP, like Linux 2.6.
• Mac OS X 10.6.4 (WLAN) again behaves similarly to Linux 2.6, only accepting both broadcast and multicast traffic for ICMP and UDP.
• Windows Mobile 6.1 and 6.5 behave as Windows XP, not accepting this kind of traffic for any of the protocols (ICMP, TCP or UDP) no matter the layer-2 address used, broadcast or multicast.

If you are interested on testing this kind of misbehaviors, you can use Josh's suggested packet crafting technique based on Python and Scapy (for ICMP, TCP & UDP) on various platforms, including the standard Backtrack 4 Final VM I used for these tests (with Scapy v2.1.0), or a simpler multi-platform method (Windows, Linux & Mac) based on creating a static entry on the local ARP table using a broadcast or multicast layer-2 address, and generating traffic against the associated layer-3 address through ping (ICMP) or netcat (TCP & UDP).

Example of an ICMP echo request packet addressed ("dst=") to a multicast layer-2 address and unicast layer-3 address in Scapy:

>>> p = Ether(dst="01:00:5e:00:00:01", src="00:0c:29:01:02:03", type=0x800)  >>> p /= IP(src="192.168.100.2",dst="192.168.100.1")  >>> p/= ICMP()  >>> srp1(p) Begin emission: Finished to send 1 packets. * Received 1 packets, got 1 answers, remaining 0 packets <Ether dst=00:0c:29:01:02:03 src=00:0a:0b:0c:0d:0e type=0x800 | <IP version=4L ihl=5L tos=0x0 len=28 id=741 flags= frag=0L ttl=128 proto=icmp chksum=0x2877 src=192.168.100.1 dst=192.168.100.2 options=[] | <ICMP type=echo-reply code=0 chksum=0xffff id=0x0 seq=0x0 |<Padding load='\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00' |>>>>

For TCP & UDP packets replace the "ICMP()" line above with the appropriate line:

>>> p /= TCP(sport=65000, dport=196)     >>> p /= UDP(sport=65000, dport=196)

Example of Linux/Mac & Windows ARP static entry to associate a multicast layer-2 address to a unicast layer-3 address. All local traffic sent to the unicast layer-3 address will use the multicast layer-2 address. Don't forget to delete the new ARP entry (-d) when the tests are finished :)

# Linux/Mac $ sudo arp -s 192.168.100.1 01:00:5e:00:00:01 $ arp -an ? (192.168.100.1) at 01:00:5e:00:00:01 [ether] PERM on eth0      $ sudo arp -d 192.168.100.1

# Windows C:\>arp -s 192.168.100.1 01-00-5e-00-00-01 C:\>arp -a Interface: 192.168.100.2 --- 0x4   Internet Address      Physical Address      Type   192.168.100.1         01-00-5e-00-00-01     static

For general operating systems, before testing, double check that the target TCP/IP stack, and associated personal firewall, allows the ICMP, TCP & UDP traffic used for the analysis (for example, using layer-2 & layer-3 unicast packets) and don't forget to launch the TCP & UDP listeners:

# TCP listener (you might need to manually close it after the incomplete  # SYN/SYN-ACK exchange when using the Scapy packet crafting technique): $ echo "hole 196" | sudo nc -l -p 196 # UDP listener: $ echo "hole 196" | sudo nc -u -l -p 196

NOTE: It would be more secure not to use 196 as the target port (Hint: root level required if port <=1023).

For mobile or embedded devices, where netcat cannot be used, you need to identify first an open TCP & UDP port that replies to standard unicast traffic. Remember that for UDP you also need to send a properly formatted packet to the target service in order to force a valid reply (Hint: ARP static entry & "nmap -n -Pn -sU -sV -p5353,137 192.168.100.1").

Definitely, more research is needed if a relevant exploitation vector for this misbehavior is found, including the analysis of both broadcast and multicast packets, covering all interfaces (WLAN and LAN) just in case the TCP/IP stacks behave differently, and considering all kind of Wi-Fi clients such as mobile devices, printers, multimedia disks, etc. Anything with a TCP/IP stack should be part of this extended research. BTW, for the layer 2 multicast address I used 01:00:5e:00:00:01, that corresponds to 224.0.0.1 (all systems on this subnet, IANA). If you test other platforms or have exploitation ideas, please share them in the comments section below, or send me an e-mail.

I will cover Hole 196 as part of an in-depth technical look at the current state of Wi-Fi (802.11) security and the still today prevalent and cutting-edge Wi-Fi vulnerabilities and countermeasures, on my "Wi-Fi (In)Security: All Your Air Are Belong To..." talk during the GOVCERT.NL Symposium on November 16, 2010, in The Netherlands.

NOTE: The image above belongs to the Great Blue Hole of Belize, in the Lighthouse Reef atoll, a legendary 125 meters deep underwater sinkhole.
Another awesome Taddong-related place!