What Kind of Malware Can Bypass Anti-Exes?

Yeah, that's what I'm saying.

One user mentioned editing browser files. I thought that was interesting and it's something I'd thought of already. There are so many things I could do.

 

Let's see if I'm understanding this. You say AEs can be trivially bypassed... but, then you say you won't go this .dll route... Why not? You say if you were a hacker, you'd totally make use of it though.

For the sake of the discussion of this thread, you did say you could trivially bypass an anti-executable. For the sake of it, Windows 7 Ultimate comes with AppLocker, and properly configured, it can be used to also prevent unknown *.dlls.

But, then you also say that *.dll It's a great way to bypass default UAC and any AE that isn't properly configured.

So, which one is it? First, anti-executables are trivially bypassed, and now a *.dll would only work against a weak anti-executable measure?

What are you going to say next? That if I got an additional* tool monitoring specific file system areas for modifications, because AppLocker doesn't, and prevent execution/prompt for an action, then you'd come and say that your "attack" would only work against a system without this kind of anti-execution measures, etc... At the end of the day, your "attack" would only work against a weak anti-execution policy.

* I mean additional, precisely because AppLocker doesn't have that feature; but, it could very well have, or some other anti-executable have it. And, just because mainstream anti-executables may not have it, that doesn't necessarily mean that non-mainstream anti-executables don't exist... And, it doesn't really matter if it's just one package or a bundle; an anti-executable is anti-executable, whether you use one or two anti-executables with different ways of working, but with the same end goal, which is to prevent the execution of unknown files.

So, it's becoming clear it's not that trivial to bypass anti-executables?

 

It doesn't really matter what its main purpose is. COMODO Defense+ is known to be a HIPS, but an user provided a tutorial to turn it into an anti-executable. So, for those using it as an anti-executable, is it a HIPS or an anti-executable?

I don't use Sandboxie to try new software; I use it to minimize the risk of the more dangerous applications, and use it so as an anti-executable, by only allowing what I want to allow. And, no Hungry Man, staying in RAM doesn't count as a bypass... and simply because they're not meant to stop them.

Did you forget the part where I specifically mentioned that it's possible to blind whatever file system and registry areas to any process, including, say, the web browser? So what if you get read access to the browser's configuration file? What are you going to get from there? My cake's recipe? And, if I only give read access to the browser's configuration file(s), then that means the write access has been revoked. So, how are you going to write to it?

 

If my goal as a hacker is to infect as many machines as possible as quickly as possible I don' tsee why I'd bother with an attack that stays in RAM. For managerial purposes it's easier to be able ot mix and match payloads.

If my only goal is to show that an AE provides no real benefit to security and I can take over a machine just as easily with or without it that's the only point I seek to prove.

Boy, I'm starting to regret bringing up the .dll at all lol it's as if people think that the attack somehow hinges on being able ot use it.

Again, it is purely an example. IT is one of a million things a hacker can do to get what they want. I do not need it. It's a cool technique and that's basically it.

IT is, in fact, basically the only feature of AEs that I find redeemable because it's more of a 'sandbox' approach ie: a program only has access to specific dll files.

An dropping a .exe and trying to run it won't work either. That does not mean an AE isn't trivially bypassed. If you think the two are mutually exclusive you are confused.

You mean if AppLocker were more than an AE and included some type of sandbox policy?

Yes, then we would be talking about bypassing a sandbox lol I've covered this. I've stated what an AE is - a program that only allows whitelisted files to execute. You brought up sandboxing stating that we could call it an AE because it can work with an AE component, I clarified that I am referring only to an AE in the base sense of a program that prevents execution of files on the system that aren't on a whitelist.

Again, by your logic you can say that a Firewall is an antiexecutable because it prevents a hacker from dropping a file onto you rsystem and exploiting it.

To make it clear, once more, I am talking about bypassing a system that only allows whitelisted files to execute.

On the contrary I Think it's become far more clear that an antiexecutable approach on its own is useless as you're now talking about adding a sandbox in the mix.

