WEP-Client-Communication-Dumbdown (WCCD) Vulnerability
http://www.securitystartshere.net/page-vulns-wccd.htm
WEP-Client-Communication-Dumbdown (WCCD) Vulnerability
Vulnerability Description:
ThinkSECURE has discovered that certain well-known wireless chipsets,
using vulnerable drivers under the Windows XP operating system and when
configured to use WEP with Open Authentication, can be tricked by a
802.11-based wireless client adapter operating in master mode ("the
attacker") to discard the WEP settings and negotiate a post-association
conection with the attacker in the clear.
We have named this vulnerability as the
WEP-client-communication-dumbdown or WCCD vulnerability.
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 our experience 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.
Vulnerability Impact:
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 security auditing 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.
Vulnerability Cause:
In our testing, we have narrowed down the cause of the problem to stem
from the way certain chipset manufacturer drivers deployed for the
Windows platform operate in handling an association.
Affected chipset manufacturer(s) have been notified via their website
contact addresses.
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)
Mitigating Actions:
Until such time as the affected chipset manufacturer(s) can release
non-vulnerable drivers, we strongly recommend the following mitigation
strategies:
1. When not using or connected to your WEP-enabled wireless network,
switch off your wireless client adapter. If your laptop does not have a
hardware switch, disable the interface under windows until such a time
as you need to use your WEP-enabled wireless network. This will minimize
the attack window.
2. Do not configure your Windows wireless profiles to use "Automatic
Connection - Connect when this network is in range" option.
3. Migrate to your profiles and wireless networks to WPA-PSK, WPA or
WPA2, if possible. WPA was not found to be vulnerable for the devices we
tested.
4. Install personal firewalls to prevent unauthorized layer 3
connections, even if an association is made.
5. Regularly patch other components of your Windows operating system to
prevent the kind of scenario outlined in the vulnerability impact
section of this advisory from happening.
6. Watch for chipset driver releases which rectify this vulnerability.
Vulnerability Discovery Acknowledgment:
Christopher Low & Julian Ho of ThinkSECURE Pte Ltd
(http://www.securitystartshere.net) discovered and researched this
vulnerability from Dec 2005 to 15 Jan 2006.