Circumventing SRP and AppLocker by design, with LoadLibraryEx

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.

Click to expand...

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

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.

Click to expand...

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.

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

Click to expand...

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.

Click to expand...

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.

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?
[...]

Click to expand...

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.)

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.

Click to expand...

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

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”.

Click to expand...

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.

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.

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.

Click to expand...

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.

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

Click to expand...

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:

safeguy said:

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).

Click to expand...

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?

Click to expand...

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.

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 .

Click to expand...

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:
This has absolutely nothing to do with tokens or integrity level. I'm not sure why you keep bringing that up.

Click to expand...

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.

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.

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).

Click to expand...

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

safeguy said:

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

Click to expand...

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.

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

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

Click to expand...

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).

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 .

Click to expand...

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.

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.

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 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.

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.

Click to expand...

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.

safeguy said:

@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 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.