I mean, does anyone here believe that a file in RAM is limited mor ethan a file on the disk? That malware.exe can do more than a compromised firefox.exe ?

The simple answer is that they are all just as capable as the other and an AE doesn't do a thing about this, it dosen't aim to, and therefor it prevents nothing critical in terms of protection.

It's fine for 'legacy' malware just as EAF is. They're pseudo-mitigations, not meant ot raise the cost, only meant to break what's there.

 

You're misunderstanding what I'm saying.

I am not saying Sandboxie is somehow weak because it has an AE component. I am saying that the AE component provides nothing and the real security comes from the sandbox.

 

I must have got it wrong, then. I always thought you were going to manage to get an unknown *.dll or whatever to execute, regardless of the AE policy. Now, that would be one amazing bypass.

I'll reference you to what I said above.

No, not at all. I was talking about monitoring against file modifications, which means different hash values. If the hashes differ, then block/block and alert. No sandboxing, at all.

So, for the sake of the discussion, I'm talking about only allowing what is whitelisted.

The discussion isn't around that, is it? We all know malware can run only in RAM, and that AEs can't stop it. We're discussing about dropping something in the system and execute it, or make it be executed, say a configuration file. I'm still thinking about whitelisting, yes.

 

"AE doesn't do a thing about this, it dosen't aim to"

And therefore, there is no true bypass--or at least as how many would describe it.

& you, as said above, can still rip a Tandy's head off by circumventing a generic AE. But no-one use generic, featureless AE outside of administration and Jmonge. Bypassing or even circumventing modern AE aka HIPS is not remotely as trivial as it closes those areas you'd be easily exploiting (protected reg/dll/memory/scripts).


...and there you have it....

 

That bypass would involve a flaw in the implementation. I'm trying to point out a flaw in the concept.

It would have to check the hash value of every file, which really isn't practical as the performance hit would be massive. It would also have to check them constantly if any of them get loaded into RAM or disallow writing to those files, which would break things.

Sure. And just as malware.exe can write to a config file or a registry entry so can firefox.exe.

If an AE can't stop me from reading and writing to the registry and to arbitrary files I don't think it'll stop me from doing much at all.

I could drop .dll's and hope the user isn't using an AE with a feature like that.

If I packaged in an escalation exploit I could probably use the task scheduler to silently start Firefox as admin on the next reboot with some malicious extension installed perhaps or a homepage that's the same as always but with some JAvascript running.

I can read everything on the system, which provides me with:
1) The ability to exploit further
2) Quite possibly anything I as an attacker would have wanted access to initially anyways

I'm sure you're creative enough to think of what a program running at medium integrity is capable of.

@Sordid

As I've said, call it a bypass or not. The issue here is that the cost of exploit is not raised in any significant way.

As for no one using a generic AE... Applocker?

I don't think it's worth reiterating what a HIPS is.

 

That's where we have to disagree. We can put Sandboxie's AE in the same bunch of any other AE, because it's the same thing. It cannot protect you against RAM malware, because it simply can't.
But, it can and it will stop the execution of anything not allowed to run.

The same happens with all other AEs. They can't prevent malicious code running in a trusted program from writing to a configuration file (I believe you made mentions to it before as well.). So, saying that you can do that, and I got no reasons not to believe it, because I actually do agree with you, and then make the web browser load the configuration file, and get the malicious code run again from RAM (I think this was an example you gave a couple pages behind?), can't be considered a bypass.

That's why I believed you were going to manage to get an unknown *.dll or whatever to execute, even if only whitelisted files could run.

Of course, if I'm controlling these key configuration files/etc., then I can stop it; but that's beside the point.

I'm just against the idea that AEs can be trivially bypassed, when these AEs are not meant to stop what you're saying you can do.

-edit-

This reiterates what I've mentioned a few pages behind. One cannot use an AE alone against current malware attacks, and simply because there are attacks that AEs are not meant to stop, and things they aren't meant to control. Hence a layered security is necessary.

 

