Circumventing SRP and AppLocker by design, with LoadLibraryEx

Discussion in 'other security issues & news' started by Didier Stevens, Jan 22, 2011.

Thread Status:
Not open for further replies.
  1. Didier Stevens

    Didier Stevens Security Researcher

    Joined:
    Nov 19, 2010
    Posts:
    66
    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.
     
  2. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
    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/.
     
  3. Noob

    Noob Registered Member

    Joined:
    Nov 6, 2009
    Posts:
    6,468
    So, theres a workaround for SRP and AppLocker? :eek:
    And i though they were kinda bullet proof :)
     
  4. Sully

    Sully Registered Member

    Joined:
    Dec 23, 2005
    Posts:
    3,719
    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.
     
  5. Didier Stevens

    Didier Stevens Security Researcher

    Joined:
    Nov 19, 2010
    Posts:
    66
    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.
     
    Last edited: Jan 23, 2011
  6. Didier Stevens

    Didier Stevens Security Researcher

    Joined:
    Nov 19, 2010
    Posts:
    66
    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.
     
  7. Pedro

    Pedro Registered Member

    Joined:
    Nov 2, 2006
    Posts:
    3,502
    User vs. Windows ... FIGHT!

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

    Didier Stevens Security Researcher

    Joined:
    Nov 19, 2010
    Posts:
    66
    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).
     
  9. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    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
     
  10. safeguy

    safeguy Registered Member

    Joined:
    Jun 14, 2010
    Posts:
    1,718
    I've been thinking about this - to what extent can a DLL harm your PC, relative in comparison to EXE that is more "common"?
     
  11. Didier Stevens

    Didier Stevens Security Researcher

    Joined:
    Nov 19, 2010
    Posts:
    66
    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.
     
  12. Pedro

    Pedro Registered Member

    Joined:
    Nov 2, 2006
    Posts:
    3,502
    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? :D
     
  13. Didier Stevens

    Didier Stevens Security Researcher

    Joined:
    Nov 19, 2010
    Posts:
    66
    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.
     
  14. Didier Stevens

    Didier Stevens Security Researcher

    Joined:
    Nov 19, 2010
    Posts:
    66
    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.
     
  15. AvinashR

    AvinashR Registered Member

    Joined:
    Dec 26, 2009
    Posts:
    2,060
    Location:
    New Delhi Metallo β-Lactamase 1
    What if an IE is running under Low Integrity level?
     
  16. Didier Stevens

    Didier Stevens Security Researcher

    Joined:
    Nov 19, 2010
    Posts:
    66
    As some of you wonder what risk this brings, let me post something from my upcoming blogpost about this:
     
  17. Didier Stevens

    Didier Stevens Security Researcher

    Joined:
    Nov 19, 2010
    Posts:
    66
    That's simple, the DLL runs in the context of the process, thus it also runs with low IL.
     
  18. AvinashR

    AvinashR Registered Member

    Joined:
    Dec 26, 2009
    Posts:
    2,060
    Location:
    New Delhi Metallo β-Lactamase 1
    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 ..
     
  19. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    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.
     
  20. AvinashR

    AvinashR Registered Member

    Joined:
    Dec 26, 2009
    Posts:
    2,060
    Location:
    New Delhi Metallo β-Lactamase 1
    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...
     
  21. Didier Stevens

    Didier Stevens Security Researcher

    Joined:
    Nov 19, 2010
    Posts:
    66
    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.
     
  22. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    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.
     
  23. AvinashR

    AvinashR Registered Member

    Joined:
    Dec 26, 2009
    Posts:
    2,060
    Location:
    New Delhi Metallo β-Lactamase 1
    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.
     
  24. Pedro

    Pedro Registered Member

    Joined:
    Nov 2, 2006
    Posts:
    3,502
    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.
     
  25. AvinashR

    AvinashR Registered Member

    Joined:
    Dec 26, 2009
    Posts:
    2,060
    Location:
    New Delhi Metallo β-Lactamase 1
    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...
     
Loading...
Thread Status:
Not open for further replies.