Microsoft Windows Wireless Exposure on Laptops

2006.01.14
Risk: High
Local: No
Remote: Yes
CWE: CWE-Other


CVSS Base Score: 7.5/10
Impact Subscore: 6.4/10
Exploitability Subscore: 10/10
Exploit range: Remote
Attack complexity: Low
Authentication: No required
Confidentiality impact: Partial
Integrity impact: Partial
Availability impact: Partial

________________________________________________________________________ _______ Nomad Mobile Research Centre A D V I S O R Y www.nmrc.org Simple Nomad [thegnome (at) nmrc (dot) org [email concealed]] 14Jan2006 ________________________________________________________________________ _______ Microsoft Windows Silent Adhoc Network Advertisement Platforms : Windows 2000/XP/2003 Application: Wireless Network Connection (aka Microsoft Wireless Client) Severity : High (albeit lame) Synopsis -------- This advisory documents an anomaly involving Microsoft's Wireless Network Connection. If a laptop connects to an ad-hoc network it can later start beaconing the ad-hoc network's SSID as its own ad-hoc network without the laptop owner's knowledge. This can allow an attacker to attach to the laptop as a prelude to further attack. Details ------- The following is a sample scenario: - Alice has a wireless access point at home with an SSID of "linksys", which she has successfully set up and connected to with her laptop. - Alice goes to the airport (or train station or coffee shop) and opens her laptop. - Bob, who is sitting next to Alice, has a laptop configured with an ad-hoc network advertising an SSID of "linksys". - Alice's laptop when started looks for the SSID of "linksys", and attachs to Bob's ad-hoc network. - The next time Alice boots up the laptop when the Ethernet cable is not attached and there is no "linksys" SSID in range, Alice starts advertising an ad-hoc network with an SSID of "linksys". This is basically a configuration error that spreads virus-like from laptop to laptop. In field tests, numerous ad-hoc SSIDs such as "linksys", "dlink", "tmobile", "hpsetup", and others have been documented. The issue is compounded with a few additional caveats. Laptops with built-in wireless connectivity are usually left with the wireless active. Additionally, by default most wireless connections use DHCP to acquire an IP address. If the DHCP request fails, Microsoft has implemented RFC 3927 [1] to provide an IP address via APIPA (Automated Private IP Address) [2] in the 169.254.0.0/16 range [3]. This is known as a Link-Local address, and by default Link-Local is turned on on all Windows platforms on all interfaces, including wireless interfaces. Details of Microsoft's Link-Local implementation is in RFC 3927, appendix A.4 (Microsoft is a co-author of RFC 3927). Essentially this assigns the advertising ad-hoc network an IP address. On Windows 2000 and Windows XP SP0 and SP1, this all happens in the background without the user's knowledge -- on Windows XP SP2, the user is notified it has "attached" to an ad-hoc network, when in fact it has simply started advertising the ad-hoc network and the Link-Local address has been assigned. An attacker can attach to the ad-hoc SSID and either manually assign an IP address in the 169.254 class B or simply DHCP and await a time-out that assigns the attacker's laptop an IP address via a Link-Local configuration. After passively sniffing and awaiting the usual NetBIOS traffic and/or by running a ping sweep, the victim's IP address can be discovered. The attacker can then perform the various probes and attacks to gain access to the system. If the attacker is impatient in waiting for determining the IP address of the victim computer, the attacker can attach to the advertising SSID and offer up a DHCP server. Windows systems running Link-Local addresses periodically probe for a DHCP address, so the victim will eventually get the DHCP address and switch to the new address supplied by the DHCP as opposed to continue using the APIPA number. By tracking what IP addresses are being served by the DHCP server, the attacker can spend more time on an attack and less time solving the connectivity issue. There is a warning about using Link-Local with wireless LANs due to the lack of physical security in RFC 3927 section 5 paragraph 3, but unfortunately Microsoft failed to properly heed this warning in spite of co-authoring the RFC. Tested configurations --------------------- Field tests were conducted and the following systems were either positively identified (sometimes via "shoulder surfing") or approximated based upon passive fingerprinting of network traffic: Windows 2000 SP 2 Windows 2000 SP 3 Windows 2000 SP 4 Windows XP Home Edition Gold Windows XP Professional Gold Windows XP Professional SP 1 Windows XP Professional SP 2 Windows 2003 (unknown patch level) Lab tests were conducted with 2 laptops with the following configuration: Windows XP Professional Gold Windows XP Professional SP 2 Vendor Response --------------- Microsoft was contacted on October 13, 2005. After numerous exchanges of emails and a conference call, Microsoft was able to reproduce and isolate the issue within their software. As there are multiple and easy-to-implement workarounds for the issue, Microsoft has scheduled to include the fix in the next service packs. Solution/Workaround ------------------- Until Microsoft releases Service Packs for the affected platforms, use one of the following three workarounds: Workaround #1: Disable wireless when not in use. Simple, eh? Workaround #2: Use an alternate Wireless Client Manager, (e.g. for an integrated Intel Wifi connector, use Intel PROSet/Wireless) as all others tested do not seem to have the problem (this testing was not all-inclusive). Workaround #3 (recommended): 1. Click on the Wireless option in the System Tray and open the Wireless Network Connection window. 2. Click on "Change advanced settings". 3. In the Wireless Network Connection Properties window, click on the Wireless Networks tab. 4. Click on the Advanced button. 5. Click on "Access point (infrastructure) networks only" This workaround prevents you from connecting to any ad-hoc network in the first place. Comments -------- Yes this is lame. I know this, don't email me with that info. However I deem it serious due to the exposure in laptops with wireless. In field tests, it became apparent that if the laptop user fired up their laptop in the airport terminal and was advertising an ad-hoc network, when the same laptop user fired up their laptop during the flight, they would in fact be advertising the ad-hoc network during flight. This has a couple of ramifications. The first is that if wireless laptops with the wireless adapter enabled were capable of interfering with the navigational systems as claimed by the airlines then we would be having numerous in-flight incidents due to the high proliferation of wifi-enabled laptops used by business people on flights. The second ramification is that users sitting on a plane at 35,000 feet are not going to be suspecting a network attack against the laptop in the lap, and so any odd "side effects" from probe and attack attempts (service crashing, blue screen or a restart) will be dismissed as a local system anomaly and not an attack, allowing the attacker to be a little more aggressive. Here is collected data from 4 domestic flights within the U.S. conducted during September and October 2005. The data was collected using NetStumbler, NMap, and Metasploit Framework [4] from a laptop running Windows XP: Aircraft Laptops* Ad-hoc Nets** Live Targets Vulnerable*** -------- -------- ------------- ------------ ------------- MD80 8 2 3 1 MD80 12 5 5 4 757 22 1 3 3 MD80 14 4 4 3 * Number of laptops out and running at approximately the halfway point of the flight. ** In some cases, an ad-hoc network would form and other laptops would attach to it instead of advertising their own ad-hoc network. *** A system was classified as vulnerable if it could be remotely compromised or it was open enough to allow files to be copied to or from the hard drive. Vulnerabilities included CVE-2005-0059 (MS05-017), CVE-2005-1983 (MS05-039), open shares, and NULL access. It should also be noted that while visiting Charlotte, NC (whose airport at the time had no commercial wireless offering like TMobile or anything else) -- walking the terminal during massive eastcoast rain delays with most flights delayed by a couple of hours -- I counted no less than 62 ad-hoc devices. The novelty of collecting data during flight was the focus of the table above, but a conservative estimate would put have of those ad-hoc devices at risk. Greetz ------ OSVDB, American Airlines (extra room in coach rocks, but serve iced tea for christ sake), Starbucks, and everyone in the scene in DFW. Special Greetz to Dino and K2, check out http://www.theta44.org/karma/ as they covered some similar ground at Bluehat and CanSecWest (I was at neither), KARMA works great and is perfect for owning every laptop in the terminal or on the plane. References ---------- [1] http://www.faqs.org/rfcs/rfc3927.html - This defines IPv4 Link-Local addresses and their use. [2] http://en.wikipedia.org/wiki/APIPA [3] http://www.faqs.org/rfcs/rfc3330.html - This defines special-use address ranges, including the 169.254 class B. [4] You should know these tool locations by heart. Netstumbler, Nmap, and Metasploit Framework can be found at www.netstumbler.com, www.insecure.org/nmap, and www.metasploit.com respectively. Copyright --------- This advisory is Copyright (c) 2006 NMRC - feel free to distribute it without edits, but you DO NOT have permission to use this advisory in any type of commercial endeavour. ________________________________________________________________________ _______


Vote for this issue:
50%
50%


 

Thanks for you vote!


 

Thanks for you comment!
Your message is in quarantine 48 hours.

Comment it here.


(*) - required fields.  
{{ x.nick }} | Date: {{ x.ux * 1000 | date:'yyyy-MM-dd' }} {{ x.ux * 1000 | date:'HH:mm' }} CET+1
{{ x.comment }}

Copyright 2022, cxsecurity.com

 

Back to Top