What Kind of Malware Can Bypass Anti-Exes?

may not be the best but it helps to reduce malware risk

 

I don't think you're the only one. I think people get confused - by definition if malware can't execute then, of course, you can't be infected. But malware *does* execute, it just stays in RAM and a new payload can't be directly executed through the typical and simplest methods. You also bring up the convenience issue, which I agree with - they're just annoying to use for the average user and while there's always a compromsie for security when you consider how little you benefit from an AE I don't know how you can put up with one. I wouldn't say to disable it just as I wouldn't say to disable EAF in EMET but I wouldn't go through any trouble with it either.

I'd recommend Sandboxie over an AE, definitely.

Against current malware, definitely - just as EAF protects you from current ROP attacks so does an AE protect you from most malware out there. The costs of attack isn't raised, really but from a managerial standpoint for C&C malware there is a potential cost I would imagine, though nothing that big.

 

I agree with you. I came to the conclusion some time ago that a layered security combining virtualization and policy restriction provides a high degree of security without involving the user in decision making as to what to behaviour to allow.

I agree that if choosing just one program, Sandboxie would be an excellent choice. It doesn't cover all the bases but one of the strengths of Sandboxie is that it's more than just virtualization in that it also has a number of policy restriction features. The user therefore gets the benefit of both approaches within a single program, albeit only for those applications that are running in the sandboxed environment.

Approaches that work by isolating and restricting behaviour don't help with social engineering attacks though if there is no suspicious behaviour to isolate or restrict. This type of attack is best handled by conventional blacklisting techniques: e.g. anti-malware, phishing and reputation filters, website verification, etc.

Kind regards

 

I like how you define what you consider standards of AE. Wise.

But I wish this wasn't, in its brief totality, what you took away from the thread. Only part of the picture, IMO. Don't just follow the one who has powder dry and ammo cache. Remember, AE being described here is purposefully weak in order to fulfill HM's argument. Applocker is part of a wider system. Consider all MS gear together, for example. EMET, AL, UAC, Firewall. MS just markets them seperately to make it modular and therefore more purposeful and less redundant versus people's pre-existing mitigation wares. BTW, they patch the exploit by design in Applocker. And why people cracking it still in their whitepapers called it a "circumvention".

So surely, weak AE is weak. Yup....indeed. But begs the question. Fallacious.

YOU don't need to be a robot. You can act outside of all this ranting. With that, this thread displays the weaknesses of possible AE designs and I agree in part: I never considered Applocker a keystone as such. However, to be convinced that virt is "the one". I disagree.

You know why.

Because I could trivially bypass your most valuable sandbox with some FFox vuln I found on metasploit. I'll XSS or Phish your ass and then say I found a bypass. Call it what you want. I jacked your computer. LOL


Virt and AE proper (like appguard and comodo) are both hard as hell to hit and would both crap out any skid PoC before a cpu was even fired. Proactive sec. So HM can convolute and redefine to his liking to win arguments and so can I. Call appguard and Comodo what you like. I call them AE, policy-based protection. Woot woot. See what I did there?

Redefined the argument. As HM has this entire dinner party (stole my dinner roll too.)

So cosnider AE/HIP/AV/AntiMalware, you know the AE or policy based protection you knew as such and the OP was keying on before this thread tainted everything with broken logic and definition. But we are robots so can't redifine the question or think outside the box in order to mitigate the possible problems at hand.

No standards here. No PoC possible. The end. But people can do what they like--seems to be a common occurrence.

 

Youi'd still be trapped in the sandbox. You can exploit whatever program you want. Exploit it to the roof. Terminate sandbox + delete contents = any exploit and stuff injected from that exploit goes out the window.

