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 thing an 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 now and 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.

25 thoughts on “ExploitShield – Smart AntiExecutable

  1. Hi,

    Nice review about ExploitShield.
    Thanks for shedding light on the real capabilities of the application; reading you helped me to better weight its benefit(s) and draw backs.

    Could you please share your view regarding Sandboxie (the application) in the line of security layer against exploits & payloads.

    In advance thank you.

    • Thanks, glad I could help.

      Sandboxie is a different sort of product, it works by isolating applications, and preventing them from writing to the file system. I’ve never analyzed the program too far, but the idea behind it is solid – least privilege is a good thing, and virtualization makes it easier to enforce. Without really looking at it and seeing how it works I can’t really verify it’s written well or anything like that, but the design is solid.

      The only issue with Sandboxie that I can see, without looking too hard, is that there’s only a single developer for a very large product. That, to me, is a bit of an issue when the source is closed, and when I have no clue who the guy is.

  2. Thanks for the prompt reply.

    Indeed Sandboxie seems different.
    By putting pieces together, my understanding of its protection is that a payload could be executed but will have no persistence as long as the session in witch everything happened get reset/cleared.

    And regarding the solo-developing matter, it definitely could end up being a severe handicap. Hopefully the program is not being targeted (already).

    Thanks for the input. I shall keep on flipping through your pages.

    • Hey sarky,

      Yes, if you clean our your sandbox then the payload would be eliminated, but you wouldn’t get persistence even if you didn’t with Sandboxie, as an attacker would have to write to the *real* registry, and not the virtualized one to do so.

      If you have any questions while reading through the stuff just let me know.

      • Hi,

        Thanks for the offer, i shall send you some direct mail about something im trying to figure out and planning to configure, it will involve implementing GrSecurity among other things.

        Will get back to you as soon i get my hands “dirty”.

        Thx

        • I’m really bad about checking my insanitybit@gmail.com email, so it may take a few day sfor me to get back to you. For speedier responses, just leave a message in reply to this topic saying you’ve emailed me.

          • No problem for a late reply, will use the time to fiddle around :))
            Thanks for the Mail address; i shall wave you here as soon as i message you.

  3. Hi there,

    Can you please write an article, in non-technical terms, about the step by step process in which a program(preferably a browser) is exploited, payload executed and the system compromised ?

  4. No offense, but if know what you were talking about, you would not have called Malwarebytes an antivirus. I love their product too but you shouldn’t spread the use of the wrong term.

    • Their product is an Antivirus. Unless you want to call it “antimalware”, which is a completely meaningless semantics issue, as literally no single AV that’s still produced today only protects against “virus” and also protects against adware, trojans, etc ie: “malware”. The classification hasn’t really meant much in a long time, as most malware samples fall into multiple classes.

      • That information is something I’ve known for years, but I still do not think it should be called “antivirus”. As many of their users are informed, there are infections malwarebytes won’t remove and among other things. I just try to follow what the mbam team tells us.

        • There’s just no real distinction anymore between calling something AV or AM, calling one AM and one AV only serves to confuse users, in my opinion. In truth, even if a program only detected viruses as opposed to all malware, it would work literally the same way.

            • I saw their response. Hearsay implies that it’s unfounded, when it isn’t – the person I linked to is an established researcher who examined and reversed the program.

              In terms of my problem with their program, it’s that:

              1) The name is misleading, yes.

              2) Before the takeover by MBAM they had lots of statements saying they were appropriate for dealing with APT attacks, which they are absolutely not

              3) They are one of the least open security services I’ve seen, basically giving menial information about their product, and then stating that everything else is intellectual property

              I can probably come up with more reasons, but I fear it’ll just start more nonsense with them, and while I have it in my abilities to analyze their system (and truly end the conversation), that’s not a trivial task, and I’m trying to get ahead for my classes this upcoming semester.

  5. Something that seems “Hot”: https://immersion.media.mit.edu/

    I don’t really feel comfortable typing in my password: + i don’t get it how they can delete data from servers that are not theirs (detail given in the video).

    What do you think ?

    Thanks for your input.

    • I would absolutely not give them your password, that doesn’t seem worth it at all. There are APIs for plugins/ websites to access GMail, and if they need more access than that, I wouldn’t trust it.

      • Great ! so i went the safe route not giving out my password.
        M.I.T guys, maybe with the Prism rigmarole Google Inc temporarily closed the backdoor on his friends, making those to resort to alternative techniques to get inside of peeps inbox ? hehehe.

        • Well, not so sure about anything like that Lol but handing your password out is no good in any situation

    • Jen,

      I think you’ve somewhat missed the point. As I’ve said in every post on AntiExecutables they’re perfectly fine for run of the mill malware, malware that doesn’t know or care about AE. But if an attacker knows the system has AE, and wants to bypass it, it takes little to no effort for them to do this generically across all of their payloads.

      So while an AE may stop malware.exe from running, an attacker simply needs to modify their attack very slightly (and in well documented ways) to make it succeed.

      I’m also trying to make clear exactly what an attacker can do before they run malware.exe, they have full arbitrary execution. They can download files, control other processes, read, write, delete files from the system/ registry.

      So my problem with AE is that they don’t really protect you in any meaningful way. It isn’t exactly ‘snake oil’ but it’s use is highly exaggerated and seems to be based on the premise that hackers will never care about users who run AE enough to spend the little time it takes to bypass them.

    • Jen,

      I think you’ve somewhat missed the point. As I’ve said in every post on AntiExecutables they’re perfectly fine for run of the mill malware, malware that doesn’t know or care about AE. But if an attacker knows the system has AE, and wants to bypass it, it takes little to no effort for them to do this generically across all of their payloads.

      So while an AE may stop malware.exe from running, an attacker simply needs to modify their attack very slightly (and in well documented ways) to make it succeed.

      I’m also trying to make clear exactly what an attacker can do before that run malware.exe, they have full arbitrary execution. They can download files, control other processes, read, write, delete files from the system/ registry.

      So my problem with AE is that they don’t really protect you in any meaningful way.

  6. A very nice read.

    Despite the recent findings about Sandboxie’s limitations by Bromium I find this article enlightening especially in regards to Sandboxie.

    Many people who have read the bromium article are now very concerned about their security setup and their defenses against advanced exploits. They think about giving up on Sandboxie and switch to so called anti-exploit programs or anti-malware solution which offer “exploit protection” instead. The reality of it seems to be they are just another anti-executable, just a less noisy one than the standalone solutions. Sandboxie on the other hand already comes with its own anti-executable feature found unter restrictions / start/run-access.

    So from what I’ve read these so called anti-exploit programs offer no actual exploit protection. Hence the advanced exploitation scenarios mentioned by Bromium will bypass these applications just as they bypass Sandboxie. I think this in an important issue because the vendors profit from this misunderstanding. That’s why they’re obfuscating how their programs really work.

    People might even think anti-exploit programs and their counterparts in internet security suites will protect them against OS kernel exploits. Misconception as a business model.

    • The newest MBAE is now claiming to address the issues I’ve stated in this article – they finally have actual stage one payload mitigation. They have absolutely 0 documentation on it from what I’ve seen, and my guess is it’s a modified EAF from EMET but I have virtually no evidence for that.

      But yes, it is largely about misconceptions.

Leave a Reply

Your email address will not be published. Required fields are marked *