Servers

HTTPS: Surf jacking makes it vulnerable

Cookies and redirection seem to be this year's "attack vector du jour." At DefCon, Mike Perry gave a rather disconcerting talk about surf jacking and how it can be used to capture SSL session cookies. Michael Kassner would like to explain how surf jacking compromises HTTPS security.

The infamous cookie causes yet more grief

Michael KassnerIn reality, it's not the cookie that causes the problems; they are just an easy way to subvert HTTP and now HTTPS connections. There are two major categories, persistent cookies and session cookies. It's important that we know the difference between the two when discussing how surf jacking works:

  • Persistent cookies are so named because they have a time-to-live that lasts longer than the current Web-browsing session. The first- and third-party cookies I discussed in my article about Behavioral Targeting and Deep Packet Inspection would be considered persistent cookies. Persistent cookies have very little to do with the actual Internet connection.
  • Session cookies only last the length of a Web-browsing session. More importantly, they carry information that validates the Web browser to the Web server.

To help explain, let's look at the life of a session cookie in the following example:

  1. Using my Web browser, I log on to https://www.mybankxy.com.
  2. The mybankxy.com Web server authenticates my credentials and places a small text file on my computer, called a session cookie. The session cookie contains pertinent user log-on and security information.
  3. After the portal Web page opens, I click on a link for the Web page with my savings information.
  4. My Web browser sends the Web page query and my session cookie back to the mybankxy.com web server.
  5. The session cookie allows the Web server to reverify who I am. If everything is in order, the Web server then sends the Web page I asked for. Without the session cookie, I'd have to log in each time a new Web page was served up.
  6. After I complete my transactions, I log off the Web site https://www. mybankxy.com. The session cookie then invalidates itself and is deleted.

So, session cookies are useful -- browsing the Web without them would get annoying real fast. Another function of session cookies is to remember actions that take place on a Web page. This is especially important if session information may be needed on a different Web page on the same Web server. A prime example of this would be a Web site that uses shopping carts; without session cookies the items purchased wouldn't be remembered when the Web browser asked for the check-out Web page.

301 Moved Permanently

Now, I'd like to take a look at HTTP redirection. In that same article about Behavioral Targeting and Deep Packet Inspection, I talked about redirection being a key component to getting illegitimate cookies installed on a computer. As you will see in the following example, surf jacking also uses redirection, but a slightly different version of it called the "301 Moved Permanently" HTTP error. As the name suggests, the 301 redirection is considered permanent. The code also contains the URL of the missing or renamed page as well as the URL of the new page.

Surf jacking

First a little history, almost a year ago Robert Graham introduced "Side Jacking" at Black Hat 2007. It was such an interesting concept that I covered it in the article "Can Your Wireless Network Be Sidejacked?" Side jacking is a clever way of stealing HTTP session cookies, allowing the attacker to actually hijack a HTTP session without knowing any log-on credentials. That was a year ago, and now there are proof-of-concept attack tools to do the same thing with SSL connections, which is scary. However, knowledge is power, so let's take a look at how surf jacking works by following the steps of an attack:

  1. I log in to my online bank at https://www.mybankxy.com. I need to move some money to my debit card as I'm buying something online.
  2. Once again the mybankxy.com Web server authenticates me and places a small text file on my computer, called a session cookie.
  3. I forgot the amount I needed, so I open a new browser window and go to http://www.commercexy.com.
  4. Just my luck there's an attacker sniffing traffic on the same Wi-Fi hotspot. So the attacker already knows that I have an active HTTPS (encrypted) session to www.mybankxy.com and that I just opened a HTTP (in the clear) session to www.commercexy.com. It's a perfect opportunity to run the surf jacking attack.
  5. The attacker sends back a "301 Moved Permanently" in response to the Web page query I sent to www.commercexy.com.
  6. The redirection now occurs as the 301 response contains the header http://www.mybankxy.com. This is telling my Web browser it needs to go to http://www.mybankxy.com to find the http://www.commercexy.com Web page I was looking for. Notice that the response is using HTTP and not HTTPS.
  7. My Web browser now starts a new and unsecured connection by sending a query to http://mybankxy.com, and since my first HTTPS session to www.mybankxy.com is still open, the session cookie is valid. Therefore, this second query contains that same session cookie.
  8. Since the attacker is sniffing all my traffic via the open Wi-Fi hotspot, the session cookie is captured. Done deal.
  9. In order to give the appearance that nothing happened, the attacker then sends another "301 Moved Permanently" finally sending my browser to the Web site http://www.commercexy.com.