The only somewhat reliable...or viable (I'd go as far as to say only possible) ways to circumvent Sandboxie (bypass, avoid, whatever) at all are:

1. Social engineering: Trick somebody into recovering something to the hard drive.

2. Anticipating weakened protection: Hoping the person you're attacking/exploiting has manually deviated from defaults for the worse and allowed certain behaviors outside sandboxes for convenience. Or, hoping a 64 bit user didn't enable Experimental Protection and having the expertise to make use of these trade-offs for an attack advantage.

3. Finding a bug in Sandboxie that allows for breaking out of containment: Doing so would be a high cost as far as I can tell, take a considerably large amount of time and effort, and it can be patched by the very proactive development of Sandboxie thanks to Mr. Ronen Tzur. In reality you have the same likelihood as finding a bug in a massively popular AV program so go do that where you can get more people exploited for your efforts.

Now anti-execution on the other hand (in general) is something I hold to less high esteem now because of the nature of it's protection that which it affords. HungryMan (among other experts) has continually argued (and essentially proven through logic) time and time again that it cannot protect against all exploits. There's collision at the whitelist, RAM-only attacks, and beyond that a considerable amount of damage an attacker can do without persistence from a payload executable dropped to the disk.

They can do all of that with a properly protected Sandboxie system, with one fundamental yet so, so epic difference: they're inevitably trapped in the sandbox. Oops. Now all the user has to do is "pull the plug" and terminate contents and you're out of there dead as quickly as someone in The Matrix when they pull they plug without waking them up first.

If you can reliably bypass, circumvent, or by any means weasel your way out of the scope of the ~99.99% TRUE mitigation protection afforded by security solutions like Sandboxie (as opposed to the ~99.99% "psuedoish" mitigation of an anti-exe like SRP/AppLocker), then by all means prove it again and again with unprecedented logic and offering to make a PoC like HungryMan has so kindly volunteered to do. But, please don't just make statements that sound like script kid material. (I'm not talking to who I quoted here; I'm talking to everyone and anyone.)

I defend HungryMan because I'll be honest...I didn't like what he had to say. There's nothing abnormal about that. It's called denial. It's the first natural, psychological step humans take when they're presented with a significant issue they can't handle and cannot accept mentally. I almost couldn't accept the fact that the security measure I held so dearly did nothing for certain classes of exploits.

Why shouldn't I have taken that away from this thread? I thought a security measure was fairly near rock-solid...I learned it's not. Fortunately for me, I've used Sandboxie in conjunction with it all this time.

I do want to say that I want to give a BIG special thanks to EVERYONE who participated in this thread for their contributions and making this a popular thread!

Thanks again, everyone!

EDIT: I did not in any way, shape, or form, mean any offense to you Sordid.

 

@All

I think my sig is an example of different kinds "off the shelve Anti Executable" , access control list and user rights/intergrity levels precautions (from the OS and from browser).

I am not only thinking it is sufficient protection, when I was recovering from my neck injury I actually thrown a lot of malware and exploits at it (early 2010). Also Rich (exploit analist and confirmed AE-user) has proven often that AE survived most (all as far as I know) POC's and exploits rich fed his AE-based security configuration with.

Discussions of AE being sufficient or AE with sandboxing/policy containment (for instance SBIE or DW) are very hypothetical as I could not see what malware would break programs like Sandboxie and DefenseWall in the first place.

My security setup is in my signature, I know there is a gap: signed malware is allowed to execute (on the important condition that I allow it to execute). Even with this "gaping security hole", no drive by exploit or XSS magic was able to break it when testing in 2010 (there fore I dropped the extra 1806, ADS deny execute bock of downloaded executables).

Regards Kees

 

Infact in EAF's case it too is not a strict definition of a bypass since EAF isn't designed to block ret-into-libc.

From Skypher blog-

 

"Youi'd still be trapped in the sandbox."

Trapped. No.

I'm sitting with your PWs and your financial info. Or if you don't access that, then what exactly are you protecting against? Accordingly, the point is damage, correct; not a bypass as such. Are you suggesting you can create zero damage within a sandbox. Is it truly like Vegas?

Sandboxes/Virt still often allow the chief of all exploits--session attacks within the function of the application you are using. (Typically data leakage from within the SB)


So as you can now see, you can apply HMs exact arguments/vein of PoC to pretty much any singular detached anti-malware tool. I/he/you/kids can still "bypass whatever you'd like to call it" any single REDUCED piece of gear--even a FreeBSD live-disc versus pre-packed malware already widely deployed. But at this point, why talk about that. No-one here believes any one, singled-out and "weakened" tool can evade all exploits. & hope no-one here depends on such an atrocity to pro-sec

But you're correct. A SB (like SBoxie) is a damn good start and so is AE/HIPS.

So for all intents and purposes HM is fighting a different fight from the rest of us (me at least and apparently more). Why he's no so much wrong as he's misaligned with the dynamic argument. All I'm saying.

You did not offend me in the slightest...and hope no one else feels I slighted them either. As HM said, he is here to help, and think all of us are here to do that. & I am certainly trying to help too. Akin to sparring. Someone may get a bloody lip, but it's all a part of training and learning. A bow of respect to begin..and end.

Respect to you, HM and everyone else. I just really hope some person reading through this a year from now can secure his set=up properly in concert with what we all laid out.

Back to icing my lip...

 

You are absolutely correct and I apologize but it's honestly been a strangely long yet short week of bad sleeping and sickness for me...I wasn't thinking straight...

When you said XSS I know exactly what cross-scripting is (see my signature with NoScript) but for some reason in my head I was picturing you arguing that exploits loading malware could escape...not sure where I got that from, lol.

But yes again you're absolutely correct. Information harvesting can be done if it exists in what is loaded in the sandbox environment. Also, keyloggers can be installed in the sandbox.

 

Sordid, you're still confused. I am not the one making the argument about the semantics of a bypass or circumvention. I'm saying that an AE provides no significant protection. If you want to say that avoiding it isn't a bypass that's fine (although every article talking about ASLR bypasses disagrees) the only thing I'm trying to get across is that a system running an AE is not difficult to compromise compared to a system without one.

edit: And I think you're still confused as to what an AE is and what a HIPS is. https://en.wikipedia.org/wiki/Host-based_intrusion-prevention_system#Host-based

@Gobbler, regardless, my point is that it's a pseudo mitigation.

 

Dear Hungry Man, I don't need your assurance that EAF is a pseudo mitigation as it is already mentioned in the EMET user manual itself, I just pointed out something very specific which was not correct like two previous occasions in the past

https://www.wilderssecurity.com/showthread.php?t=324512&page=2

http://social.technet.microsoft.com/Forums/en-US/emet/thread/1d4bfa29-3169-4608-a3ca-ae06d97accd0

 

Then you don't need me to tell you that you were correct then and you're correct now.

 

From the Wikipedia link:

That definition describes a Host-based Intrusion Detection System (HIDS) more than HIPS. One detects suspicious activity. The other prevents it. Using that definition, SSM isn't a HIPS, but a whitelist enforcement tool or application firewall. In reality, the term "HIPS" has become little more than an advertizing term that gets used to describe several types of software. Apps like SSM were developed before that term existed. For all useful purposes, HIPS has no meaning any more. Most of the terms are being (mis)used interchangeably.

Regarding pseudo-security as you're defining it, ASLR fits the definition. It's "security by obscurity". It's little more than trying to hide where the processes are in memory. Applocker is no better when calls like LoadLibraryEx bypass it. Everything in or running on Windows is basically pseudo-security, including sandboxing. As sandboxing becomes more popular, it will be broken/bypassed/escaped more often. We're already seeing examples of this. 'Bypassing ASLR and DEP on Adobe Reader X'.

On Windows, it's all pseudo-security. Theoretically, it can all be defeated, exploited, bypassed, (insert term of choice), etc. Using this kind of standard, a LiveCD isn't secure either since it can't completely protect everything it has in memory from unauthorized change. There is no real security in computing, only varying degrees of insecurity. There's nothing gained from the word games in this thread, security vs pseudo-security, AE vs HIPS, etc. It's equally pointless to isolate one component or aspect of a security package/policy, attack it specifically, then claim one is not secure. How well any component does is irrelevant. It's how the package performs as a whole that matters.

 

I assume you don't know how ROP or ASLR works if you think ASLR is a pseudo-mitigation - ASLR directly changes something critical and provably difficult to bypass, the issues with ASLR are not in the mitigation itself, they're in the implementation - this is in contrast to AE, which has its issues in the idea not the implementation.

I think there's a lot of confusion about the 'word games' here, which is probably not anyone's fault - security programs are really unclear when they label things 'HIPS'.

But I think anyone who was going to learn anything has and trying to explain the same thing over again seems useless when a Google search will do just fine for anyone motivated.

 

I am way too lazy to read this entire thread so apologies if my post is redundant.

Has anyone seen this link? It sheds a lot of light on the subject at hand
http://blogs.technet.com/b/srd/archive/2010/12/08/on-the-effectiveness-of-dep-and-aslr.aspx

 

This has got quite ridiculous. I really don't care if it's called security, pseudo-security, security by obscurity or what else. This thread is full of variable and mis-applied standards and criteria. It doesn't matter if it's the idea or the implementation that's flawed. The result is the same. There are no perfect ideas just as there's no such thing as flawless implementation. Sure, an attacker can punch thru any security layer. Punching thru layered defenses all configured to enforce a single policy is another matter. In theory, most anything is possible so we're all vulnerable. Beyond that, show me.

 

I wish I could explain just how ridiculous it really is.

 

"the only thing I'm trying to get across is that a system running an AE is not difficult to compromise compared to a system without one"

And I agree in sorts. But that's like saying a Sniper is weak and useless due to CQ combat. A sniper is part of a collective fire team. We use the same military based strats here.

So my point is that while some are weaker than others, any single point malware protection is weak. As to raising the cost. Well it raises the cost of user-disc exploits--a real problem. AE by all definintions here will stop that by design and is therefore not "without use." Yes, can be trivially circumvented, but again that applies universally and we understand and agree to a point so why keep arguing that point.

So rather than answer or argue anything above because we both seemingly agree that it's an increasing waste of time sooo:

1. How would HM mitigate trivial attacks against AE with the least amount of gear.

Memory protection?? Virt??

2. If memory protection were added, would it be a trivial skid-grade bypass/circumvention to get an exe dropped and running (w or w/o persistence) in your opinion?

3. Based on the above, what would you call or define a product which stops user-disc and in-memory executable malwares

 

But I don't agree. I don't think that something like Sandboxie is easily circumvented.

Process isolation and EMET.

That depends on the program and the implementation. If ASLR is implemented the way it's meant to be along with DEP and the other mitigations of EMET it would not be trivial to get an exploit. If the program makes use of other techniques like /gs it makes things more difficult. Properly implemented ASLR + DEP definitely raises the bar.

Well no single product does this. You would need isolation i.e.: a sandbox of some type. Sandboxie does that. You also need something like EMET.

I think both Sandboxie and EMET would fall under HIPS. Just as a program that intercepts calls would be a HIPS. Just as a Firewall is a HIPS. Not like an AV or a heuristics, which are HIDS.

 

Brandicandi gets pedantic for a moment...

The definition of HIPS according to wikipedia:

Sandboxie is a sandbox. It doesn't do any kind of monitoring or analyzing. It just keeps everything inside the sandbox separate from the c: drive. So sandboxie doesn't meet the definition of HIPS. Sandboxes are their own thing. Again according to wikipedia:

 

An application sandbox like an HIPS or behavioral blocker has to set hooks (ranging from winevent, message, global descriptor table, services hooks) to intercept the actions of the sandboxed application and redirect it to its virtual environment. So they do monitor system actions, no matter what Wiki says.

Disk virtualisation programs often only redirect harddisk access to a virtual (sandboxed) environment,

 

Thanks for your reply. Think it helps a lot.

Isolation is the key to security, IMO, too. Ultimately, you can't leak what doesn't exist at the vuln/lacks access.

@ SB, haha. Great gear. Yeah, bypasses of a true sense would be generally far from trivial considering Tzuk's patches. But it's also rather robust as a "sandbox" considering its evolution and also still does not hit hard against in-session action as I mentioned to STV0726; it isn't designed too. I bet your generic payload could actually do some damage here if using metasploit Fox. Also fall to ip abuse, RDP and inf exploits. Why I would consider it trivial if also considering memory exploits a trivial AE "bypass."

But of no matter. Think we are icing the cake at this point.

 

No worries, mate. I'm in Pacific Time Zone, so was quite tired myself when I posted that.

Damn...and now it's 5am again

 

Oh for Pete's sake, guys. Hungry Man's basic argument about AEs is sensible. I don't necessarily agree with his terminology about it, meaning "pseudo-security" and such. By that mode of thinking, it seems to me, anything that could be easily bypassed by design, or in other words anything that's simply not all-encompassing in its scope of protection, would be named pseudo-security. AE is not intended to automagically stop all malware, and certainly is not meant to prevent malware attacks that only live in RAM. AE does work rather like as promised against the attacks it is actually intended against, which is the traditional form of malware attack. That security is quite real and is in no way pseudo-anything. I might agree and call AEs pseudo-security if their authors claimed that they prevent malware in general, or even prevent all malicious code from executing, instead of just preventing malicious executables present in the file system from executing. Me, I'd rather blame the user of an AE about possibly having a false sense of security from not understanding how the technology of malware attacks and AEs works.

Personally, if some easily used and simple form of protection or defensive action - especially if it's free as in beer - prevents even only just one specific style of attack that is good enough to be used in the real world in real attacks, I'm all for it, but folks still need to understand what the limitations of said protection are.

And now to my daily dose of nit-picking.

Firstly, Applocker is not "bypassed by calls like LoadLibraryEx", actually. Applocker blocks DLL loading by such calls just fine. Unless, there's a LOAD_IGNORE_CODE_AUTHZ_LEVEL or SANDBOX_INERT flag passed to the LoadLibraryEx function by whatever thingamajig is trying to load said library. If such flags aren't in the picture, Applocker works as you'd expect it to, so that's a rather isolated case, rather than Applocker leaking all LoadLibraryEx calls. And also, "feature, not a bug", but that's MS for you, right. And fortunately, KB2532445 hotfix... uh... hotfixes said issue, as far as my testing goes.

Secondly, this whole "on Windows it's all pseudo-security" I find tastes very tacky indeed. You can't fault a man for having an opinion, but I do wonder how other commonly used operating systems aren't similarly "all pseudo-security", considering that neither Linux nor OS X have any magic in them that makes it all that different from bad old Winblows. Perhaps that wasn't the point - perhaps the point was that in computers in general it's all always pseudo-security, which would make more sense. But you know, there's always going to be the W word used in such arguments, instead of, I dunno, maybe just stating that computing in general is fraught with insecurity, and neither Windows or other operating systems are free of the problem. Everybody loves to hate on the old Win-devil. One may consider closed source a problem, but again, that's not something unique to Windows, and just because something is open source don't mean spooks can't intentionally insert holes for later use. OSS has code execution vulnerabilities like any software. How many of those vulns were accidents by an honest coder, and how many were rather more intentional "accidents" by someone posing as an honest coder, working on some obscure and boring bug and submitting the fix for it in a patch - with, oops, a difficult-to-detect vulnerability "accidentally" left in? Maybe someone, due to all those many eyes looking at the source, actually discoveres it like weeks or months or years later, but, meantime, that hole has already been used by the guy who put it there and his pals, and they've probably had time to insert 17 new holes, too. It's a race, and guess who doesn't win.