Maybe users aren't understanding what execution means. When I get shellcode in memory it's execution. That's why it's called Remote Code Execution.

Yes, it will stop me form getting shell and then dropping a new .exe down and running it. So what?

As I've said you can call it a bypass or you can say it's avoiding it. The only thing that matters is that the AE isn't stopping anything. It doesn't stop anything critical, which is the statement I made that started this.

That would, as you've said, require a hash collision or a flaw in the program itself, which would likely be unique to the program.

What's more important - that an AE can't be bypassed ie: a flaw can't be exploited to do what it tries to stop or that an AE actually increases security in some way?

 

So, now it's avoiding it...

So, I can say that if I make someone download a fake Flash Player using either Internet Explorer/Google Chrome, then I bypassed their sandboxes? Sure, I did. They aren't meant to stop social engineering. The same way AEs aren't meant to stop what you're talking about, hence not being bypassed, but avoid.

You see... you could have made it all much easier if you mentioned the word avoid. Anyone can avoid anything, which is why you can't rely in a single security policy.

Yep, hence not trivially bypassed. It's confusion bypass vs avoid.

If they can be bypassed? I'm sure they can. Simply not trivially. Avoid them? yes. They do offer an increased security, when used together with other security policies. This is everything I've mentioned in some other post.

 

Pretty sure I've said for pages now that you can call it avoiding or bypassing. I do not consider this the same as a socially engineered malware bypassing a sandbox. I don't think there's an apt analogy for this, really. A few points where it differs:
1) The sandboxes in those browsers actually prevents something critical
2) The attacker has to come up with an entirely new method of infection: ie social engineering. They don't craft their Buffer Overflows to actually use the GPU instead of the CPU or some such thing, they move to a new class of bugs entirely. With an AE it's the same exact exploit and virtually the same steps involved in the attack only it all takes plac ein RAM.

An AE attempts to stop unknown files from executing. What I said, the very first comment I believe, is that this is not breaking any critical chain for an attacker. The attacker does not need to execute some .exe they can execute in RAM all they like therefor the program is virtually useless.

The only thing it changes is that instead of writing a startup entry for some .exe you'd write the startup entry for some whitelisted process like Firefox and then compromise it repeatedly. Or you could do a million other things.

edit: And I'm curious about self protection here. I'm wondering how much can be disabled with these programs through registry and file access (like corrupting the files) to allow an actual, by strict definition, bypass.

How? Anything malware.exe can do so can firefox.exe. There's no difference. All the AE does is move you to RAM. A sandbox like Sandboxie doesn't care where the attack is in terms of hardware, it restricts it, there is no benefit except for preventing malware that doesn't take AE into account.

A privilege escalation exploit works just as well in both programs. IT's all exactly the same situation.

 

"As for no one using a generic AE... Applocker?"

I consider it more than generic granted its script and dll protection, but not doing you any easy favour so I'll take it,

You were the one who actually said no-one uses AE, actually repeatedly/ I just have been adjusting the usage back and forth in order to make some vague sense in the context of your shifting arguments. Thus the "generic" and "true AE" usage. That said, I almost agree with you. A basic AE does nothing but stop ordinary installs by users--it can be labeled an admin tool. But a security-minded AE...that would include memory exploit protection.

So yes, you could BO attack Applocker via whitelisted apps. Remember, Applocker prevents ~unauth usage~ but only stands to "help" against malware (as part of a layer def). You also have quite the edge here also. You know exactly what you are exploiting and your limits. So while this aids your points of isolating AE being "security via obscurity," it also allows you a directed attack. One we could easily mitigate with more rounded, modern AE. So why aren't we discussing that instead of fueling this anti-sec dervish of your PoC. Why don't you just tell us your theoretical method and we can poke holes in it. What fun. No coding necessary.

Reiterating HIPS? Not sure. You seemed to be describing Comodo v4.0 D+ on the other page so don't know what you're dealing with anymore--I assure you I know how it works. Let's just say the way you've outlined the definitions and the argument as a whole: the outcome is inevitable.

 

No. It wouldn't. That's like saying Sandboxie is a 'security minded AE.'

I think coding it would be more fun. IT would also force me to look at it.

I'm not on Windows so I can't test AE software to see how I would construct my exact attack. I don't have the time either. That's why I said July 1st at the earliest is when I would start.

edit: And I'm totally all for that. It sounds plenty fun. I just really don't have the time for it.

 

I would -NOT- call AE a "pseudo-mitgation". That's a term Microsoft uses for the mitigation technologies in EMET (yes, like EAF) that are based on speculation/theory on how an attacker in the future MIGHT try to exploit code in a program...but it has not been seen yet in the wild. (Source: Microsoft video on EMET with two of the designers).

AEs like SRP are NOT "pseudo" because they DO in fact block most attacks in the wild today due to how they infect machines with their payloads. Whether or not you are in agreement of the "AEs stop nothing critical/security thru obscurity" notion is irrelevant to the fact that it is not a "pseudo-mitigation".

 

No, it's more like the opposite. It's a technique implemented for *past* malware and it doens't make an effort to actually drive up the cost of exploitation, only brake automated exploits that don't take it into account (it has 0 performance hit anyways.)

I'm fairly sure that's what the EMET Handbook says at least. If it isn't then they're dumb lol

So does EAF.

EAF is a defense against ROP. So any time you see "ASLR Bypass in Wild!" that's where EAF will stop an exploit because it and ASLR stop the same things.

The goal is to purely break exploits not designed for it.

As far as I can see that's the only use of an AE for a user.

 

From your own marketed resources:

http://insanitybit.wordpress.com/20...s-security-tool-that-everyone-should-have-15/

"EMET drives up the cost of exploit, it doesn’t eliminate the threat."

or

"It's like... DEP doesn't drive up exploit costs on its own. Yeah, you need to do some ROP to get around it but that isn't such a big deal and is quite common now. But DEP + ASLR actually does make things more difficult. So I can see an AE kinda playing the role of DEP and a sandbox playing the role of ASLR."

https://www.wilderssecurity.com/showthread.php?t=324598&page=3

Given: EMET includes DEP and ASLR tools.

It's getting to the point where past and proven is now being called into question and being redefined to our argumentative desires: a bit much IMO. This thread has become lost and increasingly more useless than the "weak AE" we discuss. I can only level with gross contradiction and gaming so many times and think that goes for all of us.

End game: HM can jack a computer with an AE that does not protect against memory exploits via a memory exploit.

<shakes head>

 

You're a bit confused. DEP and ASLR absolutely do make things more difficult and I've never said otherwise. What I said is that EAF does not make things more difficult, it's purely for legacy exploits.
http://skypher.com/index.php/2010/11/17/bypassing-eaf/

My post about an AE playing DEP was to enforce the idea that both an AE and DEP are entirley useless on their own. It actually, in my opinion, gives AE too much credit as DEP and ASLR rely on eachother whereas a program like sandboxie absolutely does not rely on its AE component.

Honestly, my goal is to inform. I'm fine with explaining why an AE and a HIPS are two different things. I've just done it a dozen times and it doesn't seem to be sticking. I just think some people put a lot of stock in an AE because they don't understand waht 'execution' means. From a very base level if you think about 'oh it stops malware from executing' it sounds incredibly powerful, the simple issue is that it doesn't do that it just stops a new payload from executing.

The reason I post here (though I'm only around for this topic at this point lol) and the reason I blog is to inform. That's all.

edit: And just FYI pretty much every exploit you'll ever run into is a memory exploit.

Again, for the 1000th time lol, call it a bypass or avoiding I don't care. The point I've made this entire time is that it doesn't stop a hacker from doing anything they need to do.

edit2: This was brought up earlier. This is what MS has to say about pseudomitigations in EMET.

Here they would be referring specifically to EAF and HeapSpray, which are only meant to stop 'popular' techniques malware writers use in automated code, they just trip the malware up but are both easily bypassed (and in EAF's case this is the strict defintion of bypass, I guess you could argue in HeapSpray it isn't? I don't know.)

 

From a results point of view, it doesn't matter if malware or a POC, defeats, bypasses, evades, or circumvents your defenses. The result is the same. The only place it makes any difference is how you block the attack or mitigate what it can do.

As for security vs pseudo-security, that's a pointless word game. AFAIC, every security measure MS put in their system is pseudo-security. All of it has been defeated or bypassed at one time or another, some of it apparently by design.

Hopefully this doesn't require apps (besides Firefox) and Windows components I've stripped out. Then again, if it does, it'll verify the choices I made building this system. No matter what form this takes, I'll be interested to try it on both of my OS, since most everyone thinks my default system is so vulnerable. No matter how it comes out, it should be interesting and hopefully useful at the same time.

 

I would like to summarize the facts of this case, which I don't think even the.... hungriest of men amongst us are disputing:

1) Anti-executables stop unauthorized executables on disk from executing.

2) Anti-executables do not prevent running applications from carrying out the instructions in a script, nor are they intended to.

3) Scripts can be malicious and, unless some restrictions are applied to the rights of the program carrying them out, can do anything that the User can do (without having to save anything to disk).

4) Anti-executables do not prevent Users from installing things intentionally (so-called "social engineering"), nor are they intended to. They protect against unintentional execution.

4) In attacks currently seen in the wild today, the vast majority (easily >90%, probably >99%) attempt to put an executable on your hard drive. This is to ensure persistence, since anything in RAM will vanish upon reset.

5) Anti-executables therefore protect against the vast majority of non social-engineering attacks currently seen in the wild today.

6) Damage can still be done without persistence, although the likelihood of many types of damage is decreased (e.g. you are less likely to have your bank password stolen, but you could easily have your User space files wiped).

7) In a hypothetical future where everybody in the world uses anti-executables, hackers would undoubtedly redouble their efforts to attempt to "do more" from RAM alone. This would increase the rate at which new exploits are discovered in scripting programs (e.g. browser, flash, java) and in the operating system, by some unknown amount that is open to opinion.

I would like to extend on the above and claim that, despite the theoretically increased rate of exploit discovery in scripting programs and the OS:

1) Anti-executables would still prevent persistence as they do today, which is their purpose. Anti-executables would still achieve their purpose.
2) The per-individual consequences of being hit by malware would be reduced overall compared with today, due to the lack of persistence.

A good security approach today or in any hypothetical future should never rely on anti-execution alone. It should also

a) Employ rights management of programs that can run scripts. This includes browsers, document viewers, media players, etc.
b) Protect against social engineering. This could include signature detection, behaviour blocker, link reputation scores, depending on the knowledge level of the user.

 

I believe you totally missed my point. lol I didn't say anything about how the sandboxes protect; I simply mentioned I cannot say they're useless because of something they're not meant to protect the user from. So, from that perspective, I made a reference to social engineering attacks. So, that's how far I wanted to go with my analogy.

The sandboxes aren't designed to prevent/block social engineering attacks. They can't. The same way current AEs aren't designed to protect the user against RAM malware.

There are two things to realize, and those two things are the design/concept and the implementation of that design/concept. One one hand, we have the way anti-executables work, how they were designed to work. Then, there's the actual implementation.

We have anti-executables using steps A, B, C and D to protect the user, and you're saying you can trivially bypass it/avoid it, by attacking F. Well, as it's pretty much clear they don't protect using step F, it's 100% futile to say it can be avoided. Why? Because they can be avoided using F, G, etc, period. You brought nothing new into this discussion. And, anyone relying solely on them is asking for troubles. That's also a given fact, if they happen to face one of such situations.

Yes, we all know about that. No need to keep bringing that into discussion over and over again. lol

