Firesheep is a startling plugin that allows anyone to easily impersonate the login credentials of others for dozens of sites. It works on any unencrypted WiFi connection and is stupid-simple to setup. It can be done by anyone in a matter of minutes.
Just to illustrate how easy it is to setup, I was on Virgin America flight VX67 from Washington to San Francisco yesterday.
All I had to do to get going with Firesheep was download Firefox (onto my new MacBook Air) using the in-flight WiFi, and then download the Firesheep plugin for Firefox. Just drag the plugin into Firefox and it installs. Reload Firefox and you’re ready to go.
Click “Start Capturing” and you are instantly snooping on every interaction occurring on the WiFi network. In my case yesterday, that meant snooping on everybody who was using the WiFi on my flight.
What’s At Risk?
Within just a couple of minutes, I was able to impersonate 3 people on Facebook (updating their status, exploring friends, doing anything I wanted to – of course I didn’t). Twitter is also at risk. So is Gmail. And so is Amazon.
Access to Amazon is perhaps the most worrying. Once I realized I was in under someone else’s Amazon account, I quickly shut down Firesheep: this is some scary stuff. What if I had changed the shipping address for the account and done a one-click order on a $10,000 watch or a $2,000 plasma TV?
This was all at 37,000 feet in an airplane (and way more entertaining than SkyMall). Like taking candy from a baby.
Even More Shocking…
Later in the afternoon I was at one of the Internet Industry’s high-profile events: Web 2.0 Summit produced by O’Reilly. There on the hotel’s WiFi, which was setup to serve the summit, I ran Firesheep. Within seconds I had compromised about 25 accounts, including the Twitter accounts of O’Reilly Media and TechCrunch writer Alexia Tsotsis. Change passwords, tweet-as-them, friend and de-friend people? No problem. Here’s what I saw. (Note that my accounts were vulnerable as well.)
How It Works
I have not studied this exploit carefully enough yet to explain it in full detail, but my understanding is that on an open WiFi network, it’s trivial to capture in cleartext all of the web interactions of the users around you on the same IP network. Once you can do that (something Firesheep achieves using the pcap library, capturing port 80) then you can sniff for credential information specific to particular websites. Firesheep supports a couple of dozen out of the box, including all major social networking sites (Facebook, Twitter, Gmail, Gowalla, Foursquare) but also some more obscure sites relevant to coders (Github, Pivotal Tracker). Ouch. It even has an “import” function so others can write exploits for sites that Firesheep doesn’t know about yet.
The bottom line is that these sites all need to enforce the use of HTTPS (secure HTTP) rather than HTTP *before* the login handshake occurs. This will force some emergency changes by many sites over the next few days.
This is not a new exploit – it’s always been possible to do this; Firesheep just makes it stupid easy.
A Note On Passwords vs. Encryption
You’ve encountered WiFI networks that require WEP or WPA encryption passwords. These are secure from Firesheep’s reach. However, there are a lot of WiFi networks that require “passwords” (such as those at coffee shops, hotels, etc) that are in fact open networks. Many do not even require you to login to them to exploit them via Firesheep. To put it in perspective, every Starbucks location is vulnerable to attack.
The only for-sure ways to stay safe from Firesheep for now are to 1) use only encrypted WiFi networks (that use WPA or equivalent), 2) use wired networks that you trust. Any open WiFi network can and will be vulnerable to this attack until vulnerable sites switch to using HTTPS for all authentication. Be very careful out there, folks.
Update: After talking with a few folks and thinking through this exploit a little further, I can offer a bit more complete of an explanation of how it works and why blocking it is so difficult.
The exploit does not actually capture the *password* itself (which is actually transmitted using HTTPS) but rather captures the authentication credentials which are stored (and visible) in the session cookie *after* HTTPS authentication has completed.
So, even a one-time password will not address this. And the reason boils down to ads and other unsecure content that folks want to serve as part of the site experience. To fix this problem would require serving ads (and images) via HTTPS, which would require major computing resources and will have a major impact on the web.
According to one security researcher I spoke to this evening (who formerly ran Yahoo mail), there’s no obvious way around this other than to allow both HTTP and HTTPS content to be served from the same site during the same session, something which presently causes an alert to the user (which would have the result of freaking them out). Such an alert is a good thing; turning it off is not a net gain. It shouldn’t be up to the user to have to sort out which resources the site is requesting should be secure and which ones do not need to be.
So, it’s a real dilemma. No one seems to be sure how to really address it other than to eliminate or curb the use of open networks, which is probably where it’s going to end up. So open WiFi is now basically over. Expect places that had been using it to post publicly available WPA passwords, which solves the problem.
I spoke at eComm 2008, held this year in March 2008 at the Computer History Museum in Sunnyvale California. I’ve been involved in the VoIP and open source telephony world for the last several years as a contributor to Asterisk, hacker on OpenSER and several other projects small and large involving tearing down the 100 year old telephony infrastructure and replacing it with something better different.
If you’re a part of the Asterisk community, you know that I have a certain amount of notoriety as The Roomba Guy. In a visionary fit of silliness during the Christmas holiday week in 2005, I decided it would be interesting to play with the Roomba API and see if I could hook it up to a Linksys WRT54G wireless router.
The Roomba uses an RS-232 CMOS 3.3V interface
The WRT54G has an RS-232 CMOS 3.3V interface
The Roomba supplies a 14V DC unregulated power output
The WRT54G can run off about 12V DC and has voltage regulators
You can see that based on this, the rest is inevitable. The Roomba has a 7-pin mini-din connector that provides the power and the RS-232 connection, so I made up a cable that goes from that connector to the 10-pin serial header interface on the WRT54G.
I got the serial port working pretty quickly and could send basic hex commands like start and stop to the Roomba. My friend made up some mounting “rails” to hold the WRT onto the top of the Roomba, and now the thing was autonomous and could be controlled via an SSH session established via WiFi. The WRT runs the White Russian OpenWRT Linux distribution.
The prospect of controlling the Roomba using SSH or a web interface wasn’t too compelling. I happened to be aware that some folks had success getting Asterisk (the open source telephony PBX) working on the WRT. So, I thought, what if we could put Asterisk onto the WRT and control the Roomba with that?
So, I did. Asterisk was easy to install on the WRT and in pretty short order I had cooked up an Asterisk dialplan that tied the telephone keypad to actions on the Roomba. 2 is forward, 5 is back, 6 turns right, 4 turns left, 5 stops, etc.
I was demonstrating this at Astricon 2006, a few months later, and my friend John Todd suggested that we contact Allison Smith, a voice artist of some renown and the “voice of Asterisk” — she supplied all the default english prompts for Asterisk.
She was incredibly accomodating and obliged graciously. She recorded about 20 prompts, including “forward”, “backwards”, “right”, “left”. We also allowed for control of the vacuum and brushes in the robot. So, you can press 1 to “start sucking” and press 3 to “stop sucking”. Did I mention that Allison is an incredibly good sport?
So, the final form took shape. A talking, SIP-enabled, WIFI, autonomous, cleaning, sucking, four-port ethernet switch able to run a small business phone system and clean it at the same time. It’s really quite baroque in its overall frilly uselessness, yet still compelling in a circus side-show sort of way.
We’ve experimented with adding a camera to it, but have found that it tends to create too much power draw. I’ve looked at using other routers that can run embedded Linux, but there always seems to be some reason why it doesn’t work. I really don’t have the time to spend on this, and that’s probably a good thing.
But, the overall lesson is an important one: Imagination is more important than knowledge. Einstein said it , but it should be repeated. As techies, we spend too much time thinking about how to solve a problem, rather than playfully considering new ways of framing problems. Imagination is truly the plutonium of technology, and we tend to lock it up and not use it that often. Knowledge is certainly important, but knowledge without imagination is everything that’s wrong with tech today. Certainly the telecomm industry needs more imagination.
So, Lee Dryburgh, who did an incredible job of organizing eComm 2008 (it’s the successor to the O’Reilly produced eTel conference) posted my presentation from eComm online last week, and I wanted to share it with you.
If you’re interested in more of the Roomba Asterisk specifics, ping me and I’ll blog in more depth about it.
When Apple announced yesterday that the iPhone would now be “location-aware” with the release of their 1.1.3 software, I was curious how they had done it.
I’ve been working with location information quite closely (see Twittervision, for example) for the last year or so and have had some conversations with different companies about how Apple might geo-enable the iPhone.
There are three options available:
Cell Tower ID
Wifi Access Points
GPS is not an option at present. E911 laws in the US have required carriers to provide location information for some time, but that could be via GPS or from cell tower triangulation data. TruePosition makes this their entire business, and is the primary location information provider for AT&T and T-Mobile in the US. A pretty cozy gig, eh? They do this by way of tracking cell tower information within the network, from what I understand.
GPS may be an option later if Apple adds an AGPS (assisted GPS) chipset to the iPhone or supports external Bluetooth GPS units, but external bluetooth will never be a true mass market phenomenon, and AGPS is at least going to have to wait for the next iPhone refresh, probably not til next year.
Cell Tower ID is another option. Carriers know where their cell towers are (we hope), and by comparing the signal strength and the intersection of multiple cell tower antenna distribution patterns, you can make a pretty fair guess about where the user is. It’s not always spot-on accurate, but it’s pretty close.
Wifi AP’s are the third option. There are millions of Wifi AP radios running around the world at this point, and for the most part, they tend not to move around that much. They do, however, come and go from time to time. However, there are a lot of them, and with a modest investment in driving around populated areas, one could build up a pretty accurate database of what APs are where. Then they could sell that database to people who want to know where their Wifi client radios are.
This is exactly what my friends up at Skyhook Wireless have done. You can try out their Loki service for your laptop (Firefox/IE plugin). Suddenly, if you have Wifi, you also have a pseudo-GPS capability.
Judging by the fact that Skyhook invited me to stop in and see them today at MacWorld (which I would have loved to do, but am sadly unable due to my being at home in Maryland this week), it seems Skyhook got the contract to provide some location data to Apple. Apparently, the iPhone uses both Cell Tower ID and Wifi (Skyhook) data for location, while the iPod Touch uses Skyhook exclusively. Good Job, guys!
This explains why when I went to see Skyhook in June and said that a company like Apple might be very interested in their technology, there was a definitive “no comment.” This happens a lot; companies like to protect what might be a very early-stage negotiation, or even an intention, a lot of the time. But in this case it looks like Skyhook bagged what might be their killer deal.
Yesterday, I succumbed to the hype and “Revirginized” my iPhone (we had been engaged in some unsavory hacking) so I could safely install the new 1.1.3 software update that Steve said would be available. The revirginizing and upgrade went as clean as could be, and now my phone is running 1.1.3.
I thought I might “inspect” what the phone is doing when you do a location lookup. I have a bunch of resources on my home network, including a multipurpose Linux server, so I thought if I could pass the iPhone’s traffic through the Linux box, some tools like ngrep and tcpdump might reveal what exactly happens when the iPhone tries to position itself.
Well, turns out I was mostly right. In typical Apple fashion, though, they’re keepin’ it real with HTTPS, revealing nothing very interesting about how the location information works.
The iPhone is 192.168.1.199 and my proxy is 192.168.1.10.
Here’s what I saw:
T 192.168.1.199:49311 -> 192.168.1.10:2525 [AP]CONNECT iphone-maps.apple.com:443 HTTP/1.0.Host: iphone-maps.apple.com.User-Agent: Apple iPhone v1.1.3 Maps v184.108.40.206A93.
T 192.168.1.10:2525 -> 192.168.1.199:49311 [AP][..HTTPS DATA...]
T 192.168.1.199:49311 -> 192.168.1.10:2525 [AP][..HTTPS DATA...]
So, alas, nothing to see here, really… move along. However, we do now know that Apple is grabbing data from the phone via HTTPS, processing it network-side, and rendering a response to the phone about its position. We do not, for example, see a variety of calls to Skyhook, Google, or elsewhere, which is not inconceivable without verifying it.
After the HTTPS call, we see this unencrypted call:
T 192.168.1.199:49313 -> 192.168.1.10:2525 [AP]POST http://iphone-wu.apple.com/glm/mmap HTTP/1.1.Accept: */*.Accept-Language: en.Accept-Encoding: gzip, deflate.Cookie: s_vi=[CS]v1|46B904DB00003607-A290B210000599B[CE]; s_nr=1199572400032.User-Agent: Apple iPhone v1.1.3 Maps v220.127.116.11A93.Content-Type: application/x-www-form-urlencoded.Content-Length: 145.Connection: keep-alive.Proxy-Connection: keep-alive.Host: iphone-wu.apple.com.
T 192.168.1.199:49313 -> 192.168.1.10:2525 [AP]..*..m..DN..en_US..com.apple.iphone.18.104.22.168A93......@.......?...&_...>....&`...>.......&]...>....&^...>....&\...>....&_...>....&[...>....&`...>.
T 192.168.1.10:2525 -> 192.168.1.199:49313 [AP]HTTP/1.1 200 OK.Date: Wed, 16 Jan 2008 12:38:31 GMT.Server: GFE/1.3.Content-Type: application/binary.Content-Length: 113.Cache-control: private.Connection: close.
Not sure what this all is, but it looks like it has my iPhone serial number in there. It’s so nice that Apple wants to know so much about my phone, its serial number, its position. Why, if DHS ever has any doubts about me, perhaps they could simply just ask Apple? Maybe they know where I am.
What is Apple’s position (pun intended) on customer privacy, now that they seem to be in the location data business?
Other firms like Boost Mobile’s Loopt service have gone to great (ridiculous) lengths to inform their customers about location data privacy and to protect collected data. So as to avoid potential problems, Loopt does not even save a location track for its users, but instead stores only the current location of the user. (This was the case when I spoke with them in May 2007.) They figure this makes them less of a honeypot for DHS types, and keeps their customers happy.
I have never believed that consumers are as paranoid about location data as the press (and the most paranoid among us) would have us believe. Most people are willing to generate, share, and publish some limited amount of location data if it provides some value to them in return and they can control the data sufficiently.
What seems like a simple software update for the iPhone is actually the consent of millions (4M+ according to Steve) of users to potentially publishing their location information. And not just for the iPhone, but for the iPod Touch as well.
Now the question is what a theoretical 1.2.0 software release might hold: location of your iChat buddies? Location-enabled Twitter clients (using the Twittervision API)? Your friends conveniently plotted on the Google Maps client? All of this is now theoretically possible with the iPhone and iPod Touch now, and Apple holds the keys.
It will be very interesting to see how the iPhone SDK (Software Development Kit) works next month. If Apple opens up this location service to third party developers, we can expect to see some very interesting applications emerge this year.
The fact that the location service is not down to meter-accuracy is irrelevant (it put me, alternately, within a few feet of my house and across the river at the Annapolis Mall — I suspect because it was alternating between an accurate Wifi position and a more general cell tower position). To make social location services work, all we really need to know is generally where someone is (nearby) and that they are really there (device has reported location).
There are plenty of apps where approximate location is sufficient (stores nearby, friends nearby, homes for sale nearby, etc). Only for driving-direction or aviation applications do you need meter-accuracy. A later update to the iPhone hardware with an AGPS chipset will solve that problem, but even without that, this opens up an amazing array of possibilities.
Mostly, great credit should go to Apple for pushing out a technology so seamlessly, so effortlessly, that so many others have found so problematic and full of legal and perceived landmines. This is a big deal. Skyhook, Loopt, uLocate, Nokia, Navizon, and dozens of others have been grasping for this holy grail for some time, and they’ve been told variously that it’s “impossible to get the data,” or that “consumers won’t go for it”, or that “no one would fund it.”
Apple did it via iTunes with a software update. Agree? Kudos, Steve.