That's the attack. Granted, there are certain conditions required to pull the attack off, but it's entirely possible. I wouldn't want an attacker going to https://mybankxy.com and using the captured session cookie to change my log-on credentials or even worse. For more details on the attack, please go to the "Enablesecurity.com" Web site and watch the demonstration. It shows how surf jacking can be used against a vulnerable Gmail account.

Prevention consists of two parts

The immediate solution to surf jacking is easy, just never open a HTTP session if you have an active HTTPS session. The long-term solution is more complicated and involves Web site developers. Sandro Gauci of Enablesecurity mentions how the attack can be mitigated, along with some potential rollout issues:

"Cookies can have a flag called "secure," which when present causes the browser cookie to be sent only through encrypted channels. When the web browser is redirected to a clear text channel (HTTP rather than HTTPS), such cookies are not included in the HTTP request. This behavior solves the problem described and can be easily implemented on web services that separate services that need encryption from those that do not. One such service is E-banking, which is normally segregated on a web site such as https://secure.bank.com/.

However there are cases where setting the Cookie secure flag is not an easy option. A web service such as Google shares a session and credentials across various domains and switches between HTTP and HTTPS depending on the service. In this case, the solution is not as easy as setting the Cookie to "secure" because that would not scale well with the rest of the infrastructure. Google appears to be have mitigated this for Gmail by providing the "use only HTTPS" option - but other Google services such as Google Docs remain vulnerable to attack."

Final thoughts

Surf jacking as an attack vector is serious. Hopefully, this article will be a reminder to always use good Web-surfing practices, especially now making sure to only have one Web-browser session open if it's a HTTPS connection. I realize that surf jacking requires an attacker to be in a position to capture traffic, but theoretically that can take place anywhere along the traffic's path. I just wouldn't want to take a chance on having personal information stolen or worse yet trying to figure out why my bank accounts are empty.

-------------------------------------------------------------------------------------------------------------------

Michael Kassner has been involved with wireless communications for 40 plus years, starting with amateur radio (K0PBX) and now as a network field engineer for Orange Business Services and an independent wireless consultant with MKassner Net. Current certifications include Cisco ESTQ Field Engineer, CWNA, and CWSP.

About

Information is my field...Writing is my passion...Coupling the two is my mission.

113 comments
travisn000
travisn000

One of the 'security features' of new google chrome browser is that every tab is a completely different process (open a few tabs then check your running processes in taskmgr); has any one tested this attack against Google Chrome?

ederkley
ederkley

Does anyone know of a way to enforce HTTP or HTTPS sites only opening in a particular browser? For example, if using IE7 and Firefox, and I'm in IE7 and select a HTTPS link, the page opens in Firefox or if I'm in Firefox and access a HTTP link it opens the page in IE7? or alternatively if I'm in IE7 and try and access a web-page it gets 404'd or something to remind me to open it in Firefox. Can Opera or other browsers do this? Actually, I just remembered there was a buggy addon for Firefox 2 that allowed pages to be rendered using IE7 browser window within Firefox - that would probably create a new cookie wouldn't it? https://addons.mozilla.org/en-US/firefox/addon/1419 Might be a quick-and-dirty yet still relatively convenient way of dealing with this issue. Might have to explore that further...

mailstop29-x
mailstop29-x

Is this only a problem for users of wireless Internet connections?

Jacdeb6009
Jacdeb6009

Thanks!! This has alerted me to a real problem. I will thus install a second browser and use it for browsing HTTPS site (Firefox has way to many bookmarks to change this :) ) I will also pass this on to other that I know are exposed to the same risk. Thanks for a clear and simple explanation of a potentially serious problem!!

ederkley
ederkley

