Circumventing SRP and AppLocker by design, with LoadLibraryEx

Originally Posted by Didier Stevens

Correct. Let's take the example of an Internet Explorer exploit. You visit a web site which hosts such an exploit. This exploit uses a vulnerability to launch shellcode inside IE. This shellcode can then download a malicious DLL and load it with LoadLibraryEx. SRP/AppLocker can't prevent this if the LOAD_IGNORE_CODE_AUTHZ_LEVEL flag is used.

Thank you for this info, Didier. If the user's firewall is setup restrictively with remote ip address w/CIDR masks, the example exploit you quote may not be successful, then?

*EDIT*

Because of the security measures I have in place (yes, I'm happy to say AppLocker is one of them ), in spite of the implied direness of this poc exploit, I am not at all alarmed by it, even though I find it an others similar to it interesting. Ultimately, the postings from renowned Wilders member Rmus influence the way I perceive the current malware/exploit landscape more than anyone else (please, no offense to Didier and other security experts), because he not only discusses them in detail, but he also has a nice way of putting them in proper perspective as well

from: http://www.wilderssecurity.com/showp...5&postcount=62

I've written before that I normally don't pay much attention to POCs, for a couple of reasons.

First, not many make their way into the wild as exploits, especially widely distributed in exploit packs. So, I ususally wait for the exploit to see what is going on.

Second, most exploits download malware executables which are easily blocked.

Until the uninformed, unprotected pool of willing victims of today's exploits dries up, my guess that such a technique as has been demonstrated may be limited to specific targets, where known types of data could potentially be mined. Otherwise, it's just still too easy to add to existing botnets using tried and proven trojan dropper methods.

[Sully]

The function states

Loads the specified module into the address space of the calling process. The specified module may cause other modules to be loaded.

and the flag parameter of LOAD_IGNORE_CODE_AUTHZ_LEVEL states

If this value is used, the system does not check AppLocker rules or apply Software Restriction Policies for the DLL. This action applies only to the DLL being loaded and not to its dependents. This value is recommended for use in setup programs that must run extracted DLLs during installation.

This implies, to me at least, that the process calling this function can disregard any AppLocker/SRP checks. I am used to SRP checks being performed in the CreateProcess() method, where before a process is allowed creation, any SRP checks are made.

So how does this work exactly? If a process is created (whether or not SRP/AppLocker is part of that creation process), and it in turn uses the LoadLibrary function to load a module into memory, and the call to LoadLibrary is using the LOAD_IGNORE_CODE_AUTHZ_LEVEL flag, isn't the dll going to inherit the parents rights?

So to say, if I start this POC process with the reduced rights of a User, which uses the POC dll call with LOAD_IGNORE_CODE_AUTHZ_LEVEL, doesn't the parent process still only have the rights of a User, and therefore due to inheritance the dll, even though it is not checked via SRP (meaning it might be allowed to execute when a rule has said not to), should it not be still reduced rights?

I guess, I am curious how this POC would effect things if the parent process were restricted, or in general how this unique call can get around restrictions.

Sul.

[m00nbl00d]

Originally Posted by wat0114

Thank you for this info, Didier. If the user's firewall is setup restrictively with remote ip address w/CIDR masks, the example exploit you quote may not be successful, then?
[...]

I hope it's OK to reply?

The only way for such to prevent an exploit would be for the exploit to be hosted in a different domain, to where you'd be redirected to. If no connection can be made to the IP, then the exploit which is not hosted in the allow IP(s) cannot harm you. Unless, it's a shared IP. Windows Firewall does not allow to grant/deny access to domains/URLs, only to IPs. (I hate this design, by the way.)

P.S: I just drunk pretty much half of a coffee cup, so bear with me.

Originally Posted by m00nbl00d

I hope it's OK to reply?

The only way for such to prevent an exploit would be for the exploit to be hosted in a different domain, to where you'd be redirected to. If no connection can be made to the IP, then the exploit which is not hosted in the allow IP(s) cannot harm you. Unless, it's a shared IP. Windows Firewall does not allow to grant/deny access to domains/URLs, only to IPs. (I hate this design, by the way.)

P.S: I just drunk pretty much half of a coffee cup, so bear with me.

No problem to reply Yes, I agree with you here. BTW, I'm about to brew another pot of java

[m00nbl00d]

Originally Posted by wat0114

No problem to reply Yes, I agree with you here. BTW, I'm about to brew another pot of java

By the way, one other way to prevent exploits - Use Chromium* the way I do.

* From now on, whenever I refer to Chromium, you know I'm talking any browser based on it, as well.

Or, in fact, also, grabbing back what I previously mentioned, you may set Chromium only to allow connection to given domains, even like *.this_domain.com

It needs to be done via a batch file, for example.

I have it like that for different profiles, specially the one for verifying e-mail. No concerns in clicking links I shouldn't... by mistake... that is.

[Didier Stevens]

Post is up
http://blog.didierstevens.com/2011/0...ker-by-design/

[m00nbl00d]

Originally Posted by Didier Stevens

Post is up
http://blog.didierstevens.com/2011/0...ker-by-design/

Thanks

Many thanks for sharing your findings!

But if you use SRP/AppLocker as a security layer against (skilled) evil haxors, then you have to be aware that there is a large hole in your security layer and that it’s easy to misuse. In that case, you should better look out for another whitelisting security layer without “designer holes”.

Anyone got recommendations for a strong 64bit compatible app and dll whitelisting solution that is designed with security in mind for a change?

Sully:
This has absolutely nothing to do with tokens or integrity level. I'm not sure why you keep bringing that up.

It effectively works exactly the same as the dll loading from mem as discussed here http://www.wilderssecurity.com/showthread.php?t=287054
It's just much easier (note: skilled above is in parenthesis...)

For me, that's it. I'll quit using and promoting Applocker as a "solution". I still wonder why MS missed the opportunity to design and market it as a generic anti-exploit proactive security layer. The basics are there, it would only need some hardening.

[m00nbl00d]

Originally Posted by Didier Stevens

Correct. Let's take the example of an Internet Explorer exploit. You visit a web site which hosts such an exploit. This exploit uses a vulnerability to launch shellcode inside IE. This shellcode can then download a malicious DLL and load it with LoadLibraryEx. SRP/AppLocker can't prevent this if the LOAD_IGNORE_CODE_AUTHZ_LEVEL flag is used.

I forgot to reply to this, which I find it pertinent. Well, I do find it. I don't know about anyone else.

What I find pertinent is for example: an exploit.

OK. How about mitigate the possibility of an exploit? I'm not asking which ways we could achieve such. It's more like a rhetorical question. At least, it is for me.

But, there would be ways people could mitigate such exploits, and who knows kill them 100%, if having the right tools?

It would be interesting to see such mitigation possibilities in your article.

I can think of, at least, 4 ways to mitigate them.

[safeguy]

@Didier Stevens

without “designer holes”

That's pretty imaginative...

But I've got 2 more questions now.

Will forced ASLR for all executables and libraries help in any way to mitigate against this - as in is there any relation whatsoever (I don't think so but to confirm is wise).

In a targeted scenario, what will you recommend the Admin do? Have you found any possible alternative that you can share with us?

Originally Posted by m00nbl00d

It would be interesting to see such mitigation possibilities in your article.

If you have a look at his blog you'll see there are several posts about his own HeapLocker and EMET.

OK, my name isn't Didier but I'll answer if you don't mind:

Originally Posted by safeguy

Will forced ASLR for all executables and libraries help in any way to mitigate against this - as in is there any relation whatsoever (I don't think so but to confirm is wise).

Remember we are talking about a staged attack that goes like:
exploit->shellcode->download dll->load dll
Exploit mitigation techniques are the first line of defence. ASLR together with DEP is already very effective against common in the wild exploits. EMET and Heaplocker if you need more.
ASLR makes reliable exploitation more difficult or impossible: instead of running the malicious shellcode the application will just crash and no dll will be loaded.

In a targeted scenario, what will you recommend the Admin do? Have you found any possible alternative that you can share with us?

Don't rely on dll whitelisting as your single layer of defence. Use sandboxing, virtualization, least privilege, the usual suspects... Nothing new really, a targeted attack was always possible against AL/SRP if the shellcode was self-contained.

[Joeythedude]

I think this is a good point ( from the OP's Blog )

"Let it be clear that this only makes it possible to load arbitrary DLLs inside existing processes, it does not allow you to create a new process that SRP/AppLocker wouldn’t allow."

If I understand this correctly it means that this POC is "all in memory" , and that no code is actually permanently written to disk .

So the damage done will 1) depend on the Integrity Level of the exploited process and 2) what other factors such as LUA / AV's etc are on the the target PC .

Originally Posted by Joeythedude

If I understand this correctly it means that this POC is "all in memory" , and that no code is actually permanently written to disk .

So the damage done will 1) depend on the Integrity Level of the exploited process and 2) what other factors such as LUA / AV's etc are on the the target PC .

