Raising The White Flag: Bypassing Application White Listing

From hxxp://blog.c22.cc/2012/01/28/shmoocon-2012-raising-the-white-flag/ :

 

I see no details on Applocker, the only interesting one.

 

I don't see anything on classic HIPS used as whitelisting enforcement either.

 

I've left a comment asking for details on AppLocker.

We've already heard of bypassing Whitelists before though. It's not bad as a backup I suppose but I'd rather leave it to servers (no human element to mess it up.)

 

This article is disappointing. It looks like it is really notes from a shmoocon presentation. Not any details at all. Hopefully someone will write up a real document soon.

I already knew that application whitelists are not 100%, but was excited to see some current real world examples. I cringe every time I see that stupid PCMatic.com commercial that says "with SuperShield you'll never get another virus again." (SuperShield is their app whitelist).

 

I agree, it's complete garbage.

 

I already ditched AppLocker.

 

LOL!

 

I wouldn't worry your system having your highly tweaked classical HIPS being breached. Code injection techniques which relied on such API calls like Open Process, VirtualAllocEx, WriteProcessMemory and CreateRemoteThread are being monitored by Classical HIPS. Even better if your HIPS can prevent a trusted process(being leveraged by a shellcode) from reading the virtual memory of other trusted processes. In that way very advanced memory malware(dll loaded from memory or shellcodised backdoors) that are used in targeted attacks will be thwarted. Even the return command shell spawned by PDF exploits or browser-side exploits can't delete, modify or upload your files if your HIPS prevent it from reading and modifying your files or personal data, i.e. if a command shell can return first as it is stopped by your firewall as in the case of the former. Javascript malwares and almost all of browser exploits is a no go because of your NoScript, Privoxy or Proxo on your Sandboxed browser devoid of other plugins.

 

I'm not worried about my system. I take issue with that articles headline, describing whitelisting as easily bypassed. Maybe it is if you rely solely on some vendors whitelisting tools. I haven't used any of the apps they named, but if the description I'm reading of Bit9 is typical, I can see why. IMO, these tools are nothing more than AVs that work in reverse. Same flawed ideas used by AVs. Instead of keeping tract of all that's wrong, they try to keep tract of all that's right. Equally impossible. Like AVs, it makes the user/app dependent on a vendors database and has all of the security issues that come with it. Is their server secure? Is the communication between the app and their server secure? Is the database complete and up to date (never). Who checked all of these whiteliseted apps, if anyone?

Whitelisting and default-deny used to be synonymous terms, but that no longer seems to be the case. There's a huge difference between whitelisting the known good apps on your system and trying to keep tract of all of the good apps in existence. That article uses the weakest form of whitelisting, then condemns the entire whitelisting concept when the tested apps don't do it all for you. AFAIC, a whitelist should only include the apps on your system based on what you want to allow. Anything beyond that takes you back to the same problems whitelisting and default-deny were intended to avoid.

 

That article is pure, unadulterated B.S.

 

Anymore, it seems that we can find articles, blogs, white papers, etc that claim and attempt to prove just about anything, no matter how ridiculous it might be.

 

https://www.foregroundsecurity.com/...flag-bypassing-application-white-listing.html

Understand that this "Article" isn't exactly an article. I'm pretty sure it was just based on or note for their presentation.

 

Ah, there's all the nice details. Thanks.

 

Four or five years ago, there was a thread on that topic that became very heated. Finally, we all declared a truce when I pointed out that everyone had her/his own idea of what "whitelisting" is, and that the discussion was going nowhere. Indeed, just search for that topic and you will see what I mean. The term "whitelisting" has become a catch-all term and needs to be defined before any meaningful discussion can take place within the context of that particular definition.

This is the simplest form of whitelisting (and most effective, IMO). This was the way it was set up in the pioneering applications, such as Process Guard, Abtrusion Protector, FreezeX (later Anti-Executable), SSM, and a few others.

____________________________________________________________________________________________________​

The articles cited in this thread seem to be directed at at organizations, since they mention "companies," "agencies." "users vs admins," etc.

However, a couple of the exploits caught my attention. One was,

Well, I tried renaming from both a Command Prompt, and from within Windows. and that can't happen on my system:





I even tried copying over the file, and the same thing:



