AirTight Networks says it's found a weak point in Wi-Fi Protected Access 2 (WPA2), the mainstay of enterprise Wi-Fi security. But has it? Security expert Matthew Gast says the attack seems to be a familiar ARP spoofing exploit that works as well on wired as wireless LANS. If so, it can easily be contained.
So this guy at AirTight Networks says Wi-Fi Protected Access 2 has a "hard shell on the outside, but a soft underbelly inside"due to an overlooked vulnerability, and an attacker can decrypt traffic that's been encrypted with WPA2. Is this total panic time?
Well, probably not, based on tentative conclusions from folks who've been trying to figure out what's going on from the very limited information AirTight Networks has released so far.
(See "WPA2 vulnerability found".)
The Wi-Fi Alliance crafted WPA2, based on the IEEE 802.11i specification. Do they have a response to AirTight?
Not yet. A spokesman says they're waiting for the details from the Black Hat conference in Las Vegas. (AirTight will reveal full details of this exploit Thursday afternoon, July 29, during a presentation at the event.)
What actually is going on?
Apparently -- and this is important -- nothing new.
That's according to 802.11 security expert Matthew Gast, who's written "802.11 Wireless Networks: The Definitive Guide" from O'Reilly Media, and is a voting member of the IEEE 802.11 working group, chair of the Wi-Fi Alliance's Security Technical Task Group, and director of product management at Aerohive Networks.
Gast says his best guess -- at this point -- is that the AirTight exploit is Address Resolution Protocol (ARP) spoofing, a "man in the middle attack." According to Wikipedia. "Generally, the aim is to associate the attacker's MAC address with the IP address of another node (such as the default gateway). Any traffic meant for that IP address would be mistakenly sent to the attacker instead.”
That's what appears to be happening in the AirTight exploit, according to Gast. "The ARP spoofing is when the attacker rewrites the MAC address of the default router," he says. "To do that, it masquerades as the AP. Think of the attack as having two components, since you are operating at both Layer 2 (Wi-Fi) and Layer 3 (IP/ARP). The Layer 3 component is well understood; the Layer 2 component is just the way that you transmit the Layer 3 attack on Wi-Fi as opposed to Ethernet.”
ARP spoofing is not unique to WPA2. "If you replace the wireless access point with a switch, and all the wireless connections with Ethernet cables, the [AirTight] attack would still work," Gast says.
Secondly, in this exploit the attacker has to be an authorized user on the wireless network, not some passerby, and both attacker and the victim have to be connected to the same wireless LAN -- the same SSID on the same access point, according to Gast.
Third, the attacker does not actually recover, break or crack any WPA2 encryption keys, according to Gast.
And finally, check to make sure something called "client isolation" is turned on in your access points. If it is, it will disrupt the attack.
What's client isolation?
It blocks two wireless clients attached to the same access point from talking with each other, because the access point refuses to forward traffic from the victim to the attacker, which is critical to the success of this attack. According to Gast, nearly every WLAN vendor implements this feature.
I'm breathing again. How does this attack work?
Again, this is still informed guesswork at this point. Picture a WLAN access point, connected to a corporate network. An authorized wireless client, say a laptop dubbed the Victim, connects to it as per usual. Then another client, the Attacker, connects to the same access point, also as a valid, fully authorized user; in other words, an employee.
Like the Victim, Gast says, the Attacker goes through a normal authorization process and ends up with two sets of encryption keys. One is called the Pairwise Transient Key (PTK), which is used only between the one client and the access point to authenticate whichever one is transmitting. The second is the Group Temporal Key (GTK), which is shared between the access point and all the clients associated to it, to authenticate broadcast messages.
What happens next?
"The fundamental attack is still the traffic redirection made possible by ARP spoofing," Gast says. "The only reason you are able to redirect the traffic is because you are really exploiting the fundamentally trusting nature of ARP."
Meaning, the Attacker masquerades as the access point, and the Victim accepts it as such.
So the Victim thinks the Attacker is a legit access point. And then?
The Attacker says, "I have a new default router for you." Which turns out to be: the Attacker device.
The Victim accepts the change. The next frame it sends, per usual, goes to the original bona fide access point, where it's encrypted, also per usual, with the pairwise key shared by the Victim and the access point. Everything is normal. Then the access point says "I have a frame, and a destination for it. I'll send this frame to the destination." But now, the destination is the Attacker, the Victim's "new default router."
WPA2 is still secure. Up to this point, the attacker has no way of reading what's been encrypted between the Victim and the access point.
Then how does the Attacker work it?
This is actually pretty neat, but again it doesn't appear to be a weakness in WPA2: the access point then uses the valid pairwise key associated with the Attacker, which is an authorized device on the network, to encrypt the frame received from the Victim and send it on to the presumably authorized destination. As Gast says, "There's nothing untoward for the access point to pick up [on]."
The Attacker receives the frame and can decrypt what's in it, because it already has the valid, functioning key to do so: the key it obtained from that access point when the Attacker was authorized originally.
That's…evil! So, everything works as it should, except it's undermined by the fact that the Attacker is successfully impersonating this default router?
Right. If the Attacker is smart, it really will impersonate the router, to delay detection. For example, the Victim requests www.networkworld.com; the Attacker fetches the page and then returns it to the Victim. If it doesn't, from the Victim's viewpoint the WLAN has stopped working, a call gets placed to the IT help desk, and smart people start looking for a problem.
So what does Gast recommend in terms of mitigation?
The first thing is what he calls "The Apprentice Mitigation," using Donald Trump's signature line on "The Apprentice" TV show: "You're fired."
The nature of the attack means there would be multiple IP addresses from a single MAC address. "I'm pretty sure that is an alarm [condition] in many IDSs [intrusion-detection systems]," Gast says. Associated with the MAC address is a user ID.
I like that one. What else?
The immediate technical countermeasure for this type of attack is the use of the access point's client isolation feature: the access point won't let the Victim talk to the Attacker. From the Victim's viewpoint, Gast says, the network connection would fail, and the "fingerprint" of the Attacker would remain. See mitigation No. 1, above.
The attack seems to have a limited scope. "The attack requires that the [encryption] key be shared," Gast says. "Keys are not shared across BSSIDs (sometimes called 'virtual access points'), so the attack only works for clients connected to the same SSID on the same AP."
Similarly, segmenting different groups of users onto different virtual WLANs would prevent anyone in one group using the attack for members of another group. Suppose a university groups faculty and staff on one BSSID, students on another, and visitors on a third. The students will not be able to use the AirTight exploit against their teachers.
Last, and certainly not least, once details of the exploit are made public on Thursday, we can expect WLAN vendors to respond quickly to address any problems.
Can I have a beer now?
I'll join you.
John Cox covers wireless networking and mobile computing for "Network World."
Blog RSS feed: http://www.networkworld.com/community/blog/2989/feed