Dealing With Advanced Threats – Where AV Fails

If the Flame malware gets one message to the masses it should be that antiviruses are a failure.

The truth is, consumer-grade antivirus products can’t protect against targeted malware created by well-resourced nation-states with bulging budgets. [1]

Yeah, no kidding.

The fact is that, at best, a few antiviruses would give a warning about generic heuristic detection for Flame and obviously that wasn’t enough because it’s been around for years. Potentially quite a few years, actually. And it’s not the first, Stuxnet went undercover sometime as well as various others.

Antiviruses, in terms of blacklists and heuristics, are actually a necessary part of security. I currently wouldn’t touch a single one of them out there but I appreciate the principal, that I as a human am not capable of knowing whether a file is malicious or not therefor an AV automates the process on a level only achievable programatically.

The point is, whether AVs can or can’t be great in some ideal world, the current security solutions aimed at users are not enough and trying to lock a users computer down beyond that is impractical with the tools we have been provided with. If we’re ever going to see improvement we need something radically new.

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

Browser Wars – Everyone Else Does It

Browser Wars – Security Style

Browser wars are monthly blogs (typically following the latest release of a browser) that basically pit the latest versions of todays browsers against each other. It’s kinda lame and I feel like a tool for doing it but I’m also really bored and I think browsers in the context of security are awesome.

So, let’s start.

What Makes A Program Secure?
In an ideal world we humans would be perfect and our code would be perfect and vulnerabilities wouldn’t exist. This is not an ideal world and we are not perfect nor is our code. Vulnerabilities do exist and for the foreseeable future this will not change. So what do we do to secure programs if they’ll always be full of holes? We accept that those holes are there and we make it as hard for hackers to make use of them as we can. There are various ways to accomplish this.

So What About Browsers?
Browsers aren’t typical programs. They’re fast paced, constantly changing, plugin-filled conduits to the wide open internet. By design they take in untrusted code. They’re just dangerous and that’s why they’re so great to look at for security.

Internet Explorer 9
Internet Explorer has laughable security, right? I mean, hey, IE6 on XP was terrible and nothing’s changed. Not exactly. Microsoft has learned from their (massive, gaping) mistakes and then some. IE9 is no IE6 by any stretch of the imagination. It’s got a multiprocess architecture that allows for tabs to be separated into low-rights processes, which means that an exploit in a tab is confined to that low-rights process.
On top of that IE9 has a new version of SmartScreen, a URL and File Blacklist based on “File Reputation” and heuristics. There hasn’t been a formal study other than the one by NSS Labs on this that I know of but NSS Labs gave a remarkable score of blocking 96+% socially engineered malware (compared to trivial scores hovering around 13% for other browsers.)
As I recall Adobe Flash also runs at low integrity when used with IE9.
The low rights sandbox and smart screen make IE9 a very secure browser.
IE is Windows only and closed source.

Mozilla Firefox 4.0+
The Firefox browser, which is developed by Mozilla, is a free and open source browser that’s been very successful. In terms of customizing UI and features Firefox is top notch and it blows Chrome and IE9 out of the water in that respect. In terms of security it is… lacking.
Firefox does implement modern techniques like ASLR, DEP, and SEHOP and it even forces ASLR on toolbar binaries.
It also makes use of the Safe Browsing API 1.0, which (last I checked) blocks something like 15-20% of malware downloads.
Firefox does not implement any “extraordinary” security measures. There is no sandbox, there is no special file reputation whatever or special memory hardening technique. There’s just nothing that really stands out about Firefox.
Firefox users are able to make use of the NoScript extension, which is potentially a really great tool, but it’s not exactly accessible for the average user and I’m partial to security features that don’t bug me.
Linux users can make use of a “whole-browser” sandbox via Apparmor/LSM. A profile is provided by default on Ubuntu but it may take some tweaking, I highly recommend you check out AppArmor for your browser – check out my guide here.

