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

    wat0114 Guest

    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: https://www.wilderssecurity.com/showpost.php?p=1805915&postcount=62

     
    Last edited by a moderator: Jan 23, 2011
  2. Sully

    Sully Registered Member

    Joined:
    Dec 23, 2005
    Posts:
    3,719
    The function states
    and the flag parameter of LOAD_IGNORE_CODE_AUTHZ_LEVEL states
    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.
     
  3. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    I hope it's OK to reply? :D

    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. ;)
     
  4. wat0114

    wat0114 Guest

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

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    By the way, one other way to prevent exploits - Use Chromium* the way I do. :D

    * 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. :D
     
  6. Didier Stevens

    Didier Stevens Security Researcher

    Joined:
    Nov 19, 2010
    Posts:
    68
  7. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
  8. katio

    katio Guest

    Many thanks for sharing your findings!

    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 https://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.
     
  9. m00nbl00d

    m00nbl00d Registered Member

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

    safeguy Registered Member

    Joined:
    Jun 14, 2010
    Posts:
    1,797
    @Didier Stevens

    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?
     
  11. katio

    katio Guest

    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:
    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.
    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.
     
  12. Joeythedude

    Joeythedude Registered Member

    Joined:
    Apr 19, 2007
    Posts:
    519
    I think this is a good point ( from the OP's Blog )

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

    katio Guest

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

    Sully Registered Member

    Joined:
    Dec 23, 2005
    Posts:
    3,719
    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.
     
  15. katio

    katio Guest

    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. :mad:
     
  16. Didier Stevens

    Didier Stevens Security Researcher

    Joined:
    Nov 19, 2010
    Posts:
    68
    No, ASLR has no impact on the execution of code inside DLLs.

    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.
     
  17. Didier Stevens

    Didier Stevens Security Researcher

    Joined:
    Nov 19, 2010
    Posts:
    68
    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).
     
  18. Didier Stevens

    Didier Stevens Security Researcher

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

    wat0114 Guest

    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 :)
     
  20. MrBrian

    MrBrian Registered Member

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

    safeguy Registered Member

    Joined:
    Jun 14, 2010
    Posts:
    1,797
    @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.
     
  22. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
    I'm not sure, but a DLL doesn't necessarily have the extension .DLL.
     
  23. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
    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
    Update: I just noticed that the comment by cptanon at Didier's blog entry also mentions SaferComputeTokenFromLevel.
     
    Last edited: Jan 24, 2011
  24. katio

    katio Guest

    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.

    Comodo version 5 doesn't intercept dlls anymore.
    See here https://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.
     
  25. RichieB2B

    RichieB2B Registered Member

    Joined:
    Jan 25, 2011
    Posts:
    13
    Have you tried Bit9 Parity and McAfee Application Control?

    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.
     
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.