MS DEP gets dipped

Check this out:

-http://arstechnica.com/security/2012/08/microsoft-defense-bypassed-in-2-weeks/

Blackhats ride again.

SourMilk out

 

Smart program by Microsoft.

 

Exploited a program that suppose to help prevent exploits in programs.

 

This has absolutely nothing to do with DEP (@SourMilk) or exploiting EMET (@Dark Shadow). This is about bypassing the new ROP protections in the EMET beta, something Microsoft said would happen in it's blog when it released the beta version...

This is the most critical part:

Please note from the original MS EMET beta blog:

Now note from the article:

All-in-all good read, but not surprising at all as MS already said this would happen.

 

I viewed the youtube link in an effort to more or less see how it works with my very limited knowledge on this stuff. It appears a malicious .htm file opens calc.exe via iexplore.exe? If calc.exe is the hypothetical payload, doesn't said payload first have to write to the target directory, then of course be allowed to execute? It seems a whitelist approach might stop this? Maybe I've misinterpreted the way it works. I'd be interested in knowing.

 

ROP spraying can do this:

"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." (last sentence of the article)

Besides, I like the thread title

SourMilk out

 

Yes, that's the definition of ROP attacks that have been bypassing DEP for years. This article is about bypassing the anti-ROP protection, nothing to do with DEP. Also DEP doesn't belong to MS, so it's not "MS DEP".
https://en.wikipedia.org/wiki/Data_Execution_Prevention

 

Okay. I yield . I could have sworn a software DEP was only on my MS OS's and not my other OS's. Unless you count the nx bit on the cpu which I doubt would be a consideration on browser heaps. Oh well, com se com sa.

SourMilk out

 

Where do I find DEP?
I'm using Windows 7 64bit

Thanks

 

DEP is built in. Applications, by default, have to opt in to use it. Using a tool such as EMET you can change the DEP policy of your system.

Elapsed is correct - this is about bypassing the Anti-ROP techniques. This has been known for a while. I pointed out in a blog post when they were released (the techniques, before EMET 3.5) that an attacker only has to use different instructions to maintain full control flow of a program. There are probably other ways to bypass it. The combination of the techniques is really strong though and these, along with ASLR, make things really difficult.

 

Elapsed's reply explains it all. On top of that ROP mitigation is intended for sloppy programming storing return addresses in such a manner it can be easily exploited. Big (inflated) tittle combined with little (hollow) text in article IMO

The chance that a sloppy/lazy programmer would use direct direct calls is (near) zero. Simply because he/she would have to make them specific for a Windows version, which would contradict with his sloppy/lazy programming skills (simply because it is to much work making OS specific versions in stead of one for all Windows OS-ses).

As Hungryman points out is the combination of mitigation techniques make it harder and harder to exploit weaknesses in programming code. Some weaknesses are by design (e.g. speed), but most are by human error. With the ever increasing power of CPU's and GPU's the need for code optimisation reduces likewise the performance punishment of EMET like mitigations is also reducing. The trend will be that mitigations become stronger (e.g. EMET) and the software designs are become better and better (e.g. PPAPI as opposed to NPAPI plug-ins in Chrome) and the code platforms themselves evolve (e.g. HTML5)

The near future is bright it will be a lot harder to exploit software, also the hackers have to be a lot smarter (increasing the chance they will become white hat hackers in stead of black hat hackers). The far future looks even more promising

This old man has deserved this optimistic opinion: turned from a 'smart' (lazy) programmer preferring sloppy testing into a structured designer disliking smart programming and sloppy testing, changed to a salesmen selling software, hating smart programming and sloppy testing because of the customer recalls and problems it gave afterwards.

 

Whitelist do catch almost all payloads except for those rare(?) RAM attacks via VirtualAlloc().

 

Thanks trismegistos! Most of this is way above my grasp but it's nice to know the basics of how these might work in a real world attack. I'm not sure if that .htm link the author clicked on (in the youtube video) was what crashed IE (appeared to anyway) and I've no idea the logic behind calc.exe being launched via IE?? Fun stuff all the same

 

To be honest, I couldn't see much, and therefore understand, of what the video was displaying. I don't have superman vision.

Anyway, could you tell if IE's Protected Mode was enabled? Because, if the guy managed to plant calc.exe in the system, then it also bypassed Protected Mode... or was Protected Mode disabled? Hopefully, you saw it better than me. lol

 

