What is Firesheep?

You may remember about 4 years ago Eric Butler released a Firefox extension that did something very clever. It hooked into a packet capture library and could capture cookies that weren’t sent over SSL, at an open Wi-Fi access point. That extension was Firesheep. The press grabbed onto this story as it made “hacking” into someone’s Facebook account something almost anyone could do. At the time, many sites would shuttle you securely over https:// for the login and then give you an authentication cookie that was served insecurely over http://. This authentication cookie is the thing that proves you are who you say you are so if a bad guy got access to this cookie, they could easily impersonate you on that site.





What is SSLStrip?

SSLStrip was less publicized than Firesheep. Probably because it doesn’t demo quite as well. It was released by Moxie Marlinspike at Blackhat in 2009. It basically involves the attacker gaining control of someones traffic, usually by spoofing their ARP table. From that point you strip out all the secure connections and replace them with insecure ones. The major problem with SSLStrip is that it often can be detected by the end user. If they notice.

What was the fallout from Firesheep and SSLStrip?

With Firesheep many news stories focused on Facebook, but a lot of sites on the internet were not securing their cookies properly. For sites that didn’t secure their cookies properly there were two approaches to fixing this issue. The first approach was to rollout https:// across the entire site, which some sites did(e.g. Google, Facebook, Twitter). The other approach was to simply secure authentication cookies by sending them over https://, while still having the majority of your site still served over insecure http:// connection, which is what most sites did.

I think that SSLStrip’s effect was more felt in the information security community than in how the Web was used by people. It turned a theoretical weakness in the way HTTP worked into a trivial attack. Again some sites solved the problem as best they could by rolling out https:// sitewide. Some sites didn’t.

Cookies secured, so, problem solved, right?

Both solutions solved the issue of the attacker passively scooping up insecurely transmitted cookies at an open Wi-Fi access point.

Let’s think about how you log into Facebook. If you are an average user, you Google “facebook” or some such term. Your search is sent over https, you click on a result that takes you to https://facebook.com, another secure connection. You type in your email and password which is HTTP POST’ed to a secure page, that sets your cookies to be securely transmitted. Not much a bad guy can do here.

Let’s think about how you log into a site that doesn’t have https:// across their entire site, in this example let’s use Amazon. If you are a normal user you Google “Amazon” or some such term. Your search is sent over https, you click on a result that takes you to http://amazon.com, an insecure connection. You click on “Your Account”, you are sent to a secure https:// page where you type in your username and password the authentication cookie is set to be transmitted securely. You have logged in over https:// so again not much a bad guy can do here right?

Why having your entire site served securely matters

Most people think of SSL/TLS as a method for making it difficult to listen in on a conversation that is happening between you and a website. Maybe if you are a little saavy, you also know that it helps you verify that you are talking with the site you intend to. But the other thing SSL/TLS does is help you know that the web page being served to your browser is the same as it was when it left the server. So if a page isn’t being served over https://, It can be tampered with.

FireSheep and SSLStrip Today

So what can we do with what we know? It turns out that Firesheep doesn’t really work so well today. It requires you to have a very old version of Firefox and is pretty fragile. You have to hardcode in web application specifics for it to work with new sites. Firesheep was awesome for what it was, but it is not penetration testing tool, it is a novelty. A few years ago Matthew Sullivan, made a much more refined alternative called “Cookie Cadger” which isn’t bound by these issues. It basically lists MAC addresses it sees and keeps track of what cookies it sees associated with those MAC addresses as it captures traffic. In the original Firesheep implementation, it was listening in on unencrypted traffic passively at an open Wi-Fi hotspot. If we were to turn this into an active attack using arpsoof or by being a rogue DHCP/DNS server this would work with most wired or wireless networks. Once we have spoofed the client, we can use SSLStrip to turn secure connections into insecure ones. SSLStrip takes advantage of the fact that, http doesn’t have a method for you to verify that the information received by your browser hasn’t been tampered with. Therefore when you are on http://amazon.com, all of the secure https:// login links are turned into insecure http:// links and SSLStrip acts as a proxy. The result is that you can hijack the connection while the user is connecting to the insecure part of the site and then use Cookie Cadger to steal authentication cookies. SSLStrip will also log all unencrypted post requests which include usernames and passwords.

