What Kind of Malware Can Bypass Anti-Exes?

Memory only malware aside, malware has to execute first in order to infect. If it can't execute, it can't infect, as the saying goes. So why would you need a full blown HIPS?

 

Memory Guard/BOclean is still built into CIS, I believe. Certainly has some sort of buffer overflow protection.

AE bypass. RAM, yes. Policy bypass eg "allow signed exe" (see Flame exploit or even ransomwares). Also script attacks within the browser to hi-jack, cookie grab, and password steal. While not persistent in itself, the damage could very well be. Attacks on the router/network which would be outside the local AE's policy, yet your system data would still be deeply affected.

Trojan: as STV hints, the entire purpose is to get you to drop your uber-AV draw bridge and welcome the attacker in with open arms. If you get SE hackers getting you to escalate privs, then only an AV that realises otherwise will save you.

OTOH, some HIPS show what is being loaded or behavioral. If not on my exe whitelist--I'm suspect as hell. Then again, that's an AV/Hash verification component, IMO. When your new application is asking for keylog hooks etc--may also raise a red flag for some.

A strong ae hips IMO is the closest singular thing to full protection. Mind you, the good ones have many components, so beginning to get outside the scope of this thread. Semantics, sure. Cheating, perhaps.

 

Because there are many, different threats... An HIPS tells you WHAT is happening in your system, Where it's happening, which processes, applications, DLLs, exes, registry keys... are involved. You have the full control of your system

 

But that's why some users don't want that. Some want quiet, unobtrusive ones, that can work

 

...and yet if you don't let it execute in the first place then everything else is irrelevant. That's why SRP and Applocker are so effective.

 

Except for RAM attacks apparently...

 

I'm always interested in the initial point of entry, aka, the attack vector. That is, what has to happen to trigger the exploit?

For me, the first consideration in looking at exploits in the wild is to do a risk assessment, something that I was taught many years ago.

So, the first question I ask myself is, What is the likelihood that I would encounter such an exploit?

In looking at web-based exploits in the wild over many years, the first thing I notice is that none of the URLs are those that I would knowingly frequent.

Second, if I did through redirection, the triggering mechanism would have no effect on my system due to the fact that it either used javascript or a plugin, both of which are white listed per site on my system.

In every case, in order to see how an exploit worked, I had to enable some function.

Other attack vectors require clicking on links to update something, or opening an email attachment/document, none of which I consider a threat here.

And so, none of these exploits would ever have a chance to be snagged by a security product in place here, since nothing triggered them to start. In other words, proper security policies and procedures have been a good front line protection.

Looking at the attacks that load into memory, I've seen one POC that required opening an Excel document, and reference to one attack in the wild that exploited a Java vulnerability triggered by code in an advertising banner on a news site. So, another ho-hum.

Speaking for myself, of course. Each person has to do her/his own risk assessment.

I realize I'm in the minority, for it seems to be more interesting to speculate on what exploits do once permitted to install and do their dirty work (Flame is a good example), rather than assessing the risk that the exploit could run in the first place.

But that appears to be the way it is!


----
rich

 

Yes, JS, Java, and Flash. Plugin/extension manipulation. Look at plugins like Click and Clean. Very deep hooks for an "addon."

Caveat: less functions--more safety, but less functionality.

Java seems unnecessary these days. And flash click to play is less annoying, so works out well with a very light whitelist. So with you there. JS though? With today's web workflows, I feel you are breaking a lot or opening your whitelist up to the point of lowered protection (see Gawker, NYTimes JS attacks)

While you will really cover BO-slide, xss, drive-by etc, I believe those could also be mitigated in other ways. Chrome does a good job of stopping such problems out of the box. Most anti-Chrome technology would need Flash running which we corrected above.

But I agree. Full court press at the browser will mitigate a lot of the RAM problems and more. Other than trojans, where a lot of non-directed attacks originate, a hacker would have an extremely hard time. But then again, an AE which also included memory guards would perhaps offer similar protection and ease of use.

I'm just glad Google closed up all its G-Images (aka Mos Eisley) problems (redirect to malware packs). On the otherhand, lost a good free source for fresh nasties to test

 

Nice summary, Sordid. However,

I think one needs to be careful in evaluating from a distance. One can't know what someone else's computing habits/experiences are without first hand contact with the person.

For example, Java. My insurance company uses a custom java applet for its contact page, so I enable Java when using that contact page. Therefore, Java is necessary -- for me.