All in all, I want to love Firefox, but I can’t really give it a ton of credit here.

Google Chrome X.XXX.XX.XXXX+ (or whatever)
Google Chrome is the (relatively) new player in the browser market. At only 3 and change years old it’s had a pretty impressive start, now holding market share close to Firefox. Chrome is based on Chromium, which is an entirely open source project – the difference being that Chrome packages Flash, a PDF viewer, and an update manager (on Linux it also packages support for closed codecs.)
It uses the Safe Browsing API 2.0, which includes a file reputation module. I think NSS  Labs puts it up around 40% block rate. Again, there hasn’t been what I would consider a formal study on this.
Chrome’s main feature is a sophisticated sandbox based on the Windows integrity access control and job tokens. It is similar in architecture to IE9’s sandbox but the restrictions are much tighter, with the renderer having no file access and most of the browser running at absolute lowest rights possible  on Windows.
Chrome also sandboxes the GPU process and all extensions. Each has its own separate process.
Chrome sandboxes the Flash plugin (responsible for a large number of infections) and will soon include a much more powerful sandbox for Flash via the PPAPI(nterface, which is in beta 20.)
On Linux Chrome makes use of a namespace and chroot sandbox as well as the seccomp mode 2 filters. This allows for a strong sandbox, it’s very tight. Apparmor profiles exist for it, which are useful as they’ll even restrict the zygote process. The weakness is that the zygote process must be setUID, which is why an apparmor profile is suggested.
Chrome also limits inter process communication between it and the Java plugin, which can potentially prevent Java exploitation though it’s uncommon.

Opera 11.x
Opera is the lonely browser. On a good day it gets 4% of the market. It’s got something of a cult following and boasts pretty nice performance and a ton of features built in. As with Firefox it’s pretty lacking when it comes to security.
Opera is closed source and there isn’t a ton of documentation for security. There does not seem to be anything special about it.
No sandbox (there might be one on Linux actually but I’m not sure), not too great at filtering malware (I think NSS labs had it at 0-5%, again there needs to be more formal studies here.)
Closed source doesn’t inspire confidence either frankly.

I can’t really suggest Opera if you’re looking for security.

Conclusion:
I guess I should order them or rank them or something – answer that “Which browser is most secure?” question. I won’t try to apply anything numeric to this, that would be dumb, the system is basically an amalgamation of the above and my own personal beliefs on security.

Greatest to least: Chrome, IE9, Firefox, Opera.

I think it’s pretty close between Chrome and IE9. Firefox with NoScript and Apparmor is a pretty secure browser but for a defense in depth approach I’ve got to go with Chrome. It’s dependent on what you’re trying to secure against – when it comes to system compromise you’ll want Chrome but if it’s about preventing XSS/Clickjacking Firefox with NoScript is the way to go.

There you have it. My opinion.

I left a lot out. JIT Hardening isn’t something worth measuring as the javascript VMs all work pretty differently and they just don’t apply. I didn’t both going into ASLR or other mitigation techniques, all of the browsers have these by default at this point and the differences are subtly and in the implementation. I didn’t go into privacy, incognito/ private browsing modes, not much into extensions (this could be its own post), and some other stuff to. So consider this a very simple rundown on security. Even if I were to include everything the results would be the same, you’d just be better informed.

I’m also not going into IE10, which will include some fairly significant security improvements.

Choose the browser that is right for you. Maybe that’s the one that you think is most secure, maybe it’s the one with the UI you like best, or really any other reason. It’s your choice and it’s entirely up to you.
Sources:
http://www.accuvant.com/blog/2011/12/05/which-web-browser-is-most-secured
https://www.nsslabs.com/assets/noreg-reports/2011/nss%20labs_q3_2011_browsersem%20GLOBAL-FINAL.pdf [PDF]
http://windows.microsoft.com/en-US/windows-vista/What-does-Internet-Explorer-protected-mode-do

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