The security risks of "Free Public WiFi"

SSIDs labeled "Free Public WiFi" sound great, but seldom provide an Internet connection. They do, however, represent some nasty risks we explain how to defuse in this story.

Ever gone looking for a free WiFi link and found an SSID called "Free Public WiFi"? Careless WiFi users have been spreading this viral SSID to fellow travelers for three years now.

Here we explain why and how you should ignore this this risky ruse.

It can be tough to convince users -- especially those challenged by shrinking travel budgets -- to avoid the allure of free wireless Internet. When employers can't or won't pay for unlimited wireless Internet, employees get creative. Why should they waste thankless hours waiting for planes and trains when they could be using Free Public WiFi to catch up on mail, download iTunes, or watch a little Slingbox?

Unfortunately, Free Public WiFi isn't what it sounds like. In most cases, this unsecured wireless network is actually being offered by a nearby laptop or smartphone. Any naive user who tries to connect may well succeed, but the ad hoc node (wireless peer) at the far end isn't an on-ramp to the Internet. At best, it's a wireless cul-de-sac; a dead end for IP packets. At worst, it's a thief using KARMA to spoof destination servers, launch man-in-the-middle attacks and steal personal and business identities.

But why does Free Public WiFi exist on so many devices and in so many different venues? Most wireless clients that connect to this SSID automatically add Free Public WiFi to their list of wireless networks. Thereafter, whenever that client launches, it probes for Free Public WiFi. If none exists, it automatically starts advertising itself as Free Public WiFi. Thus the cycle repeats, spreading this viral SSID to other nearby users.

In truth, there is nothing special about Free Public WiFi -- any enticing ad hoc network name will do the trick. To prevent workers from infecting themselves and then others, employers must attack the root cause. Specifically, Wi-Fi users who are willing to connect to anyone are an accident waiting to happen. Overly automated clients further compound this human weakness by re-activating past wireless connections without user interaction or awareness.

Enterprises can use IT-managed Wi-Fi policies (e.g., Active Directory Group Policy Objects) to block connections to high-risk SSIDs such as free public WiFi. They can also use centrally managed host intrusion prevention systems to detect wireless policy violations such as Wi-Fi ad hoc mode operation. Midmarket businesses that lack the IT infrastructure and staff to implement these enterprise security measures can take comparable steps, albeit on a smaller scale.

  1. Where practical, install wireless client upgrades that deter 802.11 probe request and/or ad hoc mode exploitation. For example, Windows XP and Server 2008 systems can be patched with Microsoft's wireless client update to stop auto-probing for recently-added ad hoc SSIDs. (Windows Vista already deletes ad hoc SSIDs after disconnection unless otherwise configured.)
  2. Unless your business actually requires ad hoc mode wireless, configure all wireless clients to disable this feature. If you must enable ad hoc mode, look for client options that will notify users when ad hoc connections are formed.
  3. Configure wireless clients to disable automatic connections to unknown SSIDs. Some newer clients work this way by default, but many older clients did not. Of course, forcing users to explicitly allow connections to networks they don't recognize is just the first step -- follow up with user education regarding commonly abused SSIDs, including Free Public WiFi, hpsetup, and linksys. Rule of thumb: If an SSID looks out of place or too good to be true, don't connect.
  4. Although SSID blacklists are far from foolproof, they can still be useful in clients that support them. For example, configure the Intel PROSet Wi-Fi Connection Utility with an Exclude List that contains "Free Public WiFi" to hide and thus avoid this most popular viral SSID.
  5. Attackers can beacon any SSID they wish -- including the SSIDs they overhear being probed for by nearby clients. As such, consider disabling SSID probing in clients that implement this option (e.g., Windows XP SP3, Vista). However, using this option will also prevent connecting to any access point that does not beacon its own SSID.
  6. Ideally, users should only connect to known, trusted SSIDs and authenticated access points. But this policy can be impractical for travelers that want connectivity in many different venues. Such users can reduce risk by purchasing roaming access through a Wi-Fi hotspot aggregator like Boingo or iPass. While not free, this approach can deliver low-cost access to frequent travelers, thereby reducing the temptation to connect to unknown (and potentially malicious) SSIDs. Roaming access clients also implement protected login schemes that make it harder to plant fake hotspot APs.
  7. Keep an eye on Wi-Fi connectivity. For example, many wireless clients can be configured to maintain connection logs -- for example, the Wzcdlg.log and Wzctrace.log files created by the Windows XP Wireless Zero Config service. It may not be practical to routinely monitor these distributed log files, but they can still be useful for spot-check audits and investigation.

These steps won't provide bulletproof protection against viral SSIDs such as Free Public WiFi networks or the criminals that exploit them to attack unsuspecting wireless clients. So long as users have control over their own wireless connections, they can still make mistakes. However, implementing these safeguards can put a serious dent in the accidental use and spread of viral SSIDs.

Read more on Security policy and user awareness