This post was first published in 2011, and while many of the most widely-used web sites have adopted practices to minimize the risk from the particular attack described here, the basic principles still apply. And since the Firefox plug-in is now widely known, I don't mind mentioning that the plug-in is Firesheep.
This is my first foray into the blogosphere, but it probably won't be my last. I'll get to my topic in a moment, but first a little about me. I'm a 14-year veteran of Intel IT, with roots in appdev support, system administration, and for most of the last decade, information security. My specialty is cyber threat intelligence - software vulnerabilities and patching, malware, social networking risks, etc. When not at work, I spend my time raising five rambunctious kids - twins age 10, a 9-year-old, and twins age 7. In amongst that, I teach youth Sunday School, and am the Commander for a Wednesday night Awana club at my church, teaching some 30+ preschool through 6th grade kids. Follow @DSTX_Awana to see what is going on in our club.
But enough about me. You're really here because you saw the title of the blog and are curious. So, let's say you are flying commercially and have a couple-hour layover, so you decide to hop on the airport's free wifi to surf the web. Or maybe you reached your destination and are browsing from your hotel room. Either way, you are using a wireless Internet connection that allows open access (in other words, it did not require you to enter a complicated security key before you could access the network).
Most of us know by now to look for the little "padlock" icon in the browser status bar before logging in to a web site, or the "https://" at the beginning of the URL - we want to be sure our password is protected, right? And most sites now use an SSL (secured) connection for the login page - your password is in fact protected. But once you log in, most non-banking sites will go back to non-secured. That's OK, right? Your password is safe, and now you're just updating your status in Facebook, tweeting your latest thoughts on Twitter, things you want to be public anyway, right?
Well, not quite. How does the web site know who you are after you have logged in? It is usually done with cookies - little bits of data stored on your computer, and automatically sent to the site that created them every time you load or reload a page from that site. The cookies usually do not contain your password, but they do identify you to the site. So, if you log into Facebook, then click a link to reload the page, your computer sends your cookie to Facebook, and the site says "hey, I remember who you are, I saw you just a minute ago; you are already logged in, so here you go!" (OK, not literally, but you get the point).
The problem is, that cookie is sent in the clear. If someone were able to steal that cookie, even without your password they could pretend to be you, and could update your status, message your friends, or do anything else you can do, and Facebook would think it was you doing it. But stealing cookies is hard to do, right?
Well, not any more. Last October, a researcher in Seattle released a sample plug-in for Firefox that makes this almost as simple as point-and-click. Anyone using the same airport / hotel / restaurant / other public wireless access point as you, can run this plug-in and see a list of people's accounts they can impersonate. The attacker can then click on whomever they would like to impersonate, and voila: they are you. And it's not just Facebook. Amazon.com is vulnerable. Google is vulnerable. The New York Times, Flikr, eBay, Netflix, and hundreds of other sites are vulnerable.
I am purposefully not naming the plug-in, as my intention here is not to facilitate someone doing this (though it is not hard to find). My intention is to educate. What can you do about this? Well, the only complete solution is to use an SSL connection the entire time you are on a web site, instead of just for logging in - but you don't really have any control over that. If a web site lets you log in over SSL, then puts you back on an unsecured connection after logging in, well, you're stuck.
One alternative is to use something like HTTPS-Everywhere, which forces Firefox and Chrome (but not other browsers) to use SSL on certain sites. It only works on a defined list of sites, and still depends on the site owner to support SSL, so it's far from a perfect solution, but it is at least something. Another alternative (and personally, one I try to live by) is to limit what you do on an open wireless network. Read the news, check sports scores, and do other things that do not require you to log in - there is very little for someone to intercept if you are not using sites that require identifying yourself. I won't do banking transactions unless it's on a network I know to be secure, for example.
The next best thing is to browse through VPN. VPN routes your Internet traffic through an encrypted tunnel, securing the entire communication channel until it reaches the remote network. It doesn't completely eliminate the possibility of that traffic being intercepted, but it means the attacker has to get into the employer’s network first. As a side benefit, if your employer uses web proxy filtering (most do), the web proxy filters may prevent accidentally accessing a page (or an advertisement) known to host malware. The next time you hear an infosec geek suggest always connecting to VPN before browsing the web, you'll know why!
This is my first foray into the blogosphere, but it probably won't be my last. I'll get to my topic in a moment, but first a little about me. I'm a 14-year veteran of Intel IT, with roots in appdev support, system administration, and for most of the last decade, information security. My specialty is cyber threat intelligence - software vulnerabilities and patching, malware, social networking risks, etc. When not at work, I spend my time raising five rambunctious kids - twins age 10, a 9-year-old, and twins age 7. In amongst that, I teach youth Sunday School, and am the Commander for a Wednesday night Awana club at my church, teaching some 30+ preschool through 6th grade kids. Follow @DSTX_Awana to see what is going on in our club.
But enough about me. You're really here because you saw the title of the blog and are curious. So, let's say you are flying commercially and have a couple-hour layover, so you decide to hop on the airport's free wifi to surf the web. Or maybe you reached your destination and are browsing from your hotel room. Either way, you are using a wireless Internet connection that allows open access (in other words, it did not require you to enter a complicated security key before you could access the network).
Most of us know by now to look for the little "padlock" icon in the browser status bar before logging in to a web site, or the "https://" at the beginning of the URL - we want to be sure our password is protected, right? And most sites now use an SSL (secured) connection for the login page - your password is in fact protected. But once you log in, most non-banking sites will go back to non-secured. That's OK, right? Your password is safe, and now you're just updating your status in Facebook, tweeting your latest thoughts on Twitter, things you want to be public anyway, right?
Well, not quite. How does the web site know who you are after you have logged in? It is usually done with cookies - little bits of data stored on your computer, and automatically sent to the site that created them every time you load or reload a page from that site. The cookies usually do not contain your password, but they do identify you to the site. So, if you log into Facebook, then click a link to reload the page, your computer sends your cookie to Facebook, and the site says "hey, I remember who you are, I saw you just a minute ago; you are already logged in, so here you go!" (OK, not literally, but you get the point).
The problem is, that cookie is sent in the clear. If someone were able to steal that cookie, even without your password they could pretend to be you, and could update your status, message your friends, or do anything else you can do, and Facebook would think it was you doing it. But stealing cookies is hard to do, right?
Well, not any more. Last October, a researcher in Seattle released a sample plug-in for Firefox that makes this almost as simple as point-and-click. Anyone using the same airport / hotel / restaurant / other public wireless access point as you, can run this plug-in and see a list of people's accounts they can impersonate. The attacker can then click on whomever they would like to impersonate, and voila: they are you. And it's not just Facebook. Amazon.com is vulnerable. Google is vulnerable. The New York Times, Flikr, eBay, Netflix, and hundreds of other sites are vulnerable.
I am purposefully not naming the plug-in, as my intention here is not to facilitate someone doing this (though it is not hard to find). My intention is to educate. What can you do about this? Well, the only complete solution is to use an SSL connection the entire time you are on a web site, instead of just for logging in - but you don't really have any control over that. If a web site lets you log in over SSL, then puts you back on an unsecured connection after logging in, well, you're stuck.
One alternative is to use something like HTTPS-Everywhere, which forces Firefox and Chrome (but not other browsers) to use SSL on certain sites. It only works on a defined list of sites, and still depends on the site owner to support SSL, so it's far from a perfect solution, but it is at least something. Another alternative (and personally, one I try to live by) is to limit what you do on an open wireless network. Read the news, check sports scores, and do other things that do not require you to log in - there is very little for someone to intercept if you are not using sites that require identifying yourself. I won't do banking transactions unless it's on a network I know to be secure, for example.
The next best thing is to browse through VPN. VPN routes your Internet traffic through an encrypted tunnel, securing the entire communication channel until it reaches the remote network. It doesn't completely eliminate the possibility of that traffic being intercepted, but it means the attacker has to get into the employer’s network first. As a side benefit, if your employer uses web proxy filtering (most do), the web proxy filters may prevent accidentally accessing a page (or an advertisement) known to host malware. The next time you hear an infosec geek suggest always connecting to VPN before browsing the web, you'll know why!