Now, regarding the other bypasses listed: I confess to having become rather selfish in the past year or so, in that I no longer find it useful to advise others about their own security. The principal reason is that I see most intrusions as being problems with the user. I can not know from a distance on a forum what the user's expertise is, nor what are the user's computing habits, etc. It's an excercise in futility.

Therefore, I look at these "bypasses," and the first criteria I apply is, How likely am I to encounter such a thing? For example, one of the Didier Stevens bypasses requires me to open a boobytrapped MSOffice document. (One in the past was PowerPoint, which I don't have.) Under what conditions would I be tricked into opening such a document?

I mention this because probably each person who would be interested enough in this topic probably can apply the same criteria (risk assessment) and conclude that you are not likely to encounter such stuff.

(I'm not even considering the JAVA, FLASH, PDF exploits mentioned, which are easy enough to protect against anyway with a simple whitelisting protection mentioned above. It's when some global white list is employed that these exploits can bypass that protection, as noone_particular has alluded to.)

Which brings me back to Organizations, where an entirely different set of criteria come into play. I wouldn't want to be a System Administrator these days!


----
rich

 

Quite true, just like the term HIPS which can be almost any kind of application now. Sometimes I think this definition stretching is deliberate in order to make inferior concepts/applications look more powerful than they really are and confuse the potential users.

Like many solutions, the simplest solutions are often the best. One of the selling points of the original HIPS was their ability to provide strong protection without being dependent on continual updating from the vendor. They were/are able to stand on their own, unlike whitelisting apps that depend on the vendors databases. IMO, whitelisting software severely weakens a very strong defensive policy for the purpose of making it continually dependent on the vendor, just like AVs. In the end, they are very similar to AVs and have all the same problems, incomplete and outdated lists, dependence on anothers servers, trusting that those servers are secure since they are now part of your attack surface, needing a secure connection between them, etc. I would still like to know who is verifying all those known good apps or if they're just taking the vendors word for it. With these "whitelisting" apps, the white flag should be raised. They've adopted every characteristic that made AVs increasingly ineffective.

Good grief no! Taking care of PCs for individuals is bad enough.

 

completely agree

 

hi

As sais by Rmus, old topic discussed many times on this board.
In a recent one, i've linked a SANS's paper which is a kind of sumarize of attacks against white listing defense:
http://www.sans.org/reading_room/wh...ication-whitelisting-panacea-propaganda_33599

I see nothing new under the sun for these recent tests:
-using Microsoft binder (iexpress) is known by any script kiddie,
-using privilege escalation (get SYSTEM account or privilege) is also known and documeneted, especially considereing that all MST files are withlisted by default, but could be used againt the system (CMD is Rich of various harful commands!),
-using client/server side attacks is not serious (as demonstrated by my old tests vs HIPS or KAV) because there is no security software that can circumscribe them all!
ETC...........
I've personally used white list defense in the past in 2004/2005 with a combo of system expert HIPS (SSM) and a whitelisting HIPS (Abtrusion Protector) with a high level of HOST security: that which is not blocked by Abtrusion is detected by SSM.
Insecurity is necessary to improve security, and like any other defense strategy, whitelisting has ist own flaws...but less numerous than any blacklist defense!

Rgds

 

Here's a nice demo that can bypass both blacklisting and whitelisting security layers even a tightly configured classical HIPS...

shellcodised backdoors (fratus or parsifal) running entirely in memory of a trusted process like internet explorer for e.g...

http://benjamin.caillat.free.fr/ressources/backdoors/videos_en/attack_presentation.avi

the white paper... http://www.blackhat.com/presentatio...t-Europe-09-Caillat-Wishmaster-whitepaper.pdf

Alternative to this method is the VNC and meterpreter shells(dlls running entirely from memory) from Metasploit. Since those dlls are not written to disk even if Classical HIPS or AE2 is configured to block loading of non-whitelisted dlls, those will not be blocked.

 

In another topic (probably that XP one) this is what I was referring to. Exploits don't have to touch down and drop payloads - it's just what they do because that's quick and easy and no one actually uses whitelisting.

If everyone were to move to whitelisting instead of a payload we'd just have rogue trusted processes.

Thank you for the whitepaper.

EDIT: I would maybe suggest merging the two active topics as they're both about AE.

 

I've been doing it for the last 7 years. It hasn't been all bad. But my users are good at doing their job instead of screwing around on the internet all day.