----
rich

 

I might not be understanding you 100% correctly, but are you implying/suggesting that the current state of RAM attacks seem to be such that they are not that threatening, or perhaps...not as dangerous as some of the other users here are predicting they can be?

 

I hope I'm not getting it wrong, but I believe Rmus means that, even though these kind of malware won't get to the disk, and therefore anti-executables can't do anything about it, something will still need to trigger the malware. This can be a vunerability in some PDF reader, plugin (as Rmus mentioned), an infection that comes through an hijacked advertising network (as Rmus also mentioned), etc. The usual stuff - it just won't run on disk. But, if you can stop the exploits, by using mitigation techniques, etc... block ads, then it doesn't really matter whether or not it executes on disk.

And to the millions of Janes and Joes out there, it doesn't really matter which type of attack is - most are simply unaware of what they can do to protect themselves, and therefore any type of attack would work on them, if the conditions are met.

Actually, Jane and Joe is a very good example, IMHO. Even if they visit a website that triggers an exploits, through a malicious ad, if the ad is blocked then no harm happens. Even if the ad is allowed, it may lead to an exploit taking advantage of a vulnerability in an older Flash version, and the user is already running the latest version, and therefore the infection won't happen, because the exploit won't work. There are quite a few variables, aren't there?

I suppose it all depends on whether or not all conditions are favourable for the infection to happen, regardless of being a disk infection or otherwise.

 

At the moment, with Win7 Chrome runs its plug-ins in Untrusted mode and the renderer tabs in LOW rights. When you implement the SPR/Applocker fix they all run in AppContainer.

So most obvious entry points (javascript, PDF, Flash) are put away in well contained environment. Add EMET to the bunch and it is very unlikely an attack vector (first point of entry) would succeed in changing program logic through a memory overflow exploit. Win7 has some counter measures build in, which in conjunction with EMET are very effective.

There is no such thing as a 100% protection, but current technology is much safer than for instance with the introduction of XP (allthough DEP was a important first hardening step at the time).

I would NOT rely on OS only protection (multiple deny execute precautions and rights containment/elevation protection), when it was not safe enough to my standards (for reference in early XP time I ran GesWall or DefenseWall with SensiveGuard and an AV)

Regards Kees

 

Yes -- I was speaking only for myself.

I certainly wouldn't want others to accept that premise without doing their own risk assessment to determine the likelihood that such an exploit could be triggered on their system.

"predicting" and "can be" are not (normally) in my vocabulary.

Speaking only for myself, it serves no purpose to engage in speculations. It just increases fears and doubts.

Now, if someone feels strongly that malware attacks in memory are a coming common occurence, and that her/his defences are not adequate, then for sure that person can acquire the protection needed to prevent the intrusion, resulting in a peaceful state of mind.

----
rich

 

In case it's somehow unclear... every exploit starts off in RAM. So if anyone is saying that "RAM attacks" are uncommon they're very confused as to how programs work. I haven't really been reading though so perhaps I'm misinterpreting.

Anyways, AE basically attacks a pattern we see in malware. It's effective purely because hackers don't care to bypass it. And by "bypass" I mean keep doing exactly what they're doing with minimal extra effort because, again, all exploits start by controlling a processes virtual address space and only after that do they ever move to the disk. If an AE somehow prevented attacking from RAM (this isn't possible without detection ie: boclean/memorywall or a more convoluted HIPS) it would be worthwhile because that's a step that hackers rely on, it's just attacking something that makes their lives a bit easier.

And an AE is a HIPS. Host-based Intrusion Prevention System. Just like a Firewall is. IDK how that term somehow got adopted to mean "program that pops up a thousand times when you start your browser" but just so that it's clear. So instead of "HIPS based AE", which makes very little sense, I think people are trying to say "Pop up based AE." Because in the end it's literally all a matter of intercepting specific calls, the only difference being that a popup hips... pops up.

 

Also with Chrome for instance one could use M00nbl00d trick