The dll from memory POC from the other thread is RAM only.
The one we are dealing with here first writes a dll to disk, only the "loader" is memory only (i.e. the shellcode). Effectively this means if the exploit isn't triggered again next time you start up the program (open a certain file/website) nothing will happen if the attacker hasn't installed a backdoor (like dropping a malicious payload into usual Autostart locations)

Of course when you use an exe-whitelist that's a bit tricky. With an adversary model of "highly skilled haxxor" attacking a high value target we'd probably deal with a staged attack that after successfully loading the dll triggers a local priv escalation to install a rootkit.

AV: Unlike that previous exploit this time AVs can inspect and blacklist the malicious dll. Also forensics is easier if no further steps are taken to "clean up".

LUA/IL: Nothing new here. Applies the same as to the ordinary exe droppers.

[Sully]

Originally Posted by katio

Sully:
This has absolutely nothing to do with tokens or integrity level. I'm not sure why you keep bringing that up.

Admittedly this isn't the sort of thing I normally delve into, injections and exploits etc. But I keep bringing it up due to the wording that a process calls this function, and I want to know if the process is already reduced, can such an action do more with the dll methods that are loaded "without srp checks" than the parent process had.

The reasoning is simple, if the parent process that uses the LoadLibrary function is restricted, wouldn't also the the actions of the loaded methods also be restricted? As far as integrity levels, again I wonder how the IL of the parent calling the LoadLibrary functions would influence what the loaded methods from the unchecked dll would do.

