Establishing Digital Trust: Don't Sacrifice Security for Convenience
But the fact is that your users don't have to make use of a Wi-Fi hotspot to compromise your network. It's enough for them to pull out their laptop and start using it in an airport, conference center or any other busy place with the wireless adapter switched on. That's because the way Windows XP's zero configuration networking (zcn) works is, from a security point of view, sheer lunacy.
Here's an example of how. When a laptop is switched on, znc tries to connect to a network by matching the network names it receives with names in its preferred network list. If it can't find a network it knows, it sends out probe requests with the names of the networks in the list, in case any of those networks are non-broadcasting networks with hidden SSIDs. D'oh! By doing that, the laptop openly announces a list of the names of all the networks it's happy to connect to. Anyone sniffing the airwaves using a common tool such as Kismet or Airodump could easily configure their computer to look like an access point with one of those names, and if that network is an open, unencrypted one (as most public access points are) then within a minute or two the user's laptop would connect to it.
And don't imagine your user would be secure if they had no unencrypted networks stored in their preferred network list, or even no networks on the list at all. When the laptop is not connected to an access point, zcn carries out an operation known as "parking " the wireless adapter. This puts the adapter in infrastructure mode and creates a random wireless network name. The adapter then scans for preferred network connections - if there are any - every minute.https://o1.qnsr.com/log/p.gif?;n=203;c=204650394;s=9477;x=7936;f=201801171506010;u=j;z=TIMESTAMP;a=20392931;e=iThe problem is that some adapter drivers may interpret the parking operation as a request to connect to a network, causing the laptop to send out probes requests to try to connect to a wireless network with the random name generated during the parking operation.
But here's the really bad bit: since the random network name has no encryption associated with it, anyone sniffing the airwaves could easily spot the name of the probe and then establish a connection with the laptop by setting up a fake access point with the random name.
But that's not all. If there are no wireless access points around – in the middle of a park, for example – then zcn sends out probe requests to connect to ad-hoc networks in the preferred network list or any ad-hoc networks that have recently been used. Ad-hoc networks are direct connections between two computers without an access point acting as an intermediary. Once again, a malicious user sitting nearby could monitor these probes and make a direct connection to your user's laptop if any of the preferred ad-hoc networks are unsecured.
There's actually a bizarre side effect of this ad-hoccery: a phantom ad-hoc connection called "Free Public Wi-Fi" which often pops up as an available connection on Windows XP machines. If you try to connect to this network nothing happens. It you see Free Public Wi-Fi on your machine as an available network on your machine, it's actually an echo from the past when someone did once connect to a network with that name. It later sent that network name out as a probe, which someone else picked up and tried to connect to. Their machine was then "infected" with this SSID, sending it out as a probe and so on, until eventually your machine picked up the probe from a nearby laptop. If you try to connect to it, then in future your machine will send out this SSID name and probably "infect" someone else. The fact that it is so common shows just how overly talkative a system using zcn can be.
Remember, for a malicious user to connect to your user's laptop in any of these scenarios, your user would not have made a conscious decision to go in to a cafe and connect to the Internet. As long as Wi-Fi is left on – which it generally is – then all these probe requests and potential network connections would have been going on automatically behind the user's back. Or, more accurately, right under their nose.
And once a malicious hacker has connected to the laptop, who knows what they may find there? Perhaps of more concern is what they may deposit on the laptop, to infect your network once the user returns to the office and connects up.
A Low Profile Fix
The good news is that there is a solution to these problems in the form of a patch supplied by Microsoft. It's not a particularly new patch, but Microsoft hasn't taken many pains to announce its presence, or make it available by automatic update. You can download the Wireless Client Update onto wireless machines from Microsoft.
This changes the behavior of a parked interface so that the random connection created is encrypted. Also, the names of ad-hoc networks that have recently been connected to are no longer broadcast as probes automatically, and there's an option to define a network as a broadcast network, so that a probe will not be sent out with the network's name if the SSID is not received.
Unfortunately, this is not enabled by default – after installing the patch it's necessary to go to the adapter's preferred network list (click the "Change order of preferred networks" in the wireless connections window,) click properties for each network in the list, and uncheck the "Connect even if this network is not broadcasting" option. (Unless of course it is a hidden network, in which case unchecking it will disable connections to that network until it is rechecked.)
Unless you have already been made aware of this update it's unlikely to be on any of your users' laptops, because for some reason it is not part of Window Update and won't have been installed automatically. But installing it is a good way of reducing the risk of mobile users infecting your network inadvertently, and since reducing security risks is a vital part of network administration, you be well advised to scoot over to Microsoft and get the patch installed on all your users' laptops ASAP.
This article was first published on EnterpriseITPlanet.com.