I tried this trick and was called away. So I completely forgot about this deny (execute) of javascript (I set to deny execute javascript and allow scripts from dot.com and dot.nl websites only, thx to Hungryman). I was planning to allow to set it to default (allow all javascript), but when it is so non-intrusive I will keep it on (added allow https://* for javascript just to be sure).

Picture speaks for itself.

 

I assume people are referring to those exploits that remain in memory and do not write to disk. Attention to that started a year or so ago around here with the POC devised by Didier Stevens.

Another term that causes confusion is" White Listing." Unless it is specifically defined in a discussion, it can mean different things to people.

----
rich

 

HIPS is more of a marketing term than anything else. It's used to describe several types of software, some of which have nothing in common but the name. Apps like SSM predated the term but here they're referred to as classic HIPS. Firewall used to refer to software that controlled internet traffic, not combined security suites. Whitelisting means all kinds of different things. AFAIC, most of the terms, especially the way they're (mis)used here, have become nearly meaningless to the point of making meaningful comparisons impossible.

 

First off, yes, by "RAM attack" I really meant "RAM-only" or more specifically "not relying on disk writing access."

Second, I completely agree about the HIPS term being often misused.

As for my own personal risk level, it's low, even if I scrapped Sandboxie (which fully contains everything anyway)...

AdBlock Plus is a good way to have Firefox blocks ads, which are intrusive AND potentially malicious!

@Kees: You mention/imply SRP/AppLocker being able to contain memory-only attacks if I'm understanding you right. Is that what you meant? It seems contrary to what others are saying.

And an open question to all: Is it possible, and if so how roughly, for Microsoft to eventually improve on Software Restriction Policy and (or at least just) AppLocker to prevent memory-only execution?

 

-1-
No win7 has some enhancements against memory buffer overflow, adding EMET will enhance it even more. This is general memory protection.

-2-
Windows UAC protects higher rights objects/processes from lower right processes. So it draws a border between inter process communication.

-3-
SRP/Applocker does the same on execution level from directories (often allowing admin space and denying user space).

For processes running with medium level integrity, only -1- is a real attack protection on memory level. 2 and 3 just help to prevent these attacks survive re-boot. So your are right what others are saying is true, Sorry for my Dunglish (Dutch English).

 

In case it's somehow unclear, RAM "attacks" are incredibly difficult to distinguish from RAM "intended function". Therefore saying "lol just stop it in RAM" is fairly worthless.

Instead, we make sure that programs capable of running scripts are controlled in what they can do, to limit the downstream consequences, eg

Low integrity
Firewall
EMET
UAC

To get around this restricted rights scenario, the malware author is forced to have code run on its own.

The only thing that the widespread use of anti-executables would change is that malware authors would be forced to try and develop more exploits for them. In my opinion, this is going to be much harder because execution is tightly controlled by the OS. It is a binary event (it runs or it doesn't). This is in stark contrast to something like, say, Chrome's sandbox, which wants to let code run to maximize convenience to the user, but to limit its capabilities so that it can't cause harm.

 

So you DISAGREE with HungryMan's theory, that which states anti-executables don't stop hackers from doing anything critical; they are essentially security through obscurity. Hackers can easily switch to RAM-only attacks and damage your computer/phish you/do other malicious things without having to go through that much more effort. Am I correct?

 

That's exactly my point. I thought that I was clear.

 

Hmm? Aren't DEP, ASLR, etc. all about preventing some of the more common exploits in RAM? The attack may not be recognizable as such, but (as I understand it) the mechanism by which it occurs can often be blocked. Some OSes (OpenBSD, hardened Gentoo Linux, and IIRC Solaris) really go to town with this sort of exploit mitigation.

It's a compromise of sorts, because it often crashes a program rather than allow an exploit to occur; and (IMO) it shouldn't be relied upon solely. But last I checked such methods had a reasonable chance of preventing exploits.

 

DEP enforces data vs code, executable vs not executable. An AE tries to intercept calls such as VirtualAlloc() malloc balh blah etc. To try to intercept calls like that as a "RAM AE" would be really convoluted and likely ineffective.

The point htat I was making and that I guess Melf thought I wasn't is that it's difficult to say "Oh, that VirtualAlloc is malicious but that other one is safe." Without a convoluted system there's simply no way and most AE's just default to user interaction, which is useless.

 

I thought this was your point, which I disagree with.

In regards to your statement about user interaction, for me the point of AE is to default deny things unless I explicitly wanted them to run. This is designed to take the teeth out of any potential exploit. Obviously some user's interaction can not be trusted, but default deny makes it much harder to shoot themselves in the foot.

Your argument has been (I thought) that AE is useless because the exploit is in RAM so can still harm me. My counter to this was to say that in a good security approach anything allowed to run such scripts will be operating in a limited environment, so really can not do anything I care about.