1/15/2008

You May Run Across This Yourself

Uncle AndrewUncle Andrew
Filed under: @ 7:39 pm

I meant to post about this earlier but I was first derailed by three weeks of “Hawaii Time” laziness and then by the death of our last cat. This happened to me while waiting for our flight out to Hawaii at the Seattle-Tacoma International Airport in December.

As I am wont to do when I am bored or otherwise unoccupied, I used the wireless card in my phone to stumble for WiFi, seeing if there were any free services available amongst the usurious pay-for-play wireless networks typically available in airports around the world. Usually there aren’t—the for-profit companies tend to have a serious lock on the market, and few municipal airport systems have felt the need to provide this service free of charge for their overbooked, overstressed, sometimes overnight customer base—but it’s always worth a shot. Heck, later in our vacation I was able to while away a lengthy stay at the Kona Airport surfing the Web via Aloha Airlines‘ complimentary WiFi network….I’ve been meaning to drop them a nice little note about that.

Anyway, I fired up my favorite little Windows Mobile wireless stumbler, and there, amongst the encrypted Port of Seattle private networks and the public-but-pricey commercial service providers, was an SSID called “Free Public Wifi”. Interesting! Only things weren’t exactly kosher with ol’ Mister Free Public WiFi; it was an ad-hoc, or peer-to-peer network. Ad-hoc networks are generated by a single computer; by contrast, the more common infrastructure networks are generated by a wireless access point. Unlike infrastructure networks, ad-hoc networks generally do not connect to the Internet or to any other place except the computer that it generating the signal. They are typically used to exchange files between two or more computers. And while there may be reasons for an individual with a WiFi-enabled computer to have created an ad-hoc network—even at the airport—there is basically no legitimate reason for said individual to give this network a name implying a service that is not in fact being offered.

So an ad-hoc network bearing the name “Free Public Wifi” would seem contradictory at best, duplicitous and potentially criminal at worst. The most obvious explanation as to its existence was that some unscrupulous individual was broadcasting the SSID in an attempt to get feckless Internet-seekers to attach to it, at which point (s)he would attempt to browse their hard drive, analyze their network traffic or install malicious software on the victims’ machines. It is even possible—easy, really—to set up a system by which users connecting to the ad-hoc network actually can use it to get out onto the Internet, but every packet sent from their computers is captured and analyzed for useful data; email passwords, credit card numbers, etc. (By the way, this sort of packet sniffing is also easily performed on regular old infrastructure networks. Unless you are visiting a secure Web site [one whose address beings with “https” instead of just “http”] or are using an encrypted VPN tunnel [here’s a hint: if you don’t know whether you are using an encrypted VPN tunnel, then you’re not], you are best off not using public WiFi for any task more potentially sensitive than, say, checking out the adorable critters at Cute Overload).

I mentioned the ad-hoc network and my theory about it to Margaret, snorted in a “people these days!”-like fashion to no one in particular, and dragged out a book to read instead.

It was only after we got back from vacation that I thought to Google the network name and came back with an alternate explanation for “Free Public Wifi”. It turns out that both Windows 2000 and Windows XP have an interesting quirk: if a wireless-enabled Win2K or WinXP computer fails to find a wireless network to join upon powering up, they are set by default to rebroadcast the SSID of the last wireless network to which they were attached, only in ad-hoc mode. This is a major security flaw in Windows (Macs do not do this, by the way), and has been discussed ad nauseum on the Web. There are a number of workarounds, should you need one. I pulled these off of nmrc.org:

Solution/Workaround
——————-

Until Microsoft releases Service Packs for the affected platforms, use one of
the following three workarounds:

Workaround #1:

Disable wireless when not in use. Simple, eh?

Workaround #2:

Use an alternate Wireless Client Manager, (e.g. for an integrated Intel Wifi
connector, use Intel PROSet/Wireless) as all others tested do not seem to
have the problem (this testing was not all-inclusive).

Workaround #3 (recommended):

1. Click on the Wireless option in the System Tray and open the Wireless
Network Connection window.
2. Click on “Change advanced settings”.
3. In the Wireless Network Connection Properties window, click on the Wireless
Networks tab.
4. Click on the Advanced button.
5. Click on “Access point (infrastructure) networks only”

This workaround prevents you from connecting to any ad-hoc network in the
first place.

The part of it that I found to amusing was the “viral” nature of the bug. Here’s the basics: laptop user A connects to an infrastructure WiFi network called “Free Public Wifi”, at a coffee shop or a municipal wireless hotspot or wherever. A few minutes/hours later he signs off. The next time he opens his laptop up, there’s no available wireless, so laptop A instead begins broadcasting an ad-hoc network called “Free Public Wifi”. Laptop user B sees the SSID and connects to it, only to find that she can’t get on the Internet via “Free Public Wifi”, and signs off. Then the next time laptop user B opens up her laptop, laptop B begins broadcasting the “Free Public Wifi” ad-hoc network. Laptop users C and D connect to it, give up, sign off, and then pass the SSID on to laptop users E through H, who pass it along to I through Q, who then pass it on to R through M4, and so on.

Security questions aside, I find this tableau fascinating. At some point, there had to be a Patient Zero, the first laptop to fail to reconnect to “Free Public Wifi”, then begin to rebroadcast the SSID in ad-hoc mode, passing the torch to others. There must be hundreds or thousands—or tens of thousands—of PC laptops out there propagating this network. Just as fascinating, there must be instances when ten or twenty “infected” laptops are congregated in the same place, all rebroadcasting or rejoining the same useless ad-hoc network, commingling in a raucous orgy of futile and potentially disastrous packet exchange.

All of this should serve as a reminder: be aware of what you are doing with your computer, and what your computer is doing on its own.

7 Responses to “You May Run Across This Yourself”

  1. Sara Says:

    Glad we could accommodate you Drew with a ‘Free Willi”… mean while I’m with Margaret. Pass the book please…

  2. Uncle Andrew Says:

    Hey Sara! As long as you’re checking the blog, thanks very much for the Starbucks gift card; I tucked it into the back of my wallet for emergencies. :mrgreen:

  3. Gavin Says:

    Dude, your email inbox is full:
    :
    208.64.240.5 failed on DATA command.
    Remote host said: 452 Insufficient system storage
    I'm not going to try again; this message has been in the queue too long.

  4. Uncle Andrew Says:

    What the hell….shouldn’t be. I’ve also had problems sending to some Comcast subscribers. I think my ISP is having a nervous breakdown. I just did some online maintenance; try again?

  5. Sara and Danny Says:

    We are delighted to support your caffeine habit. Happy Birthday!

  6. joe Says:

    A note about Comcast and spam filtering. Comcast filters their incoming mail against a reverse DNS lookup of the source mail server. Several of our customers have had problems sending e-mail to Comcast addresses and in nearly every case those customers have been running an SMTP server that did not have a matching PTR entry in their Reverse DNS Zone.

    I performed a dig of the zhonka1.zhonka.net off of the comcast DNS server and it returns neither an IP address nor an entry for zhonka1 on a reverse lookup of its IP address. These values are dig-able on the DNS servers at my work. You might contact Zhonka and have them check on why their addresses are not resolving through the Comcast DNS servers.

  7. Uncle Andrew Says:

    Right on Joe, thanks! I’ll give them a buzz and let them know.

Leave a Reply

All comments containing hyperlinks are held for approval, so don't worry if your comment doesn't show up immediately. (I'm not editing for content, just weeding out the more obvious comment spam.)


All portions of this site are © Andrew Lenzer, all rights reserved, unless otherwise noted.