_______________________________________________________________________________

                         Nomad Mobile Research Centre
                               A D V I S O R Y
                                www.nmrc.org
                       Simple Nomad [thegnome@nmrc.org]
                                  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.


_______________________________________________________________________________