I had to hit ctrl + several times to magnify the page, although it was a bit blurry but it did help some The calc.exe launched resided under c:\windows\system32 so it seems to be the legitimate file and not planted there by the author. I'm guessing protected mode was on. Is there a way to tell from from Process Explorer in the video? The integrity level column isn't showing. Interesting think I saw somewhere is that with Win Vista, if you view a local html page, protected mode disables temporarily because it considers the page to be trustworthy. Source: -http://blogs.msdn.com/b/ie/archive/2007/04/04/protected-mode-for-ie7-in-windows-vista-is-it-on-or-off.aspx

*EDIT*

never mind, it's on. The status bar shows it

 

The exploit code on that link did crash IE, although and I quote...

Real-world attacks would conceal this behind-the-scene view.
-http://arstechnica.com/security/2012/08/microsoft-defense-bypassed-in-2-weeks/

What's the logic behind launching calc.exe via IE?
IE is the targetted process in this case which has the vulnerability for the exploit to work. It could be another vulnerable process like unpatched, vulnerable or outdated office applications or pdf viewer. The remote process usually exploited in real world scenario is your internet facing application, the web browser or it's plugins(pdf or flash). A hacker can also trick the user to open a downloaded word document with embedded malware for eg as in the Duqu trojan via a once zero-day kernel exploit now already patched.

Why POC's launch calc.exe?
Some benign or test POC's will usually launch or execute a benign application like calc.exe or notepad.exe already present (not downloaded) from your machine, others will launch or run the command shell or cmd.exe and a few others will only display a message window as proof that the exploit code has theoretically and successfuly pawned your machine. From that benign POC with a shellcode that simply launches calc.exe, a hacker can simply replace it with another payload of his choice. And so real world 'malware' exploits will have their payload, the shellcode running in the process' memory, drop or download further another payload like RAT (remote access trojan) with rootkit functionality for e.g. then execute it. That's for the exploits with the plain 'download and execute' shellcode. A variation is the shellcode that downloads and loads a library. If it's staged, the shellcode will download into the process' memory a much bigger shellcode and then execute that. A payload like the Metasploit's meterpreter shell or the VNC shell can completely run from the exploited process' memory as a library(dll) without writing to disk and then when needed can migrate to another process' memory or for a few steps to elevate privileges and gained persistence to survive reboots. But the simple or 'old school' or classical shellcode will just return the regular command shell buit in to the operating system (cmd.exe for windows or the bourne shell or /bin/sh for linux) back to the remote attacker usually via the "standard TCP/IP socket connections to allow the attacker access to the shell on the target machine."

 

Thanks Trismegistos for the detailed and very informative explanation I had tried out the exploit he provides here in my vm, apparently of the actual exploit he wrote, but in both attempts trying to open it using IE9, I was warned of an activex download attempt, so I could easily deny them if I wanted. Even though I allowed them, I did not get the error he got, nor did IE crash. Nothing really seemed to happen other than I got a page with a bit of meaningless text, something about TAGS. EMET 3.5 is also installed on the vm guest.

Is it accurate to assume that a real payload could be stopped via whitelist/anti-executable restrictions?

 

Are you using a version of IE that is actually vulnerable to the exploit? He picked it at random - it's not some 0day. If you're not vulnerable it won't matter.

 

It's version 9, and I tested it on both the 386 and x64 IE's on a fully updated Win7x64 vm guest. I could see the author had protected mode on, so I guess he had to be using IE8 or 9? I'm not sure why he didn't get the activex warnings, unless he disabled some of the default security measures in IE. I've provided a couple screenshots, including the one when I allow the exploit to open a tab in IE.

 

Maybe the guy just wanted to point out that EMET's mitigation itself could be bypassed, so he just probably disabled some Internet Explorer security functionality? But, maybe he would have also disabled Protected Mode?

Too bad I'm not able to properly see the video due to the resolution; not to mention we don't really see how IE was configured.

 

If you did it on a fully updated system it naturally would not work as this CVE was probably patched long ago.

 

Yeah, it's impossible to tell how he prepared his system for the test.

I used "Ctrl +" in Chrome

True, we don't know how updated his system was. I see the test files are dated August 8, and of course he tests on the very recently released EMET 3.5.

 

We do know how up to date it is. It's not up to date. He exploits a known vulnerability that was already patched. I thought I'd linked the CVE above but I guess I forgot. I'll edit this post with it later.

The point is bypassing EMET.

edit: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1260

 

Okay thanks, I just found that CVE. I had missed it where the author provides the exploits.

 

Application Whitelisting: Panacea or Propaganda?
http://www.sans.org/reading_room/wh...ication-whitelisting-panacea-propaganda_33599