ExploitShield – Smart AntiExecutable
edit: I want this edit right at the top. ES has apparently stated that they have now (October ’13) added in stage one exploit mitigation techniques. They have provided zero documentation on how these techniques supposedly work. My verdict of ‘use EMET’ has not changed, and I suspect one of their techniques is quite similar to the one used in EMET.
Recently a program called ExploitShield by the start up Zero Vulnerability Labs made its way into the security market, offering to protect against a wide variety of exploits. Just the other day it was purchased by Malwarebytes and rebranded as Malwarebytes AntiExploit. I find MBAM to be one of the best antiviruses, and I understand why something like ES would appeal to them, but I don’t see ES as being such a boon to security.
ExploitShield is essentially a “smart antiexecutable”, though they wouldn’t call it that. It actually has very little to do with exploits, and it certainly doesn’t prevent them. Instead it attempts to detect the exploit, and then prevent any new payloads from executing. This is nice, compared to a regular AE, because it’s not so stupidly overbearing. But just like an AE the attacker already has full remote code execution once they get shell, and the defense takes place too late in the game.
ExploitShield does not prevent exploit (despite its name)s, it does not make vulnerabilities more difficult to exploit. What it does is it attempts to detect exploits in various ways, and then, based on that detection, it decides if the ‘shielded’ program should be allowed to execute a payload.
My real issue with ExploitShield is that it actually doesn’t do anything to prevent exploits. It detects them, and then takes basically a single measure against them, preventing their final payload from executing. This is not nearly comprehensive enough. Until the recent merger with MBAM ExploitShield claimed to prevent Advanced Persistent Threats, or APT. APT is basically an attack in which an attacker is dedicated to defeating your system, and has some knowledge of the mechanics behind your security policies. An attacker with knowledge that you are running ExploitShield would tear through it. All of the 0days that work without ExploitShield work with ExploitShield the only thingan attacker has to do is change how they execute the payload.
How I would bypass ExploitShield is creating a buffer in memory, and using reflective DLL injection (optional, just to avoid AV detection, and forensics). I’d load that DLL into another process (AFAIK ExploitShield does not hook CreateRemoteThread()) and then execute it in the context of another, unshielded process, or really any process, shielded or not, because it won’t detect an exploit in Pidgin if I exploited Firefox. The details are a bit more complex, if they detect process ID enumeration, or one of the other steps, that’s that. But I think with just a bit of extra ROP you can prevent their detection.
I’m sure there are many other ways to bypass ExploitShield. For example, I could drop my payload and not execute it, and then, from shell, write a startup entry to the Windows registry. The user reboots at some point, the startup entry activates, and there you go.
I haven’t tried these things, but I’d like to. I’ve been meaning to write a POC “malware” to bypass AV/AE/ES for a while now, and I have the framework written out, I just have to get around to it. Either way, whether these specific bypasses work, or if there’s some tiny flaw, I am certain that, by design, ExploitShield is not going to protect you from exploits, only their payloads.
I take issue with a product saying it prevents something when it doesn’t. All it does is detect specific traits that exploits can leave behind.
A semi-formal review of ExploitShield came out, in reaction to the way-too-positive reviews from journalists who don’t know what they’re talking about, and it wasn’t exactly positive (read it here). The response from ZeroVulnerabilityLabs was to pick out a specific part that was wrong (having to do with detection) and state that that’s not how it works – they don’t say how it works, just that it’s different. Of course the method of detection is irrelevant and the real issue is that it’s simply hooking a few functions and trying to detect exploits when they’re called.
The post details that ExploitShield is fundamentally not about exploits, and that they are misusing the term.
It is my belief that when ExploitShield uses the term ‘exploit’, they really mean ‘payload’.
[…]
ExploitShield is great if the attacker doesn’t know it’s there, and, isn’t globally represented enough to be a problem in the large for an attacker. If the attacker knows it’s there, and cares, they can bypass it trivially.
Enough said? Well, not really. The author goes on to discuss other issues, but I don’t feel the need to.
I like Malwarebytes, and I find it to be the best antivirus. They’re a legit company, and maybe they’ll turn ExploitShield into something legitimate as well. But until then I don’t see its use, it just seems like extra attack surface.
If you want a real anti-exploit program, use EMET. It actually prevents exploits, or mitigations stage 1/2 payloads (as opposed to stage 3, which is the final executable) and prevents an attacker from ever getting shell access.
I wish I could write something nicer, because I do like MBAM, but I really dislike products with misleading names. Since the takeover they’ve removed the nonsense about preventing APT, but the name “ExploitShield” is making people ask “Do I still need EMET?” as if they do the same things. It’s a disservice to your customers when they don’t understand your product.
Keep in mind that I began writing this quite some time ago, and only published it recently. In all of this time MBAE may have changed, and they certainly claim to have done so. While I consider their flaws to be somewhat inherent to the design, I can’t confirm that everything I say here will always remain true, and until I perform an in depth reverse of their product I can not claim anything about how they are right nowand only how they were in the past. This isn’t to say that I believe they are suddenly incredible, or worse, or anything – but people seem to have some issue so yeah, there’s your little disclaimer.
blog comments powered by Disqus