Ok - so assuming we have someone overseas in a country known for electronic espionage and they are being actively monitored. If our people use a laptop to access https websites (ie. Outlook Web Access) but are using say a hotel's broadband or wireless solution (so basically insecure). Can we now assume there is a reasonable risk of someone being able to hijack those sessions if our person accidentally opens the second browser session to a http webpage? Ouch ouch ouch!

lopsl
lopsl

It is good that there are people like Sandro who take security issues like this seriously and seek to develop applications accordingly. If I understand correctly, the secure flag in the cookie is set by the website application and not the user. From what I've read here, it would seem that unfortunately there are many website developers who are not aware of this and therefore place their website users in a vulnerable position. What would happen if the user modified the cookie and sets the secure flag after the session has been initiated? Do you know of any secure website development software that sets this secure flag automatically when SSL is used? I have seen many websites that present forms for personal information entry that do not even use SSL (as indicated by the https url). I refuse to submit information on those websites and provide feedback instead - which is usually ignored.

GreyTech
GreyTech

A great discussion, thank you Michael. I have been using IE tab for a couple of years without problem except on the very early releases. However ederlkley raises an interesting point. Using IE tab does appear to create a completely new session and does not use cookies from firefox but from IE this could be a convenient work around but you must be careful not to use a bookmark to open the session because it will default back to firefox. IE Tab has a nice option to specify particular sites to default to using IE engine is would be easy to make it default to using IE for all https sites just the same as I make it do so for all Microsoft ones, I would still have to make sure that I didn't have a Microsoft site open if I was going to one of my secure sites.

seanferd
seanferd

For Windows, associate the http extension with one browser, and https with the other. The associations may need to be locked so they won't change, which might be accomplished through some policy setting. I'll see if I can get that to work, but I'm not sure it will. Anybody have an idea on this?

grax
grax

I cannot say whether it would do as you suggest but I find your comment that it's buggy curious. I've been using this add-on for the past year and even Microsoft's web site thinks it works!

Neon Samurai
Neon Samurai

.. but that just brings you back to the issue of changing the identity string. If browsers where universally updated to not allow that change easily, you can always capture your outbound traffic and change it on the wire. The best solutions the fellows presenting at HOPE came up with was centralized blacklists for bad ssl certs or using certs above 2048 bits. "Crippling Crypto: the Debian ..." from thelasthope.org/talks.php

Michael Kassner
Michael Kassner

I'm not sure about that Firefox add on, but Sandro Gauci (researcher from EnableSecurity) is working on an add on that will detect whether the secure flag is set or not. Hopefully, web site developer will just configure the flag and the problem will go away. Also if you are interested Sandro made several interesting comments on this post.

Michael Kassner
Michael Kassner

Surf jacking transcends access methods. The only real requirement is the ability to sniff the data packets from the victim computer. One of the easiest methods is to sniff an unencrypted Wi-Fi connection. That said if the attacker has access to a switch to which the victim is connected, the data packets could easily be sniffed that way as well. The other concern is the chain of trust from one end of the connection to the other. Usually data packets require multiple hops to get to their destination and in many cases our only option is to trust that packet sniffing does not occur along the path.

Michael Kassner
Michael Kassner

Your assistance in passing the information along helps all of us and that makes it worthwhile.

sandro
sandro

It is definitely an idea - one which I'm exploring. I can imagine that some sites might break, while others would not depending on how separate the HTTP and HTTPS sites are.

Michael Kassner
Michael Kassner

I asked Sandro about this and these are his comments: If a new instance of IE or Firefox is started and the cookie is not persistent, then the new instance should not know the previous cookie. This means that if authentication is involved, the user will be asked to login and a new session is issued to the user (not necessarily in that order). If you start a new tab in IE or FF and your browser asks you to log in, it does not necessarily mean that the web application issued a new session. The logic like this in my mind: Scenario 1: 1. Web browser has an authenticated session. The cookie is session=someuniqueid and not persistent. 2. New web browser instance is started which has its own process (i.e. its own memory space etc). Since the cookie is not persistent, the cookie is not set on this new instance since the memory etc is not shared. Scenario 2: 1. Same as Scenario 1's step 1. 2. If I start a new tab in the first instance (in step 1), that will usually be part of the 1st instance on the client's computer. Will use the same memory and inherit the same session cookies. If the browser is asked to login, it may mean various things, but it does not necessarily mean that the web application issued a new session. If the previous session still works on your original tab (the one in step one), then that means that the session is still present. Seems to make sense, I guess my hope is that Sandro gets the Secure flag add-on figured out, so we know for sure if the secure flag is set and this issue goes away.

