January 2006 Wayback

Wireless security issues

Several vulnerabilities in Microsoft’s the Windows Zero Configuration Wireless utility (ZeroConf, also known as Wireless Auto Configuration) have come to my attention in the past few days which could cause serious ramifications for enterprise network security, namely the Microsoft Windows Silent Adhoc Network Advertisement, KARMA Probe Request Response and the WEP-Client-Communication-Dumbdown (WCCD) Vulnerability. Based on testing I believe that administrators should make some GPO changes to protect their users and network.

The first exploit has been named Microsoft Windows Silent Ad-hoc Network Advertisement. The exploit has been documented at http://www.nmrc.org/pub/advise/20060114.txt just in the past few days, although the method has been known for some time. The exploit works as follows:

John Doe brings his company laptop home and connects it to his home network, an unsecured open access Linksys router. The configuration details are stored in the ZeroConf program. John finishes his work at turns off his laptop.

Later, while on a business trip, John powers up his laptop to work on a report that he is doing. His laptop immediately begins to look for the Linksys router, and not finding it begins broadcasting an ad-hoc network using the SSID of his home access point.

Hacker Jane, also in the same airport terminal as John, is running one of many wireless discovery tools on her laptop, and sees John’s machine and its ad-hoc network come online. She initiates a connection to John’s SSID. The two machines then negotiate IP addresses using Microsoft’s Link Local addressing scheme 169.254.x.x. Jane now has a network connection to John’s laptop and can now start typical penetration attacks, SMB, dictionary attacks, etc.

I have also tested the same vulnerability just hours ago using a pair of laptops and an unsecured access point in the lab.

Join Laptop 1 to the access point with SSID ‘1234’
Power off Laptop 1.
Power off the access point.
Bring Laptop 1 online. Network ‘1234’ now shows up in Laptop 1’s network list as ‘Disconnected.’ At this time it is already functioning as an ad-hoc network client.
Bring Laptop 2 online. Network ‘1234’ now shows up in its available network list as an unsecured ad-hoc network.
Connect Laptop 2 to ‘1234’. The moment I pressed this button on Laptop 2 I watched as both it and Laptop 1 went from ‘disconnected’ to ‘acquiring network address’.

This is just one scenario that could be exploited. Given the number of tablets and laptops currently deployed the possibilities are endless. Just yesterday afternoon I was able to make an ad-hoc connection to a user’s laptop within our IS department and browse their hard drive. I believe it would also be possible to have done the same thing from outside of the building using unidirectional antennas. We must also be aware of the possibility that Windows internet connection bridging might also give a hacker direct access to our internal network once connected to vulnerable machines.

The second attack focuses on a probe request, a type of packet that Windows sends as it scans the ether for wireless networks it has connected to in the past. A hacker tool known as KARMA (http://www.theta44.org/karma/) can intercept these requests and automatically configure itself to reply as an access point for all clients. A presentation (http://www.theta44.org/software/iaw6.ppt) is available on the same page that details how this can be exploited to fool a laptop into connecting to an unsecured spoof network even when it is configured to connect to a WPA enabled secure network.

To guard against these exploits there are several steps adminstrators can take, the first being to configure ZeroConf not to connect to ad-hoc networks. There is a Wireless Network (IEEE 802.11) Policies Group Policy Extension available here: http://www.microsoft.com/technet/community/columns/cableguy/cg0703.mspx that we can use to set this and many other settings including disabling the ZeroConf service altogether. Windows does not natively support the type of encryption that we use within our HQ and the rest of our enterprise should not be using wireless at all. Disabling ZeroConf completely would enable us to maintain the security of our network by rendering a majority of rouge access points (unauthorized AP’s brought in by FEI employees) unusable.

The first argument against disabling ZeroConf that I hear is that it will interfere with persons that wish to use their access points at home. My response to this argument is that the vendor supplied software that we have, namely the Intel software for our HP clients and the Cisco 802.11 client software would allow users to use their home AP’s while providing us with the layer of security that we need. Initial reports state that the Intel software is not susceptible to this type of attack, although it has not been fully tested.

The final vulnerability that I am aware of has been dubbed the WEP-Client-Communication-Dumbdown (WCCD) Vulnerability (http://www.securitystartshere.net/page-vulns-wccd.htm). To put it briefly it describes how a certain wireless XP card drivers can be tricked into dumping a WEP enabled network connection and joining an attacker’s unsecured one. I have not tested this to see if we are vulnerable or not, but simply bring it to your attention as another example of the issues that we are facing.

Enterprises are susceptible to these attacks if they have decided to disable the MS firewall thru GPO. Once an attacker has gained wireless access they can attack a machine using any standard hacker / script kiddie attack tools known to man, as well as utilize any unpatched MS vulnerabilities that exist on the system. Once in they might utilize a persistent agent on the box to gain a foothold on an inside network when a user connects back to our hard wired or VPN network.

Internal network security is only as strong as the network attached to it. Some changes must be made to see that these wireless security issues do not go unresolved.

Leave a Reply

Your email address will not be published.