In the last talk of Day 1, Roberto Suggi Liverani and Scott Bell (not present during the presentation), security consultants at Security-Assessment.com, will share the results of some intensive browser bug hunting research, and will drop 5 0days.
Roberto starts by apologizing about the fact that Scott was not able to join him at the conference.
The agenda of the talk contains 3 major components:
Everybody uses browsers, Roberto states. Browsers have become predominant desktop applications and we see a clear shift towards client-side applications and attacks. It makes a lot of sense to take a look at the security of browsers.
This bug only works in Windows 7. Roberto mentions that it took the devs a long time to get fixed, indicating possible complexity involved with this bug. A slightly modified version of cross_Fuzz was used to find this bug.
To make cross_fuzz produce the crash, they basically added more entropy, randomizing call parameter count, removed google_gc() and changed some other things. To create a different HTML file every time, they implemented HTMLGen. They also removed some phases in cross_fuzz to make things faster.
After triggering the crash, they had to simplify the html page that caused the crash and remove unnecessary components. Using the JSLOG Firefox extension, they logged DOM operations, allowing them to observe browser behavior around the time of the crash. FInally, they had to trace the browser behavior in a debugger… which took a fair bit of time (months). In the end, they were able to pinpoint the exact code that causes the UAF condition.
In terms of exploitability, they discovered that there’s some kind of race condition involved, making timings particularly important to gain code execution. The proof of concept code demonstrated on stage doesn’t include DEP/ASLR bypass either (it just sprays and ends up jumping into the spray).
Roberto found a couple of bugs in Maxthon and first explains what a Cross Zone Scripting is and the fact that it offers and intrinsic Same Origin Policy bypass. If you have javascript running in a trusted zone (and each browser has a trusted zone), you can access the local system API’s. If you can do that, you can execute code, and it would be 100% reliable.
Maxthon, a chinese web browser, supports Trident and Webkit layout engines, and is used, according to Maxthon, by 130 million users. Roberto found 5 ways to get code execution in the Maxthon browser. In addition to the Trusted Zone issues (and the fact that they could inject code into the about:history page), they also discovered that i.maxthon.com appears to be a trusted domain, allowing access to privileged API’s. There’s no control on domain name to IP resolution, and no SSL either. MiTM anyone ? The latest version of the browser is still vulnerable to some of the bugs they found. To demonstrate code execution, he used a few lines of javascript that creates a .bat file, adds some commands into the file and then runs it.
Yet another Chinese browser fell apart during their research. Roberto drops 3 0day bugs during the talk (because the Avant devs didn’t respond to any of his reports). Avant is a custom web browser application, using IE (light version) or IE/FF/Chrome (Ultimate) in the background. With 26 million downloads, the app seems to be used by a lot of people. Some of the files in the res folder are rendered in special pages, allowing for the execution of a privileged function (ARFunCommand()). They fuzzed the methods from this undocumented function and found some interesting results, returning information from the browser and browsing sessions. Using the 60003 value found during the fuzzing, they managed to perform a SOP bypass and XCS.
Roberto discovered that the nslScriptableUnescapeHTML.parseFragment() function, which is used to filter and sanitize data. Instead of using <script> (which gets removed by that function), he used javascript:alert(window). When the user clicks the scripts, it gets executed in the Chrome zone, allowing you to run privileged commands (such as downloading a file and running it).
Labeled as low severity by Opera, because Roberto couldn’t give them a proof of concept exploit. (???) It was recognized as a memory corruption bug, but not classified as a security issue. At the same time, Opera mentioned that, if Roberto would deliver an exploit, they might revisit their position. The researchers used their own custom fuzzer to find this bug.
Ancient bug, reported in 2005 by M. Krax. If the user is lured into bookmarking a malicious javascript: URI + payload and the user clicks on it, it might lead to a universal XSS (when used in a standard web page), or a XCS (when used in a privileged browser zone). Roberto explains that there are many ways to fool a user. You can spoof URL and status bar. Javascript can be compressed. You can even hide code (@Agarri_FR found a bug in Opera, where you could use a null byte to hide code from the source view). Of course, this type of exploit requires a couple of requirements or conditions to be met, but it works painfully well.
The problem is even worse in Firefox, because you can’t really see the javascript code from the “Add Bookmark” window. This issue has been fixed in Firefox 11.
This concludes my first day at Hack In The Box 2012 Amsterdam. Stay tuned for more posts tomorrow!
Tags:
© Corelan Consulting BV. All rights reserved. The contents of this page may not be reproduced, redistributed, or republished, in whole or in part, for commercial or non-commercial purposes without prior written permission. See the Terms of Use and Privacy Policy for details.
