Straight from the horse’s mouth: 802.11-2007 on ARP Spoofing July 29, 2010
Posted by Matthew Gast in : security, wireless ARP spoofing , trackbackFirst of all, I’d like to thank Devin for letting me guest blog here. For an introduction, I’m the Director of Product Management here at Aerohive, where I lead development of HiveOS, the operating system on our APs.
Obviously, a big part of what we do at Aerohive is design and build Wi-Fi APs. One of the ways I contribute to that effort is by participating in industry organizations. At the Wi-Fi Alliance, I serve as chair of the Security Technical Task Group and vice chair of the Security Marketing Task Group. Before joining Aerohive, I was chair of 802.11 Task Group M, which was producing the 802.11 revision due in 2011. (I had to give up leading TGm when I joined Aerohive because I just didn’t have the time because there are only 24 hours in my day.) You may have also read one of my books…
This has been an “interesting” week for me because I’ve been having almost non-stop conversations with people about Wireless ARP Spoofing (originally published as “hole 196″). I’m going to be writing a series of posts for the blog here about ARP spoofing, starting with the standards background, diving deeper into technical details, and highlighting other works worth reading as they come out. This post is only the first in a series.
I’ll start with a warning on this post. I wanted to start off by talking about what the 802.11 specification says about ARP spoofing. As a result, this post is going to be one of the most wonkish and technical that I’ve ever written – I’ll be quoting liberally from the specification. If you’d like to follow along at home, visit Get802 and grab your very own PDF copy of 802.11-2007.
The Wireless ARP Spoofing attack depends on the ability of any device to use the broadcast key to send an ARP packet as a vector to redirect traffic. The reason it was initially dubbed “hole 196″ is that there is a sentence on page 196 about the ability of any device authorized to use a network to forge ARP frames.
The purpose of this post is to quote the specification directly regarding the protection offered by the broadcast key mechanism, and show that any time you have a symmetric key (not a public/private key pair), it is difficult to maintain security. I’m not going to get into the effects of the attack in this post, but I’ll talk about that in the future.
First, there’s the famous part of the specification, on page 196:
8.5.1 Key hierarchy [ this is on page 196 – mg ]
RSNA defines two key hierarchies:
a) Pairwise key hierarchy, to protect unicast traffic
b) GTK, a hierarchy consisting of a single key to protect multicast and broadcast traffic
NOTE—Pairwise key support with TKIP or CCMP allows a receiving STA to detect MAC address spoofing and data forgery. The RSNA architecture binds the transmit and receive addresses to the pairwise key. If an attacker creates an MPDU with the spoofed TA, then the decapsulation procedure at the receiver will generate an error. GTKs do not have this property.
For the last week, the most quoted sentence of the specification is the last six words, but it’s hardly a secret that the GTK does not provide source address authentication. For example, there’s the introductory material in clause 5, which provides an overview of the entire standard. At the bottom of page 38, it reads (emphasis mine):
5.4.3.5 Data origin authenticity [ this is on page 38 – mg ]
The data origin authenticity mechanism defines a means by which a STA that receives a data frame can determine which STA transmitted the MAC protocol data unit (MPDU). This feature is required in an RSNA to prevent one STA from masquerading as a different STA. This mechanism is provided for STAs that use CCMP or TKIP.
Data origin authenticity is only applicable to unicast data frames. The protocols do not guarantee data origin authenticity for broadcast/multicast data frames, as this cannot be accomplished using symmetric keys and public key methods are too computationally expensive.
Finally, you can look at the assumptions that went into the construction of the Robust Security Network Architecture (RSNA), which was the security protocol defined in the 802.11i amendment in 2004. Towards the bottom of page 157, the spec reads (once again, emphasis mine):
8.1.5 RSNA assumptions and constraints [ page 157 – mg ]
h) The destination STA chosen by the transmitter is the correct destination. For example, Address Resolution Protocol (ARP) and Internet Control Message Protocol (ICMP) are methods of determining the destination STA MAC address that are not secure from attacks by other members of the ESS. One of the possible solutions to this problem might be for the STA to send or receive only frames whose final DA or SA are the AP and for the AP to provide a network layer routing function. However, such solutions are outside the scope of this standard.
To say that the specification had a “little-known vulnerability” regarding group keys is an overstatement. Nearly 40 pages prior to the sentence that has been quoted so liberally, the authors of the standard admit that ARP is not secure.
Thanks to Henry Ptasinski (Broadcom) and Nancy Cam-Winget (Cisco) for identifying relevant pieces of the specification.
Comments»
Dear Mathew,
I don’t think there was ever any disagreement about how well documented the WPA2 GTK vulnerability (so called Hole196) was in the IEEE 802.11 standard. We were the first ones to say that openly in the public (press release, dated July 22) and even referred to the page number and the line in the standard document.
But I’m afraid being well documented in the standard is one thing and being “well known” to the user community is another. Even a Wi-Fi expert and veteran like Devin Akin, in his post on this blog (dated July 22), attributed it as a “nice find.” So it’s too much to expect the WLAN user community at large to already know this. The amount of discussion (must say, a little unexpected!) this revelation has triggered is a proof in itself of how “well known” or “little known” was this vulnerability in the Wi-Fi user community.
Our purpose in demonstrating a practical exploit on this vulnerability was to create that public awareness.
Best regards,
[...] Aerohive’s Matthew Gast, who’s also chairman of the Wi-Fi Alliance’s Technical Security Working Group thinks: “To say that the specification had a “little-known vulnerability” regarding group keys is an overstatement. ” http://blog.aerohive.com/blog/?p=362 [...]