Universal ASLR Bypasses And How To Solve Them

Address Space Layout Randomization is an exploit mitigation technique that focuses on preventing Return Oriented Programming attacks. It’s become one of the “must have” tools for a secure program (like DEP) and it’s preset in all modern user-oriented operating systems.

Mitigating ROP is pretty important as most modern exploits take advantage of it. And ASLR would be entirely effective in an ideal world where every single part of address space is randomized and 64bit address space is impossible to bruteforce and heapspray doesn’t exist. We don’t live in that world and there are universal ASLR bypasses for Windows and Linux, heapspray does exist, and the majority of users are stuck in a 32bit address space (and 64bit vanilla ASLR isn’t necessarily impossible to bruteforce).

Windows is actually pretty on top of things with ASLR (as of Windows 8) and /FORCEASLR but there’s always going to be a way around it (unless some things seriously change.)

So what’s the answer?

Well, for non-performance critical applications perhaps a solution like Gadgetless Binaries would be a viable option. Gadgetless binaries would compile code in such a way that an attacker would be unable to make use of static address space instructions to form their attack.

There is a performance hit here so I’m not saying to compile everything with it, but for security critical applications why not? There are specific areas of Windows address space that are loaded in the same exact place every time – why not compile that area with gadgetless binaries and avoid situations like this?

There’s also a somewhat less effective In-Place Code  Randomization technique and even less effective (though still welcome) EAF, which is what Microsoft has implemented.

Perhaps I’m just missing something. Maybe this would require paying out or some such thing but it seems like a great idea to me as ASLR isn’t going to solve every problem. At least not with current implementations (outside of PaX ASLR, which makes use of many other features via Grsecurity to prevent attacks against ASLR).

Sources:

http://iseclab.org/papers/gfree.pdf

Securing Windows

Windows is the most popular and most targeted operating system but a lot of the more common attacks on it are trivial to defeat. This guide will cover some  simple steps to secure Windows and keep your system safe.

Reducing Attack Surface

This should be the first step to securing literally any operating system. Code is attack surface, running code is valuable attack surface, internet facing code is a gold mine.

First thing’s first go ahead and run msconfig.exe. Disable startup applications you have that aren’t important like some toolbar service. Don’t disable applications looking to update.

You can also look in services.msc and disable what you don’t need. Personally, I don’t print from my computer, so right away I can disable the Printer Spooler service. This service has been involved in many infections and an exploit in it allowed for Stuxnet to propogate. There are other services like Computer Browser that you might want to disable. Don’t disable anything without understanding what it is, I suggest you check this wiki out for explanations:

http://www.blackviper.com/windows-services/

I don’t know who that guy is or why that site is the way it is… but the wiki is fine.

You should also uninstall any programs you don’t really run. Maybe you have Java installed but you don’t really know why – get rid of it. Java’s a massive hole on your system. Maybe you have 5 torrent clients for no real reasons, remove 4 of them. Just get rid of what’s on your computer if you don’t need it.

Run EMET

I’ve posted about EMET twice now with an explanation as to what EMET is and a guide to set it up. I highly suggest you follow that guide to the letter.

EMET is probably my favorite tool for Windows security. It’s not going to prevent every exploit ever but pretty much any automated exploit is dead in the water and even a targeted attack will be more difficult against a service running EMET.

If you follow my guide you’ll have many of the critical applications running EMET.

Stay Patched

Staying patched is the easiest way to stay secure. It’s a lot easier for bad guys to exploit known vulnerabilities than to come up with new ones. Even if you’re running EMET and you’ve reduced attack surface if your system is full of vulnerabilities that are well known to every skiddy and hacker out there you’re going to be an easy target.

Set Windows to automatically update.

Guide to set up automatic Windows updates here.

You should also check for browser and plugin updates frequently as these are very commonly exploited.

If you use EMET, uninstall and disable unnecessary software, and keep your system up to date you’re going to avoid most threats for Windows. This isn’t all you can do to secure Windows but if I’ll recommend the above three tips every single time. They’re pretty universal for securing Windows users.

EMET – A Windows Security Tool That Everyone Should Use

Techniques like ASLR and DEP have made exploitation of modern software more difficult. And yet many programs still don’t make use of them. Why? Well, sometimes it’s a matter of compatibility but very often it’s simply a matter of the developer not knowing or not caring enough to implement them.

EMET sets out to fix this.

There are very few programs that I think belong on every single computer. EMET is one of those few.

What is it?

EMET is the Enhanced Mitigation Experience Toolkit and it’s pretty damn cool. The goal of EMET is to prevent programs from being exploited by forcing them to make use of modern mitigation techniques (EAF, SEHOP, ASLR, DEP, HeapSpray, Bottom Up Randomization.)

The Good

EMET attempts to bring insecure programs like Java (which is the most exploited piece of software for Windows users) up to speed in terms of security. By running Java with EMET you can prevent a ton of exploits that would have otherwise led to infection. You can also run your browser with EMET to prevent Flash/ browser exploits.

EMET also uses virtually no resources. EMET.dll is something like 44kb and that’s all that’s loaded into programs. The mitigation techniques should have a negligible effect on performance as well.

Compatibility is easy to maintain as EMET can be used on a per-program basis. I suggest that you run your PDF viewer and Java with EMET and consider running your browser as well.

Windows XP users should be downloading EMET as soon as possible. XP doesn’t have any form of ASLR but EMET will provide EAF, which is another ROP mitigation (though less effective.)

The Bad

EMET is not a replacement for an antivirus. It offers absolutely no detection of malware or malicious activity – its only goal is to prevent exploitation.

Even with all of those mitigation techniques there are ways around them; DEP and ASLR just don’t apply to every situation ie: JIT Spraying, which needs a whole separate class of mitigation. EMET drives up the cost of exploit, it doesn’t eliminate the threat.

Some of the techniques like EAF and HeapSpray are also easily bypassed, they’re more for defeating automated attacks, which is still valuable since that’s what the average user will come across.

There are potential compatibility issues with EMET. Very old programs can’t handle DEP and they’ll potentially break even if you just install EMET. It sucks. I suggest you contact the developer and remove EMET in the meantime.

It should be plain to see why EMET is such a significant security tool. Forcing horribly insecure programs like Java to start acting like modern software is probably the most important first step in securing Windows. EMET is a must have, whether you’re on XP, Vista, or 7.

I’ll be posting a guide with screenshots on how to set up EMET very soon.

Grab EMET Here:

https://blogs.technet.com/b/srd/archive/2012/05/15/introducing-emet-v3.aspx?Redirected=true