Wireless Vulnerabilities & Exploits
Wireless Vulnerabilities & Exploits
WVE ID: WVE-2006-0003
Type: Vulnerability
Status: Candidate
Classification:
Authentication Management
Cryptographic
Description:
Stations using specific chipset/driver combinations used in the Windows XP operating sytem when configured to use WEP and Open Authentication can be tricked to associate with an attacker operating an AP with the SSID that the station requests.
Discussion:
This vulnerability is apparently not due to Windows itself but due to the operation of the drivers for the affected wireless cards. However, this does not discount a situation where a patch could be released by Microsoft to deal with the problem on the chipset makers' behalf.
Again, this is apparently NOT a Windows problem but a wireless chipset driver-related one.
End-users of the system would not notice any difference about the clear connection that was being established.
Although WPA/2 & WPA-PSK have been out for some time now, in reality there is still a large installed client base who are still using WEP-enabled Access Points and thus have WEP-enabled profiles setup in their laptops. This installed base is vulnerable.
The vulnerability was observed in a Windows XP wireless client configuration with the vulnerable drivers and with the following setups:
1. Profile configured using Windows XP zero configuration as well as using the vulnerable drivers' bundled wireless client managers;
2. Profile configured to use WEP with static WEP key & Open Authentication.
Using ThinkSECURE's recently-released security auditor's tool - probemapper - one can remotely evaluate the SSID and capabilities of wireless profiles from probe requests and assess whether the subject is probing for any Open-Authentication-WEP-encryption-enabled wireless networks.
When a Windows XP client using a vulnerable chipset driver is configured as outlined above via their wireless profiles ("the victim"), the victim will send out probe requests bearing the SSID configured in the wireless profile.
An attacker who detects the probe request frames coming from the configured profile can configure a master-mode-enabled wireless card with the detected SSID of the probe request frames and, using Open Authentication with no-encryption, send probe responses to the victim.
The victim will then initiate authentication and association, sending an association request frame with the Privacy Bit set to 1 (AP/STA can support WEP).
The attacker returns an association response frame with Privacy Bit set to 0 (AP/STA cannot support WEP).
Although the correct behavior should be to not establish any communication due to the difference between association request and response Privacy Bits, the victim "dumbs-down" and establishes an un-encrypted communications session to match the attacker's Privacy Bit setting of 0, thus ignoring the WEP settings as configured in the client's profile. All traffic to & from this connection will be sent in the clear.
A victim who has a vulnerable wireless network at home and brings a laptop bearing the profile of said home wireless network to his/her organization and plugs in using a wired connection may be attacked in this manner and used as a conduit by the attacker, through the bridging of the laptop's wireless interface to the wired interface, to the victim's organization's wired network, thus bypassing corporate perimeter defences. It is irrelevant that the organization does not use wireless or has a no-wireless policy if that policy is not strictly enforced through proactive checking.
Also, firewalling on the victim's laptop might not guarantee safety in certain cases: e.g. the attacker issues an IP address and gateway address to the victim in response to the victim's typical DHCP request upon association so as to fool the victim's machine into forwarding all traffic to the attacker's machine. The result is that, when the victim opens up a web browser for example, he will see a crafted page bearing malicious code on the attacker's machine which runs exploit code on the victim's machine (a good example being the recent WMF vulnerability) to give the attacker a reverse shell into the victim, where the attacker can then do the bridging of the interface or anything else he wants.
In the interests of responsible disclosure, we will not be stating
which chipset drivers which we tested as vulnerable for a minimum period
of 14 days after this vulnerability advisory, thus giving time for the
notified vendors to issue non-vulnerable drivers. (dated 16 Jan 2006)
Update: (Tues 7th February 2006)
In our testing, we have narrowed down the cause of the problem to stem
from the way Intel drivers deployed for the Windows platform
(specifically the Intel chipset IntelR PRO/Wireless 2200BG drivers up to
driver version 9.0.3.9) operate in handling an 802.11 association.
This includes OEM manufacturer Intel Pro/Wireless 2200BG drivers which re-
use the original Intel driver code.
Intel Corporation was notified via their website contact addresses (e.g.
http://supportmail.intel.com/scripts-emf/ welcome.aspx?id=1783,1784,1637
) on 16 Jan 2006, but they have not responded to us regarding this issue
as of 7 Feb 2006.
Update: (13 July 2006)
Latest Intel chipset IntelR PRO/Wireless 2200BG driver version 9.0.4.13
(dated 5 April 2006) which was downloaded off Intel's website is still
vulnerable (even if the bundled Intel Client Manager is used instead of
Windows zeroconf). Reboot after driver update/software install is
required only if driver *AND* Client Manager installation is NEW (no
previous driver/sw installed) but that falls within normal user operation
patterns - all other types of install, update, etc are vulnerable without
need to reboot. You all can test this using Probemapper's targeting mode.
Intel Corporation was notified again(!) on 28 Jun 2006 (via
http://supportmail.intel.com/scripts-emf/welcome.
aspx?id=1783,1784,1637), but they have not responded to us regarding this
issue as of 13 July 2006.
Update: (9 August 2006)
Latest Intel chipset IntelR PRO/Wireless 2200BG driver version 9.0.4.17
(dated 26 June 2006) downloaded off Intel's website is still vulnerable
(tested using Windows zeroconf).
Christopher Low & Julian Ho of ThinkSECURE Pte Ltd (http://www.securitystartshere.net) discovered and researched this vulnerability from Dec 2005 to 15 Jan 2006.
Credits
Author:
Julian
Ho
(thinksecure@securitystartshere.net)
: ThinkSECURE Pte Ltd (www.securitystartshere.net)
Author:
Christopher
Low
(thinksecure@securitystartshere.net)
: ThinkSECURE Pte Ltd (www.securitystartshere.net)
References
URL:
http://www.securitystartshere.net/page-vulns-wccd.htm
Released: 2006-01-16
Submitter
Christopher
Low
(thinksecure@securitystartshere.net)
: ThinkSECURE Pte Ltd (www.securitystartshere.net)
Submitted: Mon Jan 16 01:26:26 -0800 2006
Candidate Date: Wed Jan 18 13:18:23 -0800 2006