I could be that I need to examine what this is really talking about in an exploit context, but all the dll calls I have used are subject to the parent process rights. If a restricted process calls a function that needs higher rights, then it fails.

Sul.

Of course the loaded dll inherits all permissions and restrictions of its parent program.
If it fails or not depends on how clever the attacker writes the dll. Reminds us of the admin vs lua malware.

An attacker using a dll loading exploit instead of the plain old exe likely knows better than to make too many assumptions about his target or assumes the "worst", a heavily locked down environment. "Good" for him that apart from such design holes Windows also comes with regular month old unpatched fully disclosured privilege escalations.

[Didier Stevens]

Originally Posted by safeguy

Will forced ASLR for all executables and libraries help in any way to mitigate against this - as in is there any relation whatsoever (I don't think so but to confirm is wise).

No, ASLR has no impact on the execution of code inside DLLs.

Originally Posted by safeguy

In a targeted scenario, what will you recommend the Admin do? Have you found any possible alternative that you can share with us?

Unfortunately no, otherwise I would have mentioned it. Maybe an admin can reinforce the other security layers he has implemented, but that has no direct impact on SRP/AppLocker.
I will get in touch with Microsoft about this, to see if they have a (hidden) switch to disable this. I hope my new Microsoft MVP Consumer Security status opens some doors ;-)

If nothing can be done, I've a mitigation technique, but it's not something I like: patch/hook LdrLoadDll (that's the ntdll function that LoadLibrary and LoadLibraryEx call) to filter out this flag.

[Didier Stevens]

Originally Posted by m00nbl00d

It would be interesting to see such mitigation possibilities in your article.

I can think of, at least, 4 ways to mitigate them.

I've several posts and tools for mitigation in a layered security context. But I don't talk about mitigation at the SRP/AppLocker layer, simply because I don't have any mitigating steps for this layer (unfortunately).

[Didier Stevens]

Originally Posted by Joeythedude

So the damage done will 1) depend on the Integrity Level of the exploited process and 2) what other factors such as LUA / AV's etc are on the the target PC .

I've seen "damage" mentioned here a couple of times, more specifically in a technical context: what are the permanent changes made to my machine? This technical aspect is easy to deal with: use a backup/restore procedure so you can undo any permanent change.

I would recommend you judge "damage" in another way: what assets do you have on your machine, and what is the cost of losing these assets or having them stolen? That is something I can't answer for you, you have to judge what these assets are worth to you, what they are worth to an attacker, and what's the cost of replacing them when they get lost.

Some example of assets: credit card numbers, pictures, CPU time, disk space, ...

Originally Posted by Didier Stevens

This technical aspect is easy to deal with: use a backup/restore procedure so you can undo any permanent change.

