In any case, I did some presentations recently and thought I should probably put details up here.
I did a talk last November at Power of Community and XCon about the Same Origin Policy and some new ways of looking at it, where most of the new material was along the line of the GIFAR attacks Billy Rios came up with that Nate McFeters, etc, ended up presenting at BlackHat which took a lot of the wind out of my sails *shrug*, it should be interesting as it covers a lot of other things and points people in some uncommon directions, I've uploaded the paper I wrote and the slides here:
Slides
Paper
I also did a talk at RUXCON and 25c3 with Stefano Di Paola (and I even spelled his surname correctly this time! ^_^) called Attacking Rich Internet Applications, so here are some materials:
RUXCON Slides
25c3 Video Recordings
I never ended up releasing this while it worked since I didn't want to kill a bug, but if you look at the video or were at the presentation you may have seen me demonstrate an exploit for Tamper Data, the bug is almost identical to this one that I had claimed was exploitable. While my rationale in that post was incorrect (due to me testing with an old version of Tamper Data which was vulnerable in the way described), I came up with an interesting exploit for the bug in Firefox 3 which could have gained me code execution by editing about:config entries.
Here is the PoC exploit:
<?php
//This is just a PoC, have a look through about:config for any _string_ entry you would want to change
//This bug is kind of lame, but the exploit is cool, since it uses a Firefox bug to do damage (this should be unexploitable)
//Bug fires when a user graphs a malicious http request (open tamper data, graph the attack request)
header ("HTTP/1.1 200 OK<BR><B>Mime Type</B>: text/html\",event);' onMouseOut='hide_info();'><script>opener.oTamper.preferences.PREFERENCES_ROOT='';opener.oTamper.preferences.init();opener.oTamper.preferences.setString('app.update.url', 'jajaja');</script><g/='");
?>
The bug is triggerable on old Tamper Data versions where the Graph Requests functionality worked, and if you graphed the malicious request/response the exploit would set the app.update.url would be set to jajaja.
The bug works by abusing a lack of access control on any objects that extensions create in their windows (It wasn't just Tamper Data, it happened in other extensions), where it was possible to read and modify the objects, and more importantly: call their functions. When you called a function that an extension had created, it was executed in the context of the extension, namely chrome code.
It did not end up being necessary or useful for this exploits, however it was possible to call those functions and completely control all the data, etc, via calls such as opener.oTamper.whatever_function.apply(our_obj).
In any case, the access control bug died some time in the last few Firefox 3.0.X releases, but I'm not really sure which since the graphing functionality in Tamper Data hasn't been working for even longer, and it got to be too much effort to double check it.
I also did a presentation at the OWASP Australia Conference in February titled "Examining and Bypassing the IE8 XSS Filter", which might be some nice background for people, but will probably be greatly surpassed by sirdarckcat & thornmaker's upcoming Black Hat presentation. Here are the Slides.
I also did a presentation on Writing Better XSS Payloads at EUSecWest in May, however I haven't uploaded the slides since I'm trying to submit it to Hack In The Box Malaysia to have the material reach a wider audience, so unless it is rejected, you'll have to wait until then to see it... Or email me.
And that's all for now...
No comments:
Post a Comment