The WiFi Pineapple - Using Karma and SSLstrip to MiTM secure connections

Using Karma coupled with SSLstrip the WiFi Pineapple can easily give you access to traffic that would normally have been encrypted. Even if a site enforces HTTPS you can still find yourself browsing an insecure version of the site.
pineapple

 

Introduction

In a few recent blogs covering Code Injection, Session Hijacking and Advanced Session Hijacking, it has hopefully become clear why Transport Layer Security (TLS / SSL) is important. TLS is what prevents anyone from accessing your traffic as it travels from your computer to the website you're visiting, and back again, by encrypting it. Unfortunately a lot of the responsibility ultimately resides with the user to determine if the site is secure and whether or not you should continue using it. Whilst a lot of websites quite proudly display security messages and pictures of padlocks asserting their security, there is only one single piece of reliable information regarding TLS and that's in your address bar.

twitter-secure

 

If your traffic to and from the site in question is protected with TLS (or SSL) then your browser will display https:// in the address bar and some information regarding the certificate of the site. If you click on the name of the certificate, or the padlock icon if you have one of those, you can view more information about the certificate.

twitter-ssl-certificate

 

To navigate to a site such as Twitter you most likely have a bookmark or simply type twitter.com into your address bar. When you hit the Enter key your browser will submit a HTTP request for the index page of twitter.com as HTTP is the default protocol and not HTTPS. At this point the servers at Twitter will respond by redirecting you to https://twitter.com to enforce a secure connection.

 

The Attack

SSLstrip works by monitoring HTTP traffic and waiting for links or redirects that use HTTPS. Once it finds a link or redirect using HTTPS it will transparently re-write it to the HTTP equivalent and pass it along to the victim. In the example above of navigating to http://twitter.com the Twitter servers will respond with a redirect to https://twitter.com that SSLStrip then replaces. Once SSLstrip has replaced that it stores a map of all the replacements it has made so it can continue to exchange traffic between the HTTPS connection to Twitter and the HTTP connection to the victim.

sslstrip-mitm

 

To get your Pineapple ready for the attack you need to download and install SSLstrip from the Pineapple Bar. You can see my previous blog for instructions on how to Install Infusions from the Pineapple Bar.

sslstrip-installed

 

That's it. No, really! You're now ready to launch a MiTM attack against clients connected to the Pineapple. Go ahead and start Karma and then start SSLstrip.

karma-running

sslstrip-running

 

Now any time that a client connected to the Pineapple requests a HTTP version of a site and is then redirected to a HTTPS version, they will never actually receive the HTTPS version. SSLstrip is going to proxy that away from the user and leave then communicating via good old fashioned HTTP. The big problem here is that it's down to the user to notice that the connection isn't secure and to stop using it. As I mentioned earlier, unless they specifically typed https:// into the address bar or happened to have a bookmark that points to a https:// version of the URL, the chances are they typed in twitter.com and made their initial request over HTTP. Even a fairly competent computer user may not notice the difference between the HTTPS connection and HTTP connection. Here are the results of typing in twitter.com before SSLstrip is running and when it is running.

sslstrip-twitter-secure

sslstrip-twitter-insecure

 

The same also applies to any links that may be found on webpages too. If they previously linked to a HTTPS version of a website they will now point to the HTTP version. Here you can see the source of my (very basic) page containing a link to https://twitter.com before SSLstrip is running and when it is running.

sslstrip-twitter-link-secure

sslstrip-twitter-link-insecure

 

Now SSLstrip is clearly working you might be rubbing your hands with glee at the prospect of access to all that unencrypted traffic! You could either fire up Wireshark to sniff on your local adapter or let loose with TCPdump to start dumping traffic onto the USB drive. Either of these 2 approaches would be a great way to get access to that data but there's an easier option. If you open the SSLstrip infusion the output tab will provide you with all of the POST data from any HTTP request that it has stripped the SSL from, because that's where all the tasty stuff will be, right?! This is incredibly convenient and gives you access to what would have previously been encrypted traffic at the click of a button. Oops, take a close look.

sslstrip-output

 

Mitigation

Up until recently there was actually no way to combat this attack from the server side. The WiFi Pineapple is a legitimate client connected to the server via HTTPS and the victim's browser is just rendering the webpages it has been sent. With the publishing of the HSTS specification in November 2012 came the first opportunity to prevent HTTP being the default protocol for communicating with a website when the user does not specify a protocol in the URL. I'm going to be covering HSTS in much more detail in a subsequent blog but in essence it is a HTTP response header that instructs the browser to only communicate with the server via HTTPS. If Twitter has the response header set and the user enters twitter.com into the address bar, the resulting URL would be https://twitter.com and not http://twitter.com as before. That was the weak link in the chain.

Until such a time when HSTS has become implemented in all mainstream browsers and adopted by all websites that use TLS, educating the end user is still the most effective tool against this form of attack. Verifying that your connection to a website is secured with TLS (or SSL) by checking the certificate and for https:// in the URL is key to defending yourself. If the connection is not secure then any information you send or receive may be accessible to an attacker.

 

Conclusion

It's worth pointing out that the above demonstration isn't a flaw with Twitter and they haven't actually done anything wrong. As far as they're concerned the WiFi Pineapple is a legitimate user connecting to their servers via HTTPS. They don't know that behind that device is actually a user being provided with a copy of the data over HTTP. The same would apply for any site that implements TLS in this fashion, which is, well, all of them. Once the use of HSTS becomes more widespread attacks of this nature will become less and less effective. Until then, you're responsible for being vigilant whilst online and ensuring your own protection.

 

Responsibility

Using the WiFi Pineapple and just a few clicks I have demonstrated just how easy it is to become the victim of a MiTM attack. The aim of the demonstration is to highlight how the responsibility is on you, the end user, to ensure that you are communicating via a secure connection where appropriate. After previous demonstrations of a similar nature I have had concerns raised that this information could be used for malicious purposes. Whilst this is unfortunately true I believe that well equipped and capable attackers are already out there taking advantage of attacks such as these. The only real way to defend ourselves against these forms of attack is to be educated about them and to understand them.

 

Scott.
Short URL: https://scotthel.me/PineappleSSLstrip

Author image
About Scott
Researcher, blogger and international speaker. I'm the creator of report-uri.io and securityheaders.io, free tools to help improve online security.