Defeating ASLR and DEP with JIT Spraying and how to mitigate

http://www.piotrbania.com/all/articles/pbania-jit-mitigations2010.pdf

I was just reading through this.

JIT spraying is a method that allows the attacker to bypass ASLR and DEP (which rely on each other to work properly *cough* WinXP.) This paper describes the attack and how it can be mitigated.

In case anyone is interested =p

 

Also: https://www.wilderssecurity.com/showthread.php?t=289164

 

Thanks Funky.

 

It "seems" to be Flash etc related. So no Flash =

Good for XP

Don't install .NET

 

Don't install anything = even more

Fail logic. Attack surface directly relates to how much you install.

 

I agree. You have to make sacrifices in security for functionality and usability.

 

FYI; a publication and presentation PDF on JIT spraying can be found at Digital Security Research Group link.
(the referenced publication in the OP linked PDF; 'Writing JIT-Spray Shellcode for fun and profit' from Alexey Sintsov).

 

Only if it's attackable etc. Having an AntiExe etc etc in place puts a stop to that

Well might have to if you did, doesn't mean others do or have. I havn't, as i keep saying

Tell me Exactly how i'm going to get infected on my comp ?

 

Having an antiexe in place puts a stop to a new process being started without your consent barring exploits.

Of course, if you'r eon an incredibly outdated machine exploits are a dime a dozen.

Let's also not forget that it's XP, which means there's no ASLR, which means Return to libc attacks will run just fine and DEP is essentially useless.

A single running program, hell even your OS, provides everything an attacker needs when you leave it full of well known holes. Default-deny won't stop an attacker from hijacking an already running process (like your OS) and using its own code/ libraries to do what it needs to.

 

Exactly ! How are those exploits going to get in ?

Name one with a link that could get through my defences, & exploit ? I'll run it

I mentioned in another thread i'm thinking of reinstalling WehnTrust. Not because i'm frightened, just to see how it does. Anyway a nasty would have to get in to to it's deeds in the 1st place. How is it going to ?

Name me one exploit with a link that could get through here ? I'll run it

 

Uhhhh with ease? lol exploits don't need to be on your system to exploit it. They can run in the browser/ exploit the browser, plugins, or a worm can exploit your firewall (there was just a recent 0day in the windows kernel that exists in XP SP2.)

I don't keep exploits in my back pocket.

They get in through the exploits, not vica versa. It does not go "program runs and then program exploits" it goes "program exploits and then program runs." And, as I said, without ASLR and on an unpatched XP SP2 there are likely plenty of buffer overflow attacks that can easily result in running native libraries ie: return to lib c and that's not the end of the ways they can avoid application whitelisting.

That nice kernel level 0day I mentioned before unless you're behind a hardware firewall/ 3rd party.

That said there are likely hundreds of other vulnerabilities that you haven't patched.


EDIT:
To be clear, not all exploits will download and execute a payload. To execute a payload means you need to load up the file into executable memory. ASLR and DEP make this fairly difficult.

Lucky for malware writers they dont need payloads. They can work with the process they just broke into - the one you have whitelisted.

 

Are we talking software DEP only, because I have both, i.e. hardware DEP.

Just wondering.

 

Just as thought ! You didn't name one, or provide a link to an article etc.

I'm not the slightest bit worried about getting infected. As i said before, the day i do i'll post about here.

Yes i have a firewall in place & configured nicely. I notice you are asking about What does a firewall do? https://www.wilderssecurity.com/showthread.php?t=312786 They do plenty

 

Hardware DEP and Software DEP should effectively be the same except that Hardware DEP will be more difficult to circumvent/ possibly have less of a performance hit (if DEP would ever have a performance hit...)

 

I named the Windows 0 day that effects WinXP and above's firewall.

If you want to see a list of vulnerablities that can get you at any time simply go to windows update and check for updates. A nice long list should pop up.

I'm aware of the basics of what a firewall does. I'm looking for more in depth concepts and specifics.

Anyways, Windows is written primarily in C++, which is very vulnerable to buffer overflows. We mitigate this risk somewhat with tech like DEP and ASLR. Unfortunately DEP isn't super great without ASLR and ASLR isn't supported in XP without EMET. You could install EMET but you'd have to update your OS (and darn it, as a byproduct you'd improve performance, stability, and security as well! what a shame) but for whatever reason you're against doing that.

idk what more you want lol I've explained that whitelisting is not an end all be all solution and that exploits can run within a process.

 

No you didn't, you said this,

My FW isn't XP's, it's a 3rd party one.

No i didn't ask for that. I asked you Specifically to name one exploit that could get through MY defences. You didn't ?

What about WehnTrust ?

Nothing wrong with ANY of those things here !

Because there's no problem with my comp. If there was i'd change things. As i mentioned before, i've run the nasties stuff on here = Ziltch effect. If that doesn't prove it, i don't know what will !

 

I'm really not motivated enough to search "Windows XP critical vulnerability" in order to convince you that by not patching well known security holes you are full of well known security holes.

Yeah I'll never really understand this.

 

SUPER

 

