A good update at Threatpost:
Their new exploit beat a fully patched Windows system running IE 8, the same version of the browser exploited by malware used in watering hole attacks against a number of political and manufacturing websites, including the Council on Foreign Relations in the U.S., and Chinese human rights site Uygur Haber Ajanski.
More motivation to move to updated browsers, as difficult as that often is. I’m really hoping IE 10 can break this cycle a bit (and I bet Microsoft is as well). Still, IE 8 is only a bit over 3 years old, which isn’t all that ancient compared to XP.
If you are stuck on old browsers, and have the capability, take a serious look at EMET. Kills most of these attacks cold.
Posted at Friday 4th January 2013 1:39 pm
(0) Comments •
In today’s news we see yet another zero-day Internet Explorer exploit being used in the wild.
And once again, soon after becoming public, an exploit was added to Metasploit. Well, sort of. While the in-the-wild attack only works against Windows XP, the Metasploit version works against Windows 7 and Vista. (Note that IE 10 isn’t affected).
You can read the article linked above for the details, but this gets to something I have been recommending privately for a while: support 2 browsers, even if one is only for emergencies.
First of all, ideally you’ll be on a modern operating system. I’m not one to blame the victim, but allowing XP is a real problem – which I know many of you fight every day. Second, this advice doesn’t help with all browser-based attacks, especially Java. But you can configure it in a way that helps.
- Choose a secondary browser that is allowed for web browsing. Chrome is most secure right now, but make sure you set its privacy defaults to not bleed info out to Google.
- Ideally block Java in the browser. Maybe even Flash, depending on how you feel about the Chrome sandbox.
- If something like this IE flaw hits, notify users to use the secondary browser for outside websites (odds are you need IE for internal web apps programmed by idiots or 19th-century transplants, and so cannot ban it completely).
- If you can, set a network policy that (temporarily) blocks IE from accessing external sites (again, you can make exemptions for partners). Unfortunately I don’t believe many tools support this.
I know this advice isn’t perfect. And there are tools like Invincea and (soon) Bromium that can likely stop this stuff cold in the browser – as well as a few network tools, although history shows signature-based defenses aren’t all that effective here. But if you can pull it off you aren’t stuck waiting for a patch or another workaround. Especially if you go with the “block Java / isolate or block Flash” option. This approach allows you to still only support one browser for your applications, and use a secondary one when needed without users having to violate policy to install it themselves.
Posted at Tuesday 18th September 2012 2:27 pm
(2) Comments •
While Microsoft releases patches for various vulnerabilities, including the two active zero day attacks, Firefox is being actively exploited.
Not that we plan to post every time some piece of software is exploited or patched, but this series seems to… bring some balance to the Force.
Posted at Tuesday 14th July 2009 12:09 pm
(1) Comments •
There is an unpatched vulnerability for Internet Explorer 7 being actively exploited in the wild. The details are public, so any bad guy can take advantage of this. It’s a heap overflow in the XML parser, for you geeks out there. It affects all current versions of Windows.
Microsoft issued an advisory with workarounds that prevent exploitation:
- Set Internet and Local intranet security zone settings to “High” to prompt before running ActiveX Controls and Active Scripting in these zones.
- Configure Internet Explorer to prompt before running Active Scripting or to disable Active Scripting in the Internet and Local intranet security zone.
- Enable DEP for Internet Explorer 7.
- Use ACL to disable OLEDB32.DLL.
- Unregister OLEDB32.DLL.
- Disable Data Binding support in Internet Explorer 8.
Posted at Friday 12th December 2008 11:16 am
(2) Comments •
Looks like the cat is out of the bag. Someone managed to figure out the details of clickjacking and released a proof of concept against Flash. With the information out in public, Jeremiah and Robert are free to discuss it.
I highly recommend you read Robert’s post, and I won’t try and replicate the content. Rather, I’d like to add a little analysis. As I’ll spell out later, this is a serious browser flaw (phishers will have a field day), but in the big picture of risk it’s only moderate.
- Clickjacking allows someone to place an invisible link/button below your mouse as you browse a regular page. You think you’re clicking on a regular link, but really you are clicking someplace the attacker controls that’s hidden from you. Why is this important? Because it allows the attacker to force you to interact with something without your knowledge on a page other than the one you’ve been looking at. For example, they can hide a Flash application that follows your mouse around, and when you go to click a link it starts recording audio off your microphone. We have protections in browsers to prevent someone from automatically initiating certain actions. Also, many websites rely on you manually pressing buttons for actions like transferring large sums of money out of your bank account.
- There are two sides to look at this exploitation- user and website owner. As a user, if you visit a malicious site (either a bad guy site, or a regular site that’s been hit with cross site scripting), the attacker can force you to take a very large range of actions. Anytime you click something, the attacker can redirect that click to the destination of their choice in the context of you as a user. That’s the important part here- it’s like cross site request forgery (really, an enhancement of it) that not only gets you to click, but to execute actions as yourself. That’s why they can get you to approve Flash applications you might not normally allow, or to perform actions on other sites in the background. As with CSRF, if you are logged in someplace the attacker can now do whatever the heck they want as long as they know the XY coordinates of what they want you to click.
- As a website owner, clickjacking destroys yet more browser trust. When designing web applications (which used to be my job) we often rely on site elements that require manual mouse clicks to submit forms and such. As Robert (Rsnake) explains in his post, with clickjacking an attacker can circumvent nonces (a random code added to every form so the website knows you clicked submit from that page, and didn’t just try to submit the form without visiting the page, a common attack technique).
- Clickjacking can be used to do a lot of different things- launching Flash or CSRF are only the tip of the iceberg.
- It relies heavily on iFrames, which are so pervasive we can’t just rip them out. Sure, I turn them off in my browser, but the economics prevent us from doing that on a wide scale (especially since all the advertisers- e.g. Google/Yahoo/MS, will likely fight it).
After spending some time talking with Robert about it, I’d rate clickjacking as a serious web browser issue (it isn’t quite a traditional vulnerability), but only a moderate risk overall. It will be especially useful for phishers who draw unsuspecting users to their sites, or when they XSS a trusted site (which seems to be happening WAY too often).
Here’s how to reduce your risk as a user:
- Use Firefox/NoScript and check the setting to restrict iFrames.
- Don’t stay logged in to sensitive sites if you are browsing around (e.g., your bank, Amazon, etc.). Use something like 1Password or RoboForm to make your life easier when you have to enter passwords.
- Use different browsers for different things, as I wrote about here. At a minimum, dedicate one browser just for your bank.
As a website operator, you can also reduce risks:
- Use iFrame busting code as much as possible (yes, that’s a tall order).
- For major transactions, require user interaction other than a click. For example, my bank always requires a PIN no matter what. An attacker may control my click, but can’t force that PIN entry.
- Mangle/generate URLs. If the URL varies per transaction, the attacker won’t necessarily be able to force a click on that page.
Robert lays it out:
From an attacker”s perspective the most important thing is that a) they know where to click and b) they know the URL of the page they want you to click, in the case of cross domain access. So if either one of these two requirements aren”t met, the attack falls down. Frame busting code is the best defense if you run web-servers, if it works (and in our tests it doesn’t always work). I should note some people have mentioned security=restricted as a way to break frame busting code, and that is true, although it also fails to send cookies, which might break any significant attacks against most sites that check credentials.
Robert and Jeremiah have been very clear that this is bad, but not world-ending. They never meant for it to get so hyped, but Adobe’s last-minute request to not release caught them off guard. I spent some time talking with Robert about this in private and kept feeling like I was falling down the rabbit hole- every time I tried to think of an easy fix, there was another problem or potential consequence, in large part because we rely on the same mechanisms as clickjacking for normal website usability.
Posted at Tuesday 7th October 2008 10:12 pm
(0) Comments •