Wait a minute… I think I might know if I was being SSLStripped.

Are you so sure about that? If you are like me, a security nerd who investigates to see if pages POST securely, or at least check for the presence of “https“ in the a URL that you are inputting credentials into, then this article isn’t for you. This article is to make people who are just average people, aware that this is a problem on the internet. Each set of the following images has one image that is secure and one of someone who is a victim of SSLStrip. If you were just browsing the internet the way you normally do, could you tell the difference? Would you be suspicious? Would you log into either of them?

Internet Explorer

Firefox

Chrome

As we can see most browsers have really de-emphasized notifying the user about whether or not a user’s connection is secure or not. Even if people are a bit security/privacy conscious, they may not notice the lack of “https” in the URL bar. Most of the browser vendors have really de-emphasized when you are using https.

What about Extended Validation certificates?

Hopefully, the above images have illustrated my point, people notice the presence of something not the lack of something, even more so for Extended Validation certs. EV certs make people feel warm and fuzzy when they see them. If they don’t see them, they are not worth the paper they aren’t printed on.

Shouldn’t you tell these companies through a process like responsible disclosure?

Disclosure is appropriate when something is an unknown vulnerability. You don’t get to work in information security at a place like Amazon or Ebay or other huge companies without knowing that this is a potential problem. This isn’t a vulnerability and it isn’t unknown. We have known about SSLStrip and Firesheep for 4-5 years. Some sites have solved this issue and some clearly have chosen not to. There is a lack of will within the industry to do the right thing. This post should shock very few people in the information security community, but my hope is that it will make you think twice about the services you use on a daily basis. If they are only willing to do the bare minimum to keep you secure then maybe you should let them know, or take your business elsewhere. You will notice that this article doesn’t go into exact specifics about how to perpetrate this attack. This is not a recipe for how to hack your neigbour, your office, your school as doing so without permission is illegal.

Doing the very least

My biggest frustration is with many sites is that if you attempt to connect to them securely, they redirect you back to an insecure connection. They are actually doing more work then if they just served you the page securely. There are also many sites, like Reddit and Wikipedia, that haven’t committed to only serving their content securely, but do allow you you to use the site securely if you choose. While it is nice to be able to opt-in to security like this, I don’t understand how this is easier to support then just having secure connections rolled out across the board.

I’ll give you some more food for thought. It always surprises me how few news sites use https://. Is it important for you to be sure that the news that you are reading hasn’t been tampered with? If that is important to you, then maybe you should use sites that are accessible over a secure connection.

I want to know why?

In 2015 we shouldn’t have to worry about whether or not we can log in securely to a website. It shouldn’t have to be a conscious thought in any of our heads, “jeez, I didn’t check that time. I hope that login was over https”. There should be a secure chain of custody that happens between sites and the links that they send down to your browser. We need to stop seeing SSL and TLS as merely encryption and see it for its authenticity and verification properties. If you can’t trust the page that takes you to the login page, you may not be able to trust the login page.

Let’s start a conversation. If you work in a big company why do you still support plain text connections? If you are a user, do you think that it is acceptable in 2015 for companies to continue to do the bare minimum?

Conclusion

2014 was a big year for privacy, encryption and TLS. I used to be on the fence about whether or not most sites on the web should be served securely. I have no doubt, that they need to be. We need to start expecting it, and talking about it and doing it. I think by the end of 2015 we are going to be asking the last of the major sites, “Why no TLS?”.

Feature Image Credit.

Share this: LinkedIn

Reddit

Facebook

Twitter

