May 16, 2008
Browser Exploits - Attacks and Defense
|
Saumil Shah examined the fundamental architecture of a few browsers and their components to get a proper understanding of the full attack surface. If you care about the attack surface of your web browser, and you should since you're using one right now, then check out what Saumil has to say. |
Sean Comeau: You're speaking at EUSecWest about browser exploits. Which browsers have you been researching?
Saumil Shah: My major focus has been on Firefox 2.x and Internet Explorer 7. I would say I have divided my time equally between the two. I wish I had more time to devote to Safari.
Firefox and IE have both gone through a lot of tempering over the years. Most of the obvious bugs are gone. Safari is gaining popularity and I am certain there are a lot of new bugs that shall be discovered over the next two years.
Sean Comeau: Can you describe the most common technique attackers are using today?
Saumil Shah: The attack scenario has shifted from the server side to the client side. Most of today's desktop OSes exhibit a high level of security, with host based firewalls built in, to protect its components. The easiest way into a user's desktop therefore lies via the browser.
There are two aspects to browser attacks. The first, via injected content, such as XSS or CSRF. The attack is carried out on the data loaded in the browser's DOM or simply stating, HTML and Javascript. The target of this attack is the user data stored on the sites that the user is currently navigating to, be it the user's social networking profile, or web based email, or internet banking account.
The second and more deadly form of attack is that on the browser and its components. The goal here is total compromise of the browser process and getting an entry into the operating system innards through the browser. Attacks are launched against browser components and plugins, delivered via cleverly written HTML and Javascript. If any of the browser's internal components, or its plugins, are vulnerable, then these attacks result in almost total system ownership. My talk focuses on this latter subject.
The modus operandi of the next generation of browser attacks is to throw out a large net exploiting popular 0-day vulnerabilities against browsers and their components. What was once mass-defacement has now resulted into mass-iframe malware delivery mechaisms. Web servers hacked en-masse have their front pages loaded up with HTML and Javascript tucked away into tiny IFRAMES which are invisible to the users. When a user browses such a modified page, the scripts try out a dozen popular 0-day exploits against the browser. Even if one of them succeeds, the user is owned. Probability theory dictactes that this scheme will always succeed. Someone or the other is going to walk into this trap.
The vulnerabilities are also special in the sense that they can be dynamically modified and delivered, resulting in the fact that no two vulnerable payloads will be the same. Thanks to the fact that all browsers have a Javascript engine built in, an attacker can craft a vulnerability that builds up the entire payload within the user's browser itself, and then drops it right onto the browser's foot.
Sean Comeau: What are the current defense mechanisms?
Saumil Shah: Prayer. Pray that any 0-day vulnerabilities discovered in browsers gets fixed fast before the mass-malware-delivery-nets start using them. I would also like to underscore the fact that here, Security-by- obscurity may emerge as the winner in holding up the fort.
Good browsing habits also make a difference. For example, all my sensitive transactions such as internet banking are carried out using a different browser than my regular browser. When I am logged on to my bank, I don't have any other browser open. Of course, I do hope that I haven't been rootkitted already!
Surprised that I didn't mention the ever-popular-AntiVirus solution? Feel free to heckle me in my talk about this! I personally have lost all faith in AV.
Sean Comeau: What does the next generation of Javascript delivered exploits look like?
Saumil Shah: The current exploit payloads are well obfuscated with real clever JS obfuscation. There are 2-3 layers of scripts resulting in more scripts resulting in even further scripts. So far, I haven't seen crypto based obfuscation, but I predict that scene isn't far away. It would be easy to deliver an on-the-fly encrypted JS package and the key using an XHR call or through some other means.
Javascript is so powerful it allows for extremely clever (read non- detectable) methods of payload delivery.
Sean Comeau: How does this render current defense mechanisms useless?
Saumil Shah: Current defense mechanisms still use the signature game. Today's exploit vectors can easily render most signature scanning useless. Attack payloads, if delivered over SSL can sneak in completely undetected too.
Sean Comeau: What new defense mechanisms are being proposed?
Saumil Shah: With the whole Web 2.0/Facebook/Twitter/Myspace/RIA/insert-the-next- slick-but-non-productive-technology-here force driving the direction of HTML and Javascript, the focus given is mostly on functionality without realising the impact on security. IE8 is already making provisions for deliberately bypassing the same-origin-policy for making cross domain applications work. Firefox 3 is no saint either. And Safari shall soon be put into the hotseat where IE5 was a few years ago. Just because it is Apple isn't going to make it win the security game. Such trends and directions raise the bar in implementing a good in-browser protection mechanism. Javascript being able to modify the DOM and itself doesn't help the cause either, and it is being enhanced with more functionality.
Until the browser makers and the standards' bodies come to a conclusion about browser level security, everything else will be a patch or a workaround. Remember the IE zones and ActiveX signing days?
With regards to new defense mechanisms, there are a few trains of thought here. What I am working on is an in-brower solution. Traditional Antivirus software is effective only if parts of it are implemented as a kernel driver, which hooks in at lower levels of the OS. Similarly new mechanisms have to hook in, or be a part of the browser's core itself. Events have to be intercepted at the DOM layer, when they are being rendered, in order for malicious attacks to be stopped.
Sean Comeau: How does this attack the very principles that browser exploits depend on?
Saumil Shah: It is 4:45 am. I do need to leave some details for the benefit of the audience :)
Sean Comeau: Ok, I'm looking forward to hearing that.
