Message-ID: <E0C192F9-7E00-4524-B635-5BECAA3E5B67@matasano.com>
Date: Tue, 17 Jan 2006 15:21:55 -0500
From: "Dino A. Dai Zovi" <ddz@...asano.com>
To: bugtraq@...urityfocus.com
Subject: Attacking Automatic Wireless Network Selection


Hello BUGTRAQ,

Simple Nomad recently discussed issues with Windows XP creating Ad- 
Hoc wireless networks at this year's ShmooCon.  There are, however,  
many more similar and more serious problems with how Windows and  
MacOS X locate and automatically join wireless networks.  These have  
been publicly discussed and demonstrated before, but do not seem to  
have been given the attention needed as many security professionals  
are still unaware of the risks they present.

Simple Nomad's work illustrated the problem when an ad-hoc network  
was present the Preferred Networks list used by Windows XP's Wireless  
Auto Configuration service (MacOS X has an similar list of "Trusted  
Wireless Networks").  In fact, Windows and MacOS X probe for *every*  
network in the preferred/trusted networks list upon boot up and  
waking from sleep.  Under Windows, the entire list is probed for  
continually when the machine is not currently associated to a  
wireless network.  In addition, any network joined is automatically  
added to the top of this list (MacOS X only adds the network to the  
trusted networks list if the user elects to do so when joining the  
network).  Some wireless adapters, notably most 802.11b-only cards,  
will automatically probe for randomly generated network names.  All  
of these behaviors can be taken advantage of by a nearby attacker.

To that effect, I would like to introduce KARMA [1], written by Shane  
"K2" Macaulay and myself.  Our paper, "Attacking Automatic Wireless  
Network Selection" [2] describes serious vulnerabilities in how  
wireless networks are identified and automatically joined by Windows  
XP and MacOS X workstations.  These vulnerabilities may cause nearby  
wireless clients to inadvertently and automatically join a rogue  
wireless network.  KARMA is a proof-of-concept toolkit that  
demonstrates the risk of these vulnerabilities through a patch to the  
Linux MadWifi driver and client-side exploit toolkit.

Our driver responds to EVERY Probe Request as it operates in HostAP  
mode.  The wireless network is "cloaked", so it does not send out any  
beacons, but when a client in range sends a Probe Request for a  
network ("tmobile", "linksys", "megacorp", etc), the driver will  
respond as if it were that network.  In this way, it acts as a  
virtual AP for any network requested.  This yields an extremely  
effective attack that is able to cause nearly all unassociated  
wireless clients within range to join the rogue network.  KARMA also  
includes a tool for passively monitoring probe requests sent out by  
nearby wireless clients and a framework for exploiting client-side  
vulnerabilities once the client has joined the rogue network (no live  
exploits are included, though).

For example, we demonstrated this attack during our presentation at  
Microsoft's first BlueHat internal security conference.  In a hall of  
400-500 engineers, we hijacked upwards of 100 clients instantly,  
enough that our Linux laptop became unstable from all the wireless  
traffic passing through it.  In practice, since nearly every roaming  
laptop has at least one unencrypted hotspot network in their  
preferred/trusted networks, almost all Windows XP and MacOS X laptops  
are susceptible to this kind of attack.

In addition, our driver uncovered vulnerabilities in drivers for  
802.11b-only cards where they probe for randomly generated network  
names when the card is not associated to a network.  When the KARMA  
driver responds to this probe, the card and host will join the  
network and DHCP an address, etc.  I reported this to both Microsoft  
and Apple in the Spring last year.  Apple has subsequently fixed the  
issue [3] and Microsoft said that a fix would be in the next service  
pack.

Again, this is not entirely new stuff.  Max Moser released his  
HotSpotter [4] tool in April 2004 to create a HostAP based on sniffed  
Probe Requests.  We first released our driver implementing the  
parallel attack in February 2005 at Immunity's Security Shindig in  
NYC.  However, awareness of these issues appears to still be low.

Cheers,

Dino A. Dai Zovi
Matasano Security
ddz@...asano.com
http://www.matasano.com
http://www.matasano.com/log/

References:

[1] - http://www.theta44.org/karma/
[2] - http://www.theta44.org/karma/aawns.pdf
[3] - http://docs.info.apple.com/article.html?artnum=301988
[4] - http://www.remote-exploit.org/index.php/Hotspotter_main

Powered by blists - more mailing lists