New IE zero day vulnerability

http://www.fireeye.com/blog/technical/2013/11/new-ie-zero-day-found-in-watering-hole-attack.html

 

Exploits of critical Microsoft zero day more widespread than thought
At least two hacker gangs exploit TIFF vulnerability to hijack users' computers
http://arstechnica.com/security/201...rosoft-zero-day-more-widespread-than-thought/

 

Sounds like this would bypass quite a lot of security software.

 

Somewhat ironic given that I posted in the forum throughout the day about the dangers of drive-bys

 

Yes another Vulnerability in a Microsoft Graphics Component !

If you have rundll32.exe set to Block/Prompt it can't get even to the second stage, so you would be safe, as i am

 

The exploit launches it from the injected shellcode. Do you think PG or other 3rd party anti-exec still going to block it under this circumstance?

 

Depends on what system calls Process Guard hooks. If it hooks CreateProcess(), and rundll32 is not trusted, then it will raise the alarm. So yes, I'd think CloneRanger's setup would work.

OTOH, your average antivirus probably wouldn't know what hit it.

 

Okay that's good to know, thanks! I've been under the impression that shellcode is going to bypass HIPS and anti-exec software, and not just antivirus.

 

Don't take my word on it.

In this case though the shellcode is injected into a spawned program (rundll32.exe). The problem is more that that's a Windows component, and might be trusted by default by security programs.

 

Understood, thanks again

 

GJ is pretty much correct. The shellcode is used to call the API that executes the binary rundll32.exe. Rundll32.exe has its own arguments, so the attacker can then have that process execute commands on its behalf.

If an AE doesn't have it as a trusted component or whatever the hell they're calling them now, and if it's hooking the call (it almost certainly would be) it'll stop it.

Exploits always start with shell (well, not really, but this type does). That isn't a get-out-of-AE free key or anything, AE just kicks in once the attacker starts messing around with the APIs that AE's monitor. Attackers are, as always, free to use any of the other thousands of API calls available.

Hope that clears it up a bit.

 

Yes that helps, thanks. But one thing I just noticed:

I thought the shellcode injected itself into the browser's memory heap, or whatever they call it?? So i figured from there it spawns Rundll32.exe?

 

Eh, the word 'shellcode' kinda means a lot of things. We're not really talking about exploiting the processes memory int erms of rundll32.exe, it's just that it exploits MSIE, controls MSIE's memory/ control flow, and then the attacker controlled MSIE calls (in a completely valid manner) rundll32.exe. rundll32.exe then acts as a 'host' for the next 'stage of shellcode'.

The attackers most likely picked that binary because it's a typically trusted component and it's not really misbehaving when it takes in a dll or some other content and runs it - that's what it exists to do.

 

Complicated stuff but interesting all the same I guess the msvcrt.dll PE headers, mentioned in the article, are read as part of the "fingerprinting" process of the attack, so the attacker's server will send a specific exploit based on the information in the headers?

 

http://www.fireeye.com/blog/technic...linked-to-deputydog-uses-diskless-method.html

 

Update: Microsoft to patch just-revealed Windows zero-day tomorrow
November 11, 2013
http://www.computerworld.com/s/arti...patch_just_revealed_Windows_zero_day_tomorrow

-----------------
Microsoft plans to address zero-day IE bug on Tuesday
http://news.cnet.com/8301-1009_3-57611860-83/microsoft-plans-to-address-zero-day-ie-bug-on-tuesday/

 

I wonder if/when support for this one will appear in Metasploit.