Michael Kassner
Michael Kassner

That would be great. I will ask Sandro about this as he's the expert. If a new tab would start a new session cookie I'd like that.

ederkley
ederkley

Only played with it very briefly a year or so ago and while some pages worked others didn't. The notes with the addon at that time mentioned there were pages that would not render correctly and other users had reported similar issues. However, I note there are still positive comments on the Firefox page for this addon - I will be revisiting it's use shortly :)

grax
grax

This has been one of the best topics/discussions I've read at TR. Topical, germane, no Trolls and no abuse!; some good ideas for further discussion and most importantly, we have a valid conclusion. Many of us are obliged to use unsecured WiFi networks for secure reasons. Whilst I try to take every precaution (for threats that I know about) I didn't know about this one. However unlikely it is, there is a clear threat. Time to fire up Opera for HTTPS. I use Firefox for everything else. Thanks to Michael and to everyone else.

ederkley
ederkley

(I'm in a small .gov agency myself and thought we were keeping reasonably ahead in the security exploit game given our size :P ) We currently provide OWA and an IPSEC-based VPN but I know many other agencies also provide Outlook Web Access or even https-based VPN portals. Wouldn't this exploit work virtually regardless of the level of security on the laptop? As far as I can see the only workarounds if you are in a country known for espionage (and most government employees would have to be considered a possible target) are: - to use an IPSEC VPN and access secure websites through the work connection, or - remember to not ever open that second http webpage.

Michael Kassner
Michael Kassner

You are definitely my anchor. I am less than impressed with NoScripts. My portable FF3 browser just totally died when I installed NoScripts. The strange thing is that I've been hearing so many good things about NoScripts. I guess maybe it' where they just peek at it and don't give it a good workout. Can you let me know how the developer's kit allows you to set the secure flag? I'm jealous yet again. You have so many talents, it never ceases to amaze me. Kudos to you my friend.

seanferd
seanferd

but it isn't forcing a secure flag for me. The only site I use for which I really require a secure connection does set the secure flag. My other test site was addons.mozilla.org, which is apparently not setting the secure flag. NoScript isn't forcing the flag, and indicates that it is not a secure connection if the first place. Several apps, including Firefox itself and the Online Armor firewall say that it is a secure connection (https) dyna-addons.nslb.sj.mozilla.com:443 63.245.209.31:443 https://addons.mozilla.org/ With the developer tools add-on, I can manually set the secure flag. I think I'm going to wait and see how this thing develops, it isn't working as far as I can tell, but it is experimental (not even a beta, really). Also note that when fully functional, it is still limited by how https is used by sites anyway, e.g., it doesn't really help if sites just use https for login. No user interaction in the add-on as of yet except for settings. http://noscript.net/faq#qa6_1 http://hackademix.net/2008/09/10/noscript-vs-insecure-cookies/

Michael Kassner
Michael Kassner

I'm not sure, but NoScript seems to have broken my portable application of Firefox 3. I wasn't all that happy with NoScript myself. It's not really that intuitive and doesn't allow me to do things that I thought it should.

lopsl
lopsl

I've tried verison 1.8.0.6 with Firefox 3.0.1 on several https sites where the session cookie indicates that it is used for any type of connection rather than for encrypted connections only. However, there is no pop up window or any sign that the session cookie has been modified to set the secure flag. One example I tried is the www.anz.com.au logon. You need to allow script execution for this site first. After the logon window pop up indicates that it is a secure site all the session cookies do not indicate they are to be used with secure connections only. update: Apparently 1.8.0.6 did not have this functionality because a new version 1.8.0.7 has appeared which adds this functionality in an Advanced configuration option. I tested it with the same site and confirm that with automatic secure cookies management enabled, the session cookies now indicate they are to be used with encrypted connections only. However, once logged in, it is interesting that the page info now states that no cookies are being stored locally even though they are.

seanferd
seanferd

Since some governments don't allow privacy anyway, and others are trying to do away with it because they are becoming lazy investigators, not to mention the national governments of some countries are becoming the police force of private industry. These industries are too lazy to file suits in civil court and actually produce evidence, so they get organizations like the FBI to arrest people with criminal charges, and feel they should be able to do anything they like with networks and logs to protect their IP. Pretty sad, all the way around.

Michael Kassner
Michael Kassner

I think a small window opens up asking what you want to do.

Michael Kassner
Michael Kassner

I fail to see why everyone is so determined to eliminate any user privacy.

seanferd
seanferd

U.N. agency eyes curbs on Internet anonymity Politics and Law - CNET News

seanferd
seanferd

Just read about it late last night, so I haven't had the time yet. To even test these rather interesting bits of software, I rather have to go out of my way to pull up secure sites, as I don't normally hit too many. I can think of two sites off the top of my head just now, so I'll check in after I get a chance to try this out. I'm hoping there will be some obvious user interaction for this feature, like a message that the header was intercepted and the flag was set. I'd still need to pull up the cookie text to confirm anyway, but an alert would still be nice.

Michael Kassner
Michael Kassner

Very cool, I'll have to tell Sandro. Have you tried the beta version, yet?

seanferd
seanferd

Experimental setting in a new version of the NoScript browser add-on provides for interception of the Set Cookie header, allowing the secure flag to be forced. Author Giorgio Maone: "NoScript 1.8.0.5 just intercepts the ?Set-Cookie? headers which are being sent over encrypted connections and are not flagged as ?Secure? yet, adding the missing attribute on the fly before the cookie is stored." NoScript mitigates HTTPS cookie hijacking attacks Found at the Zero Day blog, ZDNet. Ryan Naraine, Dancho Danchev & Adam O'Donnell This version of NoScript is an unofficial development build, found on this page: http://noscript.net/getit which also has the stable version available at the top of the page. (Stable version does not include the Set Flag functionality.)

Michael Kassner
Michael Kassner

I did mis-read your comment. That's an interesting question and I also wish that people more knowledgeable in web browsers would respond to these questions. I'll ask Sandro about this as he may have some insight.

GreyTech
GreyTech

Perhaps I didn't explain my self clearly enough. The way to get a new session in FF is to open an IE tab. As it is using the IE engine not FF it creates a new IE session and so ignores all FF cookies. You do have to make sure that if you are using the IE tab for https that you do not already have some IE tabs open using http. It would be interesting to hear from a Mozilla specialist whether my approach is as secure as I think it is.

seanferd
seanferd

then yes. I'll have to re-read the bit on sessions and persistence.

Michael Kassner
Michael Kassner

We just have to make sure that a new session cookie is started

seanferd
seanferd

https://addons.mozilla.org/en-US/firefox/addon/35 IE View Allows one to set certain sites to always open in IE. About wraps that one up, no? edit: Found while looking for various extensions after installing FF3, so I could use Perspectives. I had to make sure FF# would not trash my SeaMonkey installation.

seanferd
seanferd

Thanks. So, perhaps either cookies need to become more specific, or for a site that uses SSL for some connections, all connections could be made secure. Probably not good ideas, just throwing it out there. It seems more complex the more I hear about it.

Michael Kassner
Michael Kassner

I wish I understood it more, but it seems that there are domains that have multiple sites referenced together, and that somehow affects the secure flag. This is from Sandro: "A web service such as Google shares a session and credentials across various domains and switches between HTTP and HTTPS depending on the service. In this case, the solution is not as easy as setting the Cookie to ?secure? because that would not scale well with the rest of the infrastructure. Google appears to be have mitigated this for Gmail by providing the ?use only HTTPS? option - but other Google services such as Google Docs remain vulnerable to attack."

seanferd
seanferd

If I ran websites, and/or knew how to write code, I'd be using that feature of cookies. It is odd that so many do not.

Michael Kassner
Michael Kassner

I wonder if that could be pushed out using group policies? I just wish this was visible enough so that people hosting secure web sites would just set the secure flag as that's the simplest fix. I guess there are some issues with that though. Sandro mentioned something about that.

seanferd
seanferd

Unfortunately, this will not stop one from opening secure and non-secure sites from within the browser. For this little experiment, I started with SeaMonkey as the default browser, with the intent that it be used for normal browsing. Internet Explorer would be set to be the browser for secure sites. CAVEAT: (It's a big one) As far as I can tell, this is only going to work if you launch the site from an Explorer window, such as the Desktop or a folder. It will not affect URLs entered in to the address bar, as this is an excercise in controlling Windows file type associations. On the other hand, if you launch internet shortcuts from folders or the desktop, they will have different icons. In this case https links have the IE icon, everything else has the SeaMonkey icon (even Gopher (yay!)). Set normal use=SeaMonkey (1.1.11): Edit > Preferences > Advanced > System > Un-tick https > OK (I also checked the box: Alert me if other apps change these settings.) Set secure connection=Explorer Window (Win XP): Tools > Folder Options > File Types > Look for file type : (NONE) URL: HyperText Transfer Protocol with Privacy Highlight this type and click Advanced > Highlight the Open command > Edit > Browse > find Internet Explorer and select it (most likely C:\Program Files\Internet Explorer\IEXPLORE.EXE) > Click Open > OK > *OK > Close * If you want to set the icon: Click Change Icon, navigate once more to Iexplore.exe, and select the icon of your preference. OK > OK > Close. I have no idea how to go about creating policies which would limit the actions available to the browsers,assuming such is possible. I'd give this an overall Fail, just like my first attempt to post this. Whereas I had the instructions bit saved in a text file, most of my other comments have disappeared, and for the most part, elude me.

Michael Kassner
Michael Kassner

Also stay tuned there are going to be more articles explaining SSL certificates and what we as users need to know about them.

scarville
scarville

True but I trust the security of Cotse or my own firewall more than I do 99% of the hotels I've stayed in. I'm not trying to minimize this, just throwing out some defenses users can try. A friend of mine likes to point out that when the guano hits the turbine a .22 pocket rocket in hand is better than a tricked out .45 at home in the safe.

Michael Kassner
Michael Kassner

After thinking about this for a bit, wouldn't the redirect fall apart at the VPN log on?

d_g_l_s
d_g_l_s

No, SSL VPNs work off of a secure key requirement. But I can see where there might be a chink in the armor so to speak. It would be advisable to work with due caution.

sandro
sandro

Tunneling through SSH / VPN is just shifting the problem else where. The good thing about this is that else where might be more secure than your current physical network ;-) So I find SSH great in certain situations like Hotel WiFi etc

Michael Kassner
Michael Kassner

The real problem is that everyone has to surface at an Internet perimeter sometime. That's the weak link as I see it, because surf jacking and any other malware injection can then take place at that point.

scarville
scarville

"Wouldn't this exploit work virtually regardless of the level of security on the laptop?" Depends. IF your IPSEC VPN is configured to send corporate traffic thru the VPN but everything else thru the local LAN (most are these days) then it may be possible to hijack your IPSEC connection if you access it via Citrix. May have to give that some thought... I generally use ssh and port forwarding to a proxy server for web surfing on the road. Still not perfect but it protects me from unsecured local wireless and clueless administrators. You all might be surprised at the number of hotels I've stayed in where the WAP and/or router still have the default password.

pgit
pgit

always use a separate browser for https. IE for normal browsing, Opera for https, for instance. This sounds like something you all with "policies" should be jumping on asap, two browsers with dedicated purposes.

Michael Kassner
Michael Kassner

I completely forgot about SSL VPNs. I'm not even remotely smart enough to know if they are in the same boat. I'd suspect so, as I was under the impression that they work off of session cookies. That would be really huge. As for using an IPsec VPN, that does make sense, except that you have to exit to the Internet at some point. The attacker could be sniffing the traffic at that point. Unless you totally ruled anything other than point to point connections. I'm glad that this attack requires the user to have both an HTTPS and HTTP session open , other-wise it might get a bit scary.