The end point in Memory corruptions attacks(buffer overflows or arbitrary code executions) would be the miniscule shellcode to try to do the usual download and execute malwares or trojans or to load the malicious executable(the malicious dll, driver or exe files), and default deny will be able to stop those payloads like that of the sophisticated Stuxnet with its four zero day exploits(lnk exploit, buffer overflows/arbitrary code executions, privilege escalations). The rare exception default deny would fail would be that of the theoretical kernel exploit of the Embedded font vulnerability which possibly can bypassed all security defences like Sandboxie, HIPS, Applocker, etc excluding full virtualization. I can't possibly tell how DEP, ASLR et al will actually fare from such theoretical kernel mode attacks. Possible real world kernel mode attacks would be the exploit that served the Duqu malware. But with layered defences like having light virtualization(Shadow defender) and some hardening(unregistering t2embedd.dll) even the said worst kind of kernel exploit can be mitigated even without ASLR or EMET. There are plenty of critical vulnerabilities(privilege escalations, buffer overflows) but having a kernel vulnerability(privilege escalation) with remote code execution translated into a single succesful kernel exploit which can bypassed all security defences sans hardening mitigations is rather rare. Ordinary buffer overflows which is rated critical is nothing to Sandboxie for e.g.

 

@ trismegistos

Hi, yes i'm also convinced that default deny = Antiexe/dll etc, which i have, would be enough. I'm sure Rmus would agree too.

I tested the .LNK vulnerabilty at length on here. Yes the .LNK worked, but the payload did NOT. That was due to my not allowing rundll32.exe free reign on my comp.

My XP isn't vulnerable to the t2embedd.dll exploit, i tested it on a vulnerability www for it recently, can't remember which www.

Plus i also have ShadowDefender. So all in all, i feel Very secure.

 

The end point of almost any attack is to move tools/ programs over.

But if you have shell access in a program you can do a lot without a new process starting. I'm not sure how the default deny works but if you can get yourself some addressable RWX space you should be able to launch anything you want.

And this is XP... so unless you're on LUA anything should be able to elevate. If it can elevate it can turn off anything you've done. At least in V/7 you get a warning when something does this.

Furthermore, depending on the exploit (in this case it's an unpatched OS so you can get some really critical ones) it can be severe enough that they can simple turn off default deny. If they get admin they can turn off whatever they like.

And you don't even need a kernel exploit, which would bypass everything. DEP and ASLR are about stopping that from happening to begin with whereas things like Sandboxie/Shadow Defender play cleanup. Because the exploit happens at the lowest software level nothing can mitigate it except perhaps something as low as the kernel.

@Clone
I'm not saying "You'll be infected." I'm saying you're needlessly adding risk and that you can be infected. I doubt many exploits take default-deny into account but if they did it wouldn't be hard for something like StuxNet to take the extra step and disable it first.

 

Memory corruption attacks is only the first step. The next step is to trojan the system and to clean the logs. Yes, the shellcode can launch anything(the payload whether it's a dll or a driver as in Stuxnet, TDSS etc). This is where default deny will stop their tracks.

I am not sure how can one can do a lot with the constraint in the limitation of the size of the shellcode other than the usual which is to download and execute malware. It's quite possible to do other than that but I haven't seen an actual exploit that do otherwise.

Privilege escalation kernel mode exploits would even bypass LUA, Sandboxing, HIPS. But since majority of these kernel or privilege escalation exploits would require an initial remote code execution attack just like Stuxnet's Lnk exploit would serve the malicious dll containing that kernel exploit, thus default deny with dll control can stop that malicious payload from serving that component containing the kernel exploit which can bypass LUA, Applocker, AE, HIPS, Sandboxie etc.

That's why even critical vunerabilities like buffer overflows and the usual privilege escalations is nothing for Sandboxie for e.g. as I have said before. That's why you won't be hearing from Sandboxie users complaining that they had a malware that have bypassed the containment.

I agree nothing can mitigate the memory corruption attacks other than those you present. I myself would mitigate or patch those very rare critical kernel vunerabilities having both privilege escalation and remote code execution like that of the EOT vulnerability(t2embedd.dll) which possibly can bypass any security.

 

The next step is not always to download and launch the payload at all. If it's a direct attack ie: human they often look around first before moving tools over.

There are going to be multiple libraries included in whatever it is you're attacking and without ASLR you can just keep pointing back to those and you can do quite a lot. If it isn't LUA you won't even need privilege escalation to turn off default deny, even a user can do it.

And really you don't even need privilege escalation to own a box.

Yep, you'd probably need some payload on the host for a privilege escalation exploit. But it's not always necessary and that's not even just going with kernel exploits.

The reason I was focusing on ASLR is because if you get a buffer overflow and there's no ASLR it is easy to bypass DEP and if you can bypass DEP getting further address space isn't an issue (it's all executable without DEP.) You can bypass DEP from a shell in the right code with multiple techniques like certain calls or ROP. VirtualAlloc() ?? There's all the space you need.

edit: source http://binholic.wikkii.com/wiki/Windows_Protections#DEP

The only real way to defend against exploits is to patch them. OS exploits are incredibly dangerous.

 

Funnily enough today is the three year anniversary of Conficker. We should call it "Patch your sh** day"

http://nakedsecurity.sophos.com/2011/11/24/the-conficker-worm-three-years-and-counting/

 

You are probably referring to old hacking attacks like port scanning. Then bufferoverflows on the vulnerable service listening on that open port to have a shell and thus own the system. How would one do that if one has a firewall.

Yes, those were the days of the internet worms.

Again how can one spawn the right shellcode to disable or turn off one's defences like to disable the victim's firewall if he or she has other layer defences like HIPS, light virtualization and Sandboxie. How does an attacker or a hacker knows what security to disable unless he trojan the system first or have adequate reconaissance. He can probably do the unhooking to disable the antivirus for e.g but that would require a payload to do the job. Unless perhaps the attacker is an uber hacker with his super duper shellcode.