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 griefIn 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:
Using my Web browser, I log on to https://www.mybankxy.com.
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.
After the portal Web page opens, I click on a link for the Web page with my savings information.
My Web browser sends the Web page query and my session cookie back to the mybankxy.com web server.
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.
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 PermanentlyNow, 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 jackingFirst 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:
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.
Once again the mybankxy.com Web server authenticates me and places a small text file on my computer, called a session cookie.
I forgot the amount I needed, so I open a new browser window and go to http://www.commercexy.com.
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.
The attacker sends back a “301 Moved Permanently” in response to the Web page query I sent to www.commercexy.com.
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.
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.
Since the attacker is sniffing all my traffic via the open Wi-Fi hotspot, the session cookie is captured. Done deal.
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 partsThe 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 thoughtsSurf 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.
or is visible because I've highlighted the phrase Miami-Dade County. Clicking that indicator takes me to a menu where I can choose from any available action; in this example, I'm about to send the selection to Google Maps, which will open in a new browser tab.
a local weather report from Live Search. Clicking the associated link on the new Favorites bar displays the contents of that slice without having to load a full web page or even leave the current page.
range groups and set non-Microsoft controls as the default for particular actions, as I've done here with Google's Blogger and Google Maps tools.
that many sites coded for earlier IE versions will render improperly in the new browser. A compatibility button on the Address bar allows you to switch to compatibility mode for all pages on that domain. Unlike earlier betas, you don't have to restart the browser to switch compatibility mode on or off.
remarkably detailed console for examining, tweaking, and debugging source code, CSS style sheets, and script on any web page.
unsafe will be blocked in equally emphatic style.
used to power the new SmartScreen Filter and there is a chance that new third-party providers will be included. Google’s blacklist, which now powers the anti-malware blocker in Firefox 3, is not included.
Posts
