Circumventing SRP and AppLocker by design, with LoadLibraryEx

I think some of you will find this interesting.

While reading up on LoadLibraryEx, I noticed an interesting flag: LOAD_IGNORE_CODE_AUTHZ_LEVEL

From MSDN:

I just did a SRP test to confirm this:

A couple of years ago, I build a spreadsheet that creates a DLL in a temporary folder and then loads it. With the appropriate SRP or AppLocker configuration, this can be prevented (and bypassed again, but that's another story...).

I configured SRP to whitelist DLLs, so my spreadsheet didn't work anymore. Until I used LoadLibraryEx in stead of LoadLibrary like this:

Code:

Private Declare Function LoadLibraryEx Lib "KERNEL32" Alias "LoadLibraryExA" (ByVal strFileName As String, ByVal hFile As Long, ByVal dwFlags As Long) As Long
...
hLibrary = LoadLibraryEx(file, 0, 16)

16 is the value of flag LOAD_IGNORE_CODE_AUTHZ_LEVEL.

Thanks to a feature Microsoft included by design, I can circumvent SRP and load my DLL.

I have to test AppLocker too, but I expect this to work too per the MSDN doc.

 

Thank you for the info . This would seem like bad news if used in a manner similar to the shellcode mentioned at hxxp://skypher.com/index.php/2010/01/11/download-and-loadlibrary-shellcode-released/.

 

So, theres a workaround for SRP and AppLocker?
And i though they were kinda bullet proof

 

Ok, so there is a rather puzzling flag on a LoadLibraryEx function that ignores what exactly? Code_Authz_level is what? How does the dual token in 7 differ from a reduced token that SRP could impose? Does it apply to deny policy, or only basic user? How does the fact that it only applies to the dll and not dependents figure into the equation? Does IL have any bearing on this matter at all?

I haven't yet looked at this function or the flags/values. Seems like a rather stupid mistake to allow such a flag that can circumvent the only real protection the OS has other than the standard rights of a group/user. I guess not too surprising, but still stupid.

Sul.

 

Token creation and assignment is done at process creation time. LoadLibrary(Ex) is used inside an existing process, and makes no new tokens (unless the DLL is explicitly programmed to do so, for example for impersonation). The existing process has already been vetted by SRP/AppLocker.

SRP/AppLocker can be configured with rules that apply to the DLLs (in stead of the EXEs). Using this LOAD_IGNORE_CODE_AUTHZ_LEVEL flag instructs SRP/AppLocker to disregard these rules and authorize the loading of the DLL. You don't need special rights or privileges to use this flag.
DLLs depend on other (system) DLLs, like kernel32.dll. SRP/AppLocker rules are still applied to these dependent DLLs when they need to be loaded (e.g. they are not already loaded) while the depending DLL is loaded.
Integrity Levels are assigned at process creation time, and can't be changed during the process life time.

 

Yes, this shellcode writes to a temporary file, so the only change to make is to use LoadLibraryEx in stead of LoadLibrary, and to push 2 extra arguments on the stack. So it only requires a few extra bytes.

 

User vs. Windows ... FIGHT!

Didier Stevens, thank you for your blog and for continuing to share your findings!

 

You're welcome! As I know there are many SRP/AppLocker users here on this forum, I decided to inform you first before I post on my blog (post is scheduled for tomorrow).

 

Thanks for pointing this situation out, regarding this flag.

Allow me to try and understand something. You make mention that "the existing process has already been vetted by SRP/AppLocker".

You also mention that "LoadLibrary(Ex) is used inside an existing process".

If the process has been vetted/blocked... will the DLL still load?

Then, you say that "SRP/AppLocker can be configured with rules that apply to the DLLs (in stead of the EXEs)". And, then making use of that flag SRP/AppLocker will ignore such rules and allow the DLL to load.

I'm wondering why you chose "instead", and not "as well as EXEs"?

Just trying to learn a bit more, I guess. lol


Regards

 

I've been thinking about this - to what extent can a DLL harm your PC, relative in comparison to EXE that is more "common"?

 

If SRP/AppLocker allows the process to start, then yes, one can use LoadLibraryEx and the DLL will load.

Yeah, "as well" is a better choice. What I wanted to point out is that you can make rules that apply to EXEs and rules that apply to DLLs. And that this flag is for the DLL rules.

 

It was a pleasant surprise to find you posting here, and i hope that you can continue.
Even though i am not able to follow you on everything in your blog, i always take something with me when reading it.
Keep up the good work!

Something has to load it, or ask to load, and that something has to be running ey?

 

There's many malware in the wild that uses a DLL in stead of an EXE. It can be very harmful.

Writing a (malicious) program in the form of a DLL gives you the same possibilities and power as an EXE, with just a few limitations. For example, if you need your program to run under another user than the current user (runas), you'll need to create a new process (EXE), it won't work with a DLL, because you can't change the principal user of the current process. You can use impersonation, but that's not exactly the same.

 

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.

 

What if an IE is running under Low Integrity level?

 

As some of you wonder what risk this brings, let me post something from my upcoming blogpost about this:

 

That's simple, the DLL runs in the context of the process, thus it also runs with low IL.

 

Well every security software have designer hole...whether you take the case of Anti-Virus software, Behavior Blockers, White listing programs or Rollback software.. There is nothing which can make you 100% secured...

Only we can defend our self up to 99% but can not achieve 100% protection ..

 

Duh.

My question had to do with the choice of words for "instead" instead of "as well". That was my only doubt, if there was more into it than what I could understand.

Didier explained it; now, I understand he just tried to make a point.

 

So how much damage it can do..? I guess it would not be as much high as it can do while running with high IL...

 

That's not what I'm saying, you read me wrong, I never wrote about 100% protection.

To make informed decisions about which security software you decide to use, you have to know how it works and what features is has. This LOAD_IGNORE_CODE_AUTHZ_LEVEL feature is something noone mentioned before in the discussions of SRP/AppLocker as a security tool.

 

The damage, or better yet "possible" damage, IMO, would depend on two things: Would the way UAC applies low IL to IE be flawed, the same way Chromium based browsers low IL is, which under certain conditions both parent and children processes run both with medium IL (if using a standard account, otherwise if running an admin. account with no UAC, it would be high IL, of course)? I haven't seen any problems with the IE's low IL. So, in case of an infection, as pointed out, it would inherit the low IL, and the greatest damage would be if you had confidential info on your system which isn't off-limits to, at least, be read by objects with low ILs.

By design, a low IL object cannot write or modify to higher ILs, but it can read from them.

 

Well I haven't took you wrong.. I was just saying that no software or solution can protect you.. And yep, I agree with you that nobody discussed about the above mentioned feature ever while having a words about SRP/AppLocker. I am sure MS will look into this matter.

 

MS already did have a look, when they designed it.
It's documented. That's how the OP found out about it.
It's not a bug, it really is a feature.

 

Yeah I know that its not a bug but a feature.. But it can be used for malicious purposes by highly skilled hackers.

Remember, AutoRun feature? It was also a feature but soon it was compromised by malware authors to infect systems via USB/Removable drives...