Absolutely I agree with you on this, Didier. BTW, I hope you do have some positive influence on the folks at MS in improving their built-in security mechanisms. Good luck

[MrBrian]

For those who are disturbed about this news, I wrote a guide on using Comodo Internet Security v4.x as an anti-executable. One could use it instead of, or in conjunction with, SRP/AppLocker. Disclosure: I personally use AppLocker only, and not Comodo Internet Security.

[safeguy]

@MrBrian

I do use Comodo Defense+ but I'm using it in Clean PC Mode and not as anti-exe (AppLocker/SRP is my primary anti-exe). I believe Comodo in this mode is still able to alert the user when the DLL is written to disk...someone correct me if I'm wrong.

[MrBrian]

Originally Posted by safeguy

@MrBrian

I do use Comodo Defense+ but I'm using it in Clean PC Mode and not as anti-exe (AppLocker/SRP is my primary anti-exe). I believe Comodo in this mode is still able to alert the user when the DLL is written to disk...someone correct me if I'm wrong.

I'm not sure, but a DLL doesn't necessarily have the extension .DLL.

[MrBrian]

To see if there are more APIs that ought to be explored, I did the following Google search: +applocker +function site:msdn.microsoft.com

The following three APIs were found that have the term 'AppLocker' in the description:
1. LoadLibraryEx - the topic of this thread
2. CreateRestrictedToken - the topic of Circumventing SRP and AppLocker by design, with SANDBOX_INERT -> new process
3. SaferComputeTokenFromLevel

SAFER_TOKEN_MAKE_INERT
4 (0x4)

If this flag is set, the system does not check AppLocker rules or apply Software Restriction Policies. For AppLocker, this flag disables checks for all four rule collections: Executable, Windows Installer, Script, and DLL.

Set this flag when creating a setup program that must run extracted DLLs during installation.

Update: I just noticed that the comment by cptanon at Didier's blog entry also mentions SaferComputeTokenFromLevel.

Don't get your hopes up that this will be "fixed". This is not a vulnerability as posted in one of the comments on Didier's blog.
MS answer to malware is MSE/Forefront, to exploits ASLR, DEP, MIC, EMET and new IE9 features. The fact that an enterprise management feature is successfully used by a small crowd of security enthusiasts was mere coincidence and never intended by MS.

Originally Posted by safeguy

@MrBrian

I do use Comodo Defense+ but I'm using it in Clean PC Mode and not as anti-exe (AppLocker/SRP is my primary anti-exe). I believe Comodo in this mode is still able to alert the user when the DLL is written to disk...someone correct me if I'm wrong.

Comodo version 5 doesn't intercept dlls anymore.
See here http://www.wilderssecurity.com/showthread.php?t=284188
I also just confirmed it myself.

I tried AppGuard too. It lacks any kind of fine-grained controls, for example you can only whitelist complete directories and not specific files. And it doesn't handle dlls either.

Next stop is Faronics. Any other anti-execs out there?

On another note I have to redact what I've said earlier (ranting how MS didn't make Applocker more hardened)
Anti-exec is incomplete anyway, there still is the loading from memory dll we talked about earlier which simply can't be fixed easily. While searching for memory only "malware" in the wild I found out that the widely used and script kiddie ready* metasploit toolkit does just that with its "Meterpreter".

* this means we are no longer in the realm of fiction, tin foils, highly skilled hackers, movie plots...
This I believe is a very realistic threat and just because it's not widespread doesn't mean we can ignore it. Widespread would mean highly automated; even lot of bored script kiddies only attack so many targets, few victims will detect anything (given it's not only bypassing SRP/AL/HIPS but also ALL AVs) and even fewer will report their findings so no wonder it stays under the radar.

[RichieB2B]

Originally Posted by katio

Any other anti-execs out there?

Have you tried Bit9 Parity and McAfee Application Control?

Originally Posted by Didier Stevens

If nothing can be done, I've a mitigation technique, but it's not something I like: patch/hook LdrLoadDll (that's the ntdll function that LoadLibrary and LoadLibraryEx call) to filter out this flag.

I'd very much like to see this "feature" configurable with a registry setting. Failing that, if you could post a patched ntdll.dll for Windows 7 that would be great.

For what it's worth: the company I work for sees targeted attacks on a regular basis. The payloads used in these attacks typically are recognized by 10% to 20% of the AV vendors on VirusTotal.