Microsoft defense that fetched $50,000 prize bypassed in just 2 weeks
Technique comes at price, since it increases the cost of Windows exploits.
Dan Goodin - Aug 8, 2012 8:52 pm UTC
A computer's Internet Explorer screen just prior to it being exploited by an attack that bypasses new protection baked into EMET. Real-world attacks would conceal this behind-the-scene view.
Two weeks after Microsoft released a free utility designed to help its software better withstand a powerful hacking technique, a security researcher has demonstrated an exploit that bypasses the newfangled protection.
Microsoft released a new version of its Enhanced Mitigation Experience Tool on July 24 to great fanfare. The update to EMET, which adds an extra layer of defense to prevent vulnerabilities from being successfully exploited, introduced protections designed to block an advanced attack technique known as return oriented programming. A regular staple in exploits at the annual Pwn2Own hacker contest, ROP works by rearranging benign pieces of code already present in memory to form a malicious payload. The new protection, known as ROPGuard and developed by University of Zagreb researcher Ivan Fratric, fetched a $50,000 prize under a security contest Microsoft sponsored.
On Thursday, a security researcher whose Twitter profile claims he's based in Iran said he had bypassed the ROPGuard protections. A video demonstration accompanying his blog post showed a Windows 7 machine falling prey to a ROP-induced exploit even though the OS was running version 3.5 of EMET. The anti-ROP mitigations work by wrapping certain important system functions with extra code to verify that they're not being called by attack code. Based on a brief technical description, the attack circumvents this protection by calling the system function directly, thereby bypassing the protective wrapper.
The technique is one that attackers have been using for a few years to bypass protections known as data execution prevention and address space layout randomization, which Microsoft introduced with Windows Vista. Using the system call known as NtProtectVirtualMemory, the researcher was able to circumvent the anti-ROP mitigations as well.
The technique, however, comes at a significant cost to those writing software exploits. Namely, system call numbers change from version to version of Windows, requiring a different exploit for each one (although the syscall variation is much more pronounced in 32-bit releases than 64-bit releases). Considering the six-figure price for reliable attacks that exploit unknown vulnerabilities in Windows, the reduced number of machines that any one exploit can commandeer may be enough to discourage criminal hackers from bothering.
"The $250,000 prize [there were two other prizes awarded] is likely a low cost for Microsoft when they take into account the full cost of a reliable exploit in the wild," HD Moore, an expert in software exploitation and CSO of Rapid7, told Ars. "If EMET stops a single widespread attack from occurring, it would pay for itself back in multiples."
Yunsun Wee, director, Microsoft Trustworthy Computing, made much the same point in a statement released to Ars. "The security mitigation technologies implemented by EMET increase the cost for attackers to develop a successful exploit," she wrote.
Fratric's ROPGuard contribution took second place in Microsoft's "Bluehat" contest, which awarded $260,000 worth of prizes for security mitigations. All three of the winning entries focused on ways to reduce the effectiveness of ROP attacks.
The episode is a graphic example of the active and protracted arms race carried out by software exploiters and those hired to repel them. The discovery of a new attack technique may give hackers the upper hand for a brief period of time, until developers figure out a way to blunt it. To do this, the developers come up with defenses like security sandboxes and the aforementioned ASLR and DEP. Then attackers develop new weapons such as heap spraying to get around them. ROP, in fact, is a technique for bypassing DEP, which prevents data loaded into memory from being executed.
Stay tuned. This story isn't over yet.
Dilbert | Ars Legatus Legionis
Hacking is akin to asymmetrical warfare.
Hacker only needs to get lucky once. Software vendor needs to get lucky every time.
It only takes one competent hacker. Software vendor's people must all be competent. Just one inept one could lead to a security breach.
Hacker can make as many mistakes as they want. They just need to do it correctly once. Software vendor can't make any mistakes, ever.
It ought to be obvious even to a child that hacker will win for any foreseeable future. So plan your computing adventures accordingly.
Janeazy | Smack-Fu Master, in training
Dilbert wrote:
It's like protecting a city with a wall- the defender needs to make sure the wall is strong everywhere. The attacker only needs to find that weak spot.
There'll be lots of money, and lots of risk floating back and forth in the security sector in the coming years, and there'll probably many more seriously destructive hacks coming down the line as well
potato44819 Ars Legatus Legionis
Dan, I really like articles like these. Keep it up.
27936 posts | registered Dec 1, 2004
Janeazy Ars Centurion
aggressiva Ars Scholae Palatinae
How is SHARED_USER_DATA's address not randomized? Is this something that would be fixed/mitigated by ForceASLR (Win 8, update to Win 7), or possibly High Entropy ASLR (Win 8)?
And I disagree with Dilbert and Janeazy, the whole point of DEP, ASLR, Sandboxing, is to prevent a hack if the software has flaws. Granted, so far these techniques haven't been fool proof, but as they expand and get fortified (ForceASLR, HEASLR, AppContainer Sandbox, for example), it will be harder and more expensive to write exploits, and vendors will have less grief when they do make inevitable mistakes. Only time will tell if eventually this stuff gets to the point where attacking the software becomes unprofitable, and dare I say it, maybe even one day impossible.
Last edited by aggressiva on Wed Aug 08, 2012 4:34 pm
Dargaza Seniorius Lurkius
Chances are that some more exploits will pop up in near future, seeing the pace at which the current one has been released.
DrPizza Account Banned
aggressiva wrote:
I find it a little surprising. No user code should ever depend on its fixed address, so you'd think its location could be randomized easily enough.
93870 posts | registered May 10, 1999
Solidstate89 Ars Tribunus Angusticlavius
Thanks for the heads up. I didn't realize EMET 3.5 had been released as I'd been running 3.0. Will update my machines in the next few days. Still, that's pretty impressive that it was able to bypass all of those mitigation techniques.
DrPizza wrote:
So "Force ASLR" doesn't actually..force ASLR then? The most frustrating part is that these flaws seem easily preventable, how hard is it to make sure everything in your code has a randomized address, checking this should be an automated process, with mandatory compliance.
armandh2 Ars Scholae Palatinae
'Stay tuned. This story isn't over yet".
[if ever]
wobbleworks Wise, Aged Ars Veteran
It seems to me that changing processor architectures so that there are two stacks, one for code and one for data, would help. Without the ability to affect the code stack at all these sort of attacks seem impossible. Am I just being naiive?
I may be wrong, but I think Force ASLR just forces all libraries to be randomized; I didn't think it randomized other structures too.
Yea, that's what I thought too, I just (being unfamiliar with terms like SHARED_USER_DATA) assumed this was a struct in some unrandomized library.
flash__ Ars Centurion
I agree with you in a sense... but this doesn't tell the whole story.
If you're focusing on just compromising a target, yeah, hacker's only need to get lucky once (or perhaps a few times) and can make mistakes. However, if you widen the focus to include the counter-attack (such as, say, an FBI investigation into the hack), things get a bit more symmetric. The hacker now cannot afford to make mistakes. If he has linked his identity in any way- even indirectly- to the hack, he's likely to get arrested. I believe one of the LulzSec members was found mainly due to the fact that he failed- once- to mask his IP on an IRC server. It's easy to see, from this perspective, that hacker's can't always afford to make mistakes, and they might need more than a little luck.
It comes down to how you define "win." You say that hackers will "win" for the foreseeable future, but it's a lot harder to perform a major hack and GET AWAY than it is to just perform the hack.
MarkMS Ars Scholae Palatinae
The technique, however, comes at a significant cost to those writing software exploits. Namely, system call numbers change from version to version of Windows, requiring a different exploit for each one (although the syscall variation is much more pronounced in 32-bit releases than 64-bit releases).
I'm a newb here with this kind of stuff, but I like to learn about security. Can anyone explain the higher costs for me? From what I've gathered, exploit used system call NtProtectVirtualMemory to bypass ASLR and other protections like it. But the system call changes from version to version of Windows, so why would this cost more to exploiters? Can't they just buy all the different versions of Windows to get the system call numbers? Or is everyone's version of Windows different when it's installed?
Last edited by MarkMS on Wed Aug 08, 2012 5:28 pm
645 posts | registered Jul 9, 2007
It was, and I believe still is, a piece of kernel memory that's mapped into user space.
SealedSun Seniorius Lurkius
wobbleworks wrote:
I don't think that we would have to change processor (architectures/instructions sets) for that, but calling conventions used by compilers.
It sounds like a relatively simple, yet effective idea. This must have been tried before.
chris__ Seniorius Lurkius
SealedSun wrote:
Isn't that Data Execution Prevention? https://en.wikipedia.org/wiki/Data_Execution_Prevention
Making it mandatory breaks Just-in-time compilers.
29 posts | registered Sep 1, 2011
Itanium is a dual stack architecture.
chris__ wrote:
I think DEP prevents the scenario where the attacker stores malicious code somewhere in the "data" region of memory (the read-write memory pages) and then issues a function call to that code. As far as I understand return-oriented-programming (horrible term, but I can't come up with a better one), the attacker basically doesn't provide their own code but instead changes the return address of the current stack frame to enter existing functions (parts of the application or the operating system).
Now, if we could isolate the program control structures (return address, saved registers) from the working memory (local variables, probably also parameters), ROP should be more difficult/impossible in that form.
dangoodin Ars Scholae Palatinae et Subscriptor
Major General Thanatos wrote:
Thanks for the kind words, Major General. They mean a lot to me.
argamond Ars Scholae Palatinae
According to your article, $50k is the runner-up prize. From the title, people (at least I did) would have assumed it was THE prize (number 1)
Still security is a fuzzy game with no absolutes. Anything that makes it harder for an attacker to gain control of a large number of computers is always a win
MarkMS wrote:
It increases the cost in that a hacker will need three separate attacks to successfully exploit Vista, 7, and 8 users. Without EMET, a single attack would work on all three platforms. The "network effects" and "critical mass" of a given operating system aren't important only to developers of legitimate software. Criminal hackers care about them, too.
igor.levicki Ars Scholae Palatinae
Slow news day eh?
This is not a new technique, it is used for ages and it was always like that.
Have people tried attacking Itanium using methods like this? Do they work? Or are there entirely different but equally effective ways to attack Itanium systems?
Have people tried attacking Itanium using methods like this?
Well, first you have to find someone running an Itanium system.
Leo Davidson Smack-Fu Master, in training
EMET 3.0 seems next to useless to me.
I set it to the max settings for most of my common processes, especially ones that touch the network.
The EMET notifier often puts up a message in the bottom right saying a process has done something wrong and will be terminated, but the process ALWAYS carries on regardless. The same on both machines I have installed it on. (One Windows 7 x86 logged in as standard user; the other x64 as administrator, both with UAC enabled.)
I have seen it put up an error dialog many times but have not once seen it close anything. Does it actually work!?
I could already force DEP on for things, and have done for years, so that's not giving me much AFAIK. It has let me force on some other security measures, which is good, but the fact it does what I just described has made me lose all faith in it and start to wonder if it is snake oil. TBH, I don't think I would bother installing it again.
Once EMET 3.5 is properly out (not just a "tech preview") I might upgrade to that and see if it's any better, but if it still appears to be useless I think I'll just get rid of it. It doesn't seem to be worth the extra process cluttering up Task Manager.
(I assume when EMET 3.5 is properly released either EMET or Windows Update will notify me. If not then I've lost even more faith in it, as a security tool that doesn't detect updates -- and EMET hasn't done so once so far -- can't be very well thought out.)
Leo Davidson wrote:
That is what Secunia PSI is for.
Quitch Ars Praefectus
Secunia PSI only detects updates which correct vulnerabilities in the previous software. It would not detect EMET 3.5 since, AFAIK, there are no vulnerabilities within EMET itself.
Decker-Mage Ars Centurion
flash__ wrote:
Thank you, that was going to be my point as well. A regular feature in the security biz is when, how, and by how much, should you engage in counter-attacks when you discover you are a victim of a hack. [Of course, there are questions about the very legality of such counter-attacks as well.] With a good forensic capability in-house, and the right log-level documentation, you should at least be able to put the hounds on the right scent.
249 posts | registered Aug 5, 2009
EMET User Guide wrote:
In Process Explorer, the ASLR column for a process is blank even though EMET is configured for use with that application.
EMET does not take advantage of the OS implementation of ASLR. It will not show up in Process Explorer even when it is turned on because Process Explorer only queries the OS implementation of ASLR.
Why does EMET use its own ASLR implementation rather than the OS one?
Stubabe Ars Scholae Palatinae
Quitch wrote:
Because it is in addition to the OS level one. The Windows Vista/7 ASLR works in opt-in mode (by default) where only .exes and .dlls that are marked ASLR compatible are randomised. EMET randomises dlls that are not so marked by hooking the dll loading process and pre-allocating memory at the default load position before the incompatible .dll loads. This forces the OS to put it somewhere else and is usually safe (dlls are loaded after the image so cannot guarantee their load address is available).
The other option is to set the MoveImages registry key to 0xFFFFFFFF which forces any reloadable sections to be randomised by the built in ASLR. However, even here the code must have relocation fix-up tables in the image (true of all dlls but not common for non-ASLR .exes) otherwise it would immediately crash on load i.e. instructions like JMP 0x12345678 must be altered at load time to the new address by the loader. EMET can't do anything about this either for the same reason.
Note this is a less of an issue for x86-64bit code as unlike x86 there is now instruction set level support for relocatable code (instruction pointer relative addressing) whereas there was a not insignificant runtime overhead for relocatable code techniques on x86. This is why Windows opted for load time fix-up tables instead. Of course programmers still need to set the ASLR image flag but this is on by default in visual studio for new 64bit projects.
Boneman69 Ars Praetorian
And I disagree with Dilbert and Janeazy, the whole point of DEP, ASLR, Sandboxing, is to prevent a hack if the software has flaws.
So, are DEP, ASLR and Sandboxing hardware solutions or software? Are they written by Hackers or Software Vendors.
I think you made Dilbert and Janeasy's point, even though you disagree with it.