Well, why don't you do some testing? Now, if you do that and reveal your findings, it will be far more interesting than saying you can avoid something that doesn't exist.

And, you keep talking about attacks that current AEs aren't meant to protect you from.

Come up with a way to bypass their current way of working (steps A, B, C and D) - implementation flaw - and, I'll pay attention.

It would be far more interesting for you to study how some AEs work, such AppLocker, Faronics, etc., and find implementation flaws and reveal them, rather than discuss about some design limitation. Just some crazy idea I had.

 

~ Removed Comments ~

@Melf,

I agree with most of that. I don't think an AE can reliably stop persistence though. The exploit is given so many rights it seems like it shouldn't be difficult to get persistence.

But, yes, almost everything today drops a new payload, which it tries to execute so AE's are very effective for what we currently see.

@M00n,

Right, but the sandboxes do actually prevent a serious class of attacks whereas an AE only trips up current malware.

Except F is just as easy as A, B, C, D. Therefor the cost of attack hasn't been raised, which has been my point this entire time.

It's strange how people don't seem to get this. F is A, B, C, D... it's the same exact thing but in RAM.

I will later though I doubt I'll change any minds here lol you guys don't seem to be understanding the issue, which is that regardless of whether it's bypassed or avoided it's still useless. I don't measure security against what's currently out there because what's currently out there is aimed at people with old unpatched Java versions running XP.

Right. It' slike if no one used any ROP mitigations and just DEP. Using ROP doesn't really drive up the cost, the attack is the same. DEP isn't meant to stop ROP, but that doesn't make it any less useless. The difference is that an AE is actually less useful than DEP.

I'll probably do that anyways. But the point is that if it only protects against A, B, C, D, but not F, when F is just as effective and just as easy and effectively the same exact thing (RAM vs HDD makes 0 difference) the program isn't exactly effective.

Think about Sandboxie. There is no way to get around the sandbox without social engineering. You can't just move to separate hardware and go throug hsome other method or use some other memory bug. You're trapped in the sandbox. Outside of an actual bug in Sandboxie you're trapped.

Why? Bugs and vulnerabilities in specific software don't actually matter that much. What matters is bugs and vulnerabilities in security measures because solving one of those bugs will solve numerous specific vulnerabilities ie: don't focus on patching buffer overflows when you haven't implemented ASLR yet.

If I found specific vulnerabilties that allowed me to, say, crash the AE and execute my own files... would you rather have that... or would you rather I show that a system running an AE is just as easily owned as a system not running one?

 

please show both on you tube, it would be very interesting

 

I understand your point, HungryMan, and I have come to my own personal conclusion that I more or less agree with you. Because I was using anti-execution (which is an extreme security measure since it has a higher impact on convenience) for the sole purpose of preventing all (not just current) malware (because I genuinely thought it did just that for a long while), I'm considering moving it to a secondary layer and making Sandboxie my primary layer.

@Melf: When you say that anti-execution is a good paired with "rights management", I'm assuming you are simply talking about making sure UAC is on (preferably on "always notify" [but that's another argument thread]) and that the user is preferably running as a non-administrator.

Or are you using other 3rd party stuff paired with anti-execution and non-admin rights that I'm not aware of? You used some pretty fancy words in another prior post to describe stuff I'm 99% sure Windows has built-in but I wasn't sure if you were referring to that or an alternative to Windows tools.

So here it is, my official statement on my flip-flop:

I no longer consider anti-execution technologies such as Software Restriction Policies or AppLocker built into modern Windows to be the single best piece of security one could add to their setup. Furthermore, I have always believed in a layered approach regardless of how experienced the user is, but if one is looking for the single most effective layer to add to any security setup, my new opinion is that the best approach by far is sandboxing and virtualization technology such as Sandboxie. It comes as no surprise, these are also whitelist-based security measures, which do bring about some inconvenience and are often harder for less experienced users to learn to operate, but for intermediate and above users in my opinion it's a no-brainer to implement this.