What Kind of Malware Can Bypass Anti-Exes?

Still one major problem that poses as a deal breaker to all that -

The exploited process is running under a standard/non-admin user. Oops.

Now you have to exploit admin privileges, and that's no easy task. Windows is a LOT heartier than Java, Flash, Firefox, Plugins.

Granted there are plenty of mal-actions you can do without attacking Windows itself...botnets being out of the question. You could try to harvest passwords for example.

 

This here has yet to be defined. Perhaps that would be be up to the OP but the definition of AE seems important. Like Scoobs mentioned early in the thread, there are several third-party products that could fall into that category as well as SRP/Applocker. AppGuard for example could be considered an AE but it also has protections in place to protect the memory and inter-process manipulations. However, NVT ERP does not have all these same protections but is still considered an AE. So, definition seems important.

 

Well...I guess we're mostly talking about the technology of anti-execution (and blocking of other executable type files like DLLs) in general.

A good place to start would be what's built into Windows already... Software Restriction Policy / AppLocker / Application restrictions component in Parental Controls

Any additional functions like what AppGuard has is an advantage that particular program may have not standard to all AEs (at least not to my knowledge.)

 

Being used by very few users home users is pointless. I previously talked about Stuxnet. I could have talked about Flame, which is a very recent event, and also targeting infrastructures that are meant to be properly secured.

If it's so trivial, then why did a state-sponsored malware made them waste lots of resources and money, not to mention some of the world's greatest crypto experts, when all they had to do is create exploits that can bypass anti-executable measures? Wouldn't this have been cheaper and efficient? I mean, social engineering works everywhere.

I never saw mentions that any of these state-sponsored malware attacks bypassed this kind of policy; rather all of them due to insufficient security measures, and in all of them, a proper security policy would have stopped the initial infection (Flame, for instance.).

But, this kind of question is actually pointless in itself. There's no standard for what an AE is, correct? Could I say that if I use Sandboxie, and only allow specific processes to run, that it is an AE? I say I can. And, it also allows me to allow access to specific Registry and File System areas, and give them either read or write access.

In Hungry Man's example, if anyone is using Sandboxie alone, he wouldn't succeed.

 

I'm curious to know what the most popular and most widely trusted Anti-Excutable program (not virtualization/sandbox program) is here among Wilders users outside of those that use Windows' own tools.

It may be AppGuard.

 

Not much of a deal breaker, really. You can still steal or delete data, including passwords and banking credentials, you can still use the system as your personal illegal content storage site or proxy for sending the kind of messages you wouldn't like to admit to sending, you can still be a happy part of the big family that is a botnet. The only thing you can't do is gain system-wide infection and system-wide persistence for infection. Unless you've got the right privilege escalation vulnerability in Windows to use.

I'm all for non-admin, but it's not a deal breaker in this scenario, no.

You could say that, but I believe a vast majority of people who even know what Sandboxie is would disagree with you. I certainly would. It's a light virtualization software, not an anti-executable. Though there may not be a standard set in stone for these things, it's rather obvious that AE is meant to refer to software that has preventing new software in the form of executable files in the file system from executing without permission as its primary, perhaps only, purpose. That's what the name comes from, anti-executable... The primary purpose of Sandboxie certainly is not preventing new software from running, it's actually pretty much the opposite, allowing new software to run while limiting what it can do to the real system. If we went with the definition that allows Sandboxie to be named an AE because it can be used for that kind of purposes, then we'd have to define Windows itself as an AE, even without SRP or AppLocker, because of the Execute File file permission.

 

A lot of long posts lol I'll get back to them later.

 

Good clean up. Yes, indeed. And begs the question really. Seems like our arguments are being gamed by semantics.

So had a biere and sourced the deep contentions.

Hungry Man is correct. But misaligned his PoC. Here's why. Define what a true AE does. Hmm, not much when you broke it down. I think we've named many ways we could legitimately exploit an 1984 AE. It's just too damn weak and specific. As Hungry said: 'tis useless. AE useless? That's the cornerstone of my policy though.

But there's the rub. The definitions of each. Anyone with 3 teeth could circumvent an AE and that's HM's point. An AE is an admin tool to stop users from virtual suicide, not hacks. So how would AE help me the admin/user?? From my evil split personality?? My dog? So on that point AE is garbage for the home, single user and ones with white hat, savvy dogs.

But. Here's where it gets complicated. Who uses "pure AE" outside enterprise. Then again, that's HMs point.

So let's redraw the question: modern AE...like Comodo. Yes, the exact point HM condemned. "HIPish AE". Makes no sense or does it. HIPS is AE-based, IMO. Just the modern iteration garnering that feature creep goodness bolted on. Comodo as an AE is the style of AE you'd use today and want as an example because it is the 1984 AE in addition to plugging all the holes we mentioned earlier. Like BOs, reg flips and file drops to sensitive areas.

So I mod my outlook.

AE pure: useless from the home user. You'd by definition click yes. HM is on point.

HIPS: AE-based--IMO, modern, and is a solid set up because it includes points of empowerment for the user and can even outsource a 3rd party admin/request unknown exe analysis. This is hard to hit and NOT obscure. It would guard against most of the aforementioned "AE" exploits excluding in-function exploits (eg non-persistent browser function vulns).

Bypass the 'modo with a non cert jack or non crap policy PoC exploit and I will take my pants off. Anything else wouldn't surprise me; HM's a smart dude.

 

Here's the thing. Call it a bypass, call it avoiding it, the simple truth is that whatever you call it I'm infecting the computer.

I think a lot of what I see is users depending on an AE, centering their security around it, and believing they're safe from advanced attacks because 'if it can't execute it can't infect.'

 

Then infect Comodo by the same loose "AE" definition if you're going to use "bypass" so loosely.

Fair is fair.

Or bypass a true AE using a true bypass definition.

Otherwise, you're tooting your own horn and not the sentiment of the people disagreeing with you.

Just don't want you to bypass an oldschool AE with a modern exploit and we reply "and....". Your world, HM.

 

It's all a matter of intercepting calls.

Comodo's HIPS component doesn't work on a whitelist. It blocks calls that do anything, so a call to write to a folder would be blocked or prompted (more complicated, it won't intercept every call and different settings will yield different results). That isn't an anti-executable unless you also consider a Firewall an anti-executable in that they'll both long term stop me from executing software. It's more like a sandbox.

An antiexecutable allows only whitelist executable files to run. That's the definition I'm going with - does anyone take issue with this definition?

It enforces this by hooking calls relevant to execution. It does not attempt to sandbox, by any definition (ie: restricting file access, socket, capabilities, etc) whitelisted files, it only attempts to prevent new unknown files from being loaded.

If a 'True' AE is anything else we disagree on what an AE is. My 'bypass' will be for what I consider an AntiExecutable ie: it will work without introducing a payload to the system, which would then be subsequently executed. It will work either entirely within the Firefox process or it will hop between processes.

If you don't consider a bypass, that's fine. If you want to call it simply avoiding the program, go for it. But ask yourself if you should be relying on a program so easily avoided.

Honestly, if I manage to make the POC you should really take it seriously. I am not a hacker. If it takes me a week to write it it'll take someone else 5 minutes.

EDIT: @M00nbl00d

Neither Flame nor Stuxnet were made to bypass an AE. Why would they be? Even in businesses they aren't common and Stuxnet was designed to attack SCADA systems. Flame was created to spy. Could they have easily created a payload that stayed entirely in RAM? Sure.

Seriously, no one cares about AEs. Some businesses actually use them. I doubt most do.

In that case it would include an AE component, yes. I would be forced to stay in RAM. The AE doesn't do anything lol whether I execute a file in the sandbox or stay in my own exploited processes address space I'm just as confined - it's the sandbox that stops me.

And I could, obviously, still do quite a bit from within a sandbox as I've got read access to your entire system.

 

There are a fair number of people here using "true" AE, if SRP and AppLocker fit the definition.

Edit: though an AE method that used checksums might make persistence hard, no? Modifying an executable would change its checksum...

Edit:

I can't really speak about OSX security, I know very little about that OS. But various forms of UNIX have had varieties sandboxing and memory protection for a long time. FreeBSD has had jails since version 4.0 (circa 2000). Solaris has had methods for mitigating buffer overflows since I-don't-know-when. Linux has also had such things for a while (e.g. PaX since 2000), but mostly not incorporated by default.

Not just UNIX either. VMS (upon which the Windows NT kernel is partly based) has been almost entirely immune to buffer overflow vulnerabilities since its inception, IIRC.

 

I would think AppLocker fits the definition. It doesn't restrict programs that are whitelisted in any way, it only stops execution of new files.

edit: and privilege escalation exploits work just fine whether they're conducted by Firefox.exe or malware.exe.

 

Yeah, i'm the other one = NO updates

 

Right. So privilege escalation shouldn't be a problem on either of your machines. Meaning once I compromise Firefox, assuming that the AE is the only defense you're using (and I don't believe it is), I can make use of any of the thousand XP privilege escalation exploits and likely hook the kernel. Once I hook the kernel I'm working at the same level as your AE.

In case it's unknown if Process A wants to confine Process B then Process A needs higher or the same rights as Process B. There is nothing higher than the kernel in terms of software. If we're both at the highest point nothing can reliably control the malware and you're in trouble - or at least it becomes more difficult.

 

Wait, what's this talk of a POC? No POC needed here: memory-only malware can do all kinds of evil stuff, and it will absolutely positively not be stopped by an AE. That's just fact, no new radical theory there. So is the possibility to make the malware persistent on the system without creating any new executable files, there's even very simple ways to do that even if the old way of doing things would be easier still.

An AE is not something anyone should rely on as the first and last line of defense like some digital Maginot Line, but it can be useful, even very useful, no matter whether you're a home or business user. While memory-only malware is something to remember, practically all malware out in the wild today still works by creating executables on disk. And there's also the side that you can use AEs to control what legit software runs, to keep your kids from installing a million games on their system that should be used for serious schoolwork, or you can prevent your employees from same.

P.S. You guys who don't update your operating systems by choice. I guess you've discovered the physically safest way to be remarkably brave in our modern world.

 

AE that control dlls may help to prevent memory attacks

 

That's true jmonge. As anyone who tries my proof of concept will likely have read this topic and hardened against that specific attack I don't think I'll be including it - especially since it sounds like a pain to write and I'm going to be as lazy as possible and get Metasploit to do the work for me.

edit: I think comparing an AE with something like EAF makes sense. EAF is a pseudo-mitigation, it's purely there to create an 'uncommon' state for the program even if it's easily bypassed. An AE does the same thing - it creates a state where malware has to use RAM instead of Disk, both are equally viable for everything malware would want to do, but it's uncommon and therefor provides protection through that.

 

The approach used by AppGuard is based on trusted enclaves, which is a different technology to a pure AE.

http://www.prweb.com/releases/antivirus_software/zero_day_protection/prweb3989004.htm
http://www.freepatentsonline.com/7712143.html

Regards

 

Faronics Anti-Executable [A-E, which I'm running in tandem with Faronics Deep Freeze 7.3, Sandboxie and MSE] does what you mentioned in your post which I'm quoting.

It protects DLLs, although by enabling that feature [disabled by default on new installs], comes at a price and it's that it slows down your PC noticeable. However, that's the price of increasing security on your system at the expense of usability.

I tested this product [Faronics A-E] with DLLs monitoring enabled, against several rootkits [TDSS, ZeroAccess] and Internet worms and, none of them were able to bypass or disable A-E, indeed.
I'm really happy by having purchased some licenses for this product from Faronics.



Carlos

 

That's true.
I've used both [AppGuard and Faronics A-E], and AG protection approach is somewhat different form A-E, which I'm running now on my PCs.


Carlos

 

Zyrtec exactly

 

HungryMan, if your POC doesn't take into account Windows SRP DLL protection then it's a faulty POC since DLL protection is on by default with SRP created.

Or did I misunderstand you?

 

I don't plan on doing anything at all with that DLL trick. It was only one example of what can be done.

If I were a hacker and I wanted to infect as many machines as possible I'd totally make use of it though. It's a great way to bypass default UAC and any AE that isn't properly configured.

 

So in other words what you're saying is with DLL protection ON there's still other ways to get around AE...