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

    katio Guest

    You'll have to admit that LOAD_IGNORE_CODE_AUTHZ_LEVEL, SANDBOX_INERT and SAFER_TOKEN_MAKE_INERT can take some burden off the admins.
    If you have seen the Bit9 demo this is a bit like their "group" feature. Though honestly, I like the Bit9 solution more. It requires more maintenance (like every point upgrade to a software means you need to approve ALL the files again) but at least there are no loopholes in its design. However Applocker comes free with the enterprise versions of Windows.
    Someone should test if Bit9 ignores those flags...

    About the technet blog, these are just "recommendations"
    http://technet.microsoft.com/en-us/library/ee424371(WS.10).aspx

    You can of course disable everything for everyone but in most environment this isn't feasible and not worth the costs.
     
  2. Sadeghi85

    Sadeghi85 Registered Member

    Joined:
    Dec 20, 2009
    Posts:
    747
    That makes sense. :doubt:
     
  3. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    But, somehow, I don't believe any careful administrator would be wishing for something like what happens with SRP and AppLocker.

    Otherwise, what is the point of white-listing what can run, which in its turn denies everything else, if this white-list can be circumvented/avoided/ignored?

    To me, it makes no sense.

    For me, it would be like building some anti-radiation bunker, and somebody decide to create holes all over the place to allow a better air circulation. What would be the point for such bunker, if radiation could still pass through it, via those holes?
     
  4. katio

    katio Guest

    So far we know there is a single hole in the system, VBA macros, and I like everyone else think this needs to be addressed. The other risk is vulnerable applications. But those can be exploited anyway, with or without the "backdoors" we are discussing! You still need to patch your software and keep up-to-date with exploit mitigation techniques no matter if you use an antiexecution layer or not.

    I disagree with your analogy.
    SRP/AL is not a secure bunker, it's more like a metal detector at the entrance and wasn't meant to protect from let's say a rocket attack or someone digging a tunnel from below. It's against employees and strangers walking in through the front door with concealed weapons or coming out with stolen goods. VBA macros are that one window on the ground floor someone left open. Just close that one window, no need to fortify the whole building.
     
  5. Pedro

    Pedro Registered Member

    Joined:
    Nov 2, 2006
    Posts:
    3,502
    You can stop at "wasn't meant to protect".
    A metal detector with no one making sure you go through it. :doubt:
     
    Last edited: Jan 26, 2011
  6. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    I guess the analogy wasn't the most accurate one; a bit too rude, I guess.

    But, imagine a system (Not an Operating System.), where who enters and who's able to perform certain actions needs to be controlled. There's a mechanism that allows to perform such control; but, wait, this mechanism is flawed because there are ways around it, and it were made by design.

    This system's mechanism control role is to control people not to misbehave, like not allowing them the introduction of new people, without authorization. Unfortunately, the control mechanism allows such control to be avoided by design. A bad person is able to enter the system, through a good one, exploiting a weakness in this person, and the bad person compromises the system, and all due to a hole that was stupidly introduced as part of the design.

    Makes any sense o_O Why have a control mechanism to control what happens, if this control mechanism can be avoided, due to its own design?
     
  7. katio

    katio Guest

    There are 3 ways in, one through the detector, one through the window and one through digging a tunnel.
    You demand an application control system should protect against the latter? Why? That's not the threat model AL was designed for, is that really so hard to understand? If you don't like it, don't use it or put up with the limitations it has for your uses.

    m00nbl00d, what you are looking for a MAC system. Windows doesn't have one, it's not an OS you should use in a high security environment. Yes, its design is flawed from the ground up. But that is "by design". Security is always a tradeoff (see Bruce Schneier) and Windows puts usability first, that's what business want and that's where the money is.
    If you don't like it, etc. etc.
     
  8. CloneRanger

    CloneRanger Registered Member

    Joined:
    Jan 4, 2006
    Posts:
    4,979
    @ katio

    Thanks for the facepalm :D I must admit i've been overdosing on info of all kinds lately, not just security/privacy, so much to take in and deal with etc, i guess my eyes glazed over that. Sometimes i think my head is going to explode :D
     
  9. Pedro

    Pedro Registered Member

    Joined:
    Nov 2, 2006
    Posts:
    3,502
    The problem is you don't need the window, there's a way around the metal detector and no one is there to stop you.
    People go through it because it's inconvenient to go around, or it simply doesn't make sense to go around. The guy with the gun however has a reason to go around, if he knows it's plugged in, and turned on.

    BTW, i'm not demanding anything. Just a comment.
     
  10. katio

    katio Guest

    Please elaborate, which -concrete- ways do you have in mind?
     
  11. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    Until Didier Stevens brought to us these flags to go around AppLocker, documented by Microsoft, didn't we believe we had the opposite of this:

    If such situation were never brought to our attention, we would believe that AppLocker would be there to stop it. But, it is not.

    Don't take me wrong, I agree with you that Windows is not for high end security, and this all situation clearly shows it: Microsoft introduced an improved SRP mechanism; but then again with 3 flaws, allowing it to be completely ignored. This totally kills the purpose of having such SRP/AppLocker, in the first place.

    I wonder how many administrators are even aware of such situation, and they will start now to be, I don't think they will stick with the "it's by design" excuse.

    As user wat0114 mentioned, Microsoft clearly had security in mind, and they even mention fighting/preventing malware in the article pointed by wat0114.

    Microsoft, simply putting it, has made life easier for the bad guys and harder for those protecting systems.

    As Sully mentioned - either on this thread or the other, I don't recall - "not too surprising, still stupid".

    And, as one other user pointed out, administrators already are excluded from AppLocker rules, so why such by-design holes. Makes no sense, at all. If, as an administrator I'm already excluded, why such... They're not making my life, as an administrator, any easier by having done that, only harder. I got to cover my back other ways, when I thought they were covered by AppLocker.

    I wonder why such design isn't mentioned in the Technet library resources o_O
    If it weren't for Didier Stevens, unless someone is a programmer taking a look at MSDN library you'd never come across such "news".
     
  12. katio

    katio Guest

    His first POC, reflective memory injection, should have proven that already.

    >This totally kills the purpose of having such SRP/AppLocker, in the first place.
    I disagree with you here, 100% :)

    >As user wat0114 mentioned, Microsoft clearly had security in mind, and they even
    >mention fighting/preventing malware in the article pointed by wat0114.
    malware installed by the user, yes, but not remote exploits

    >Microsoft, simply putting it, has made life easier for the bad guys and harder for those
    >protecting systems.
    Their goal was to make it easier for the good guys to start using whitelists instead of blacklists, this is A Good Thing (even if it's just a start and incomplete, again let me reference UAC)

    >As Sully mentioned - either on this thread or the other, I don't recall - "not too surprising,
    >still stupid".
    Office Macros calling those is absolutely stupid. They overlooked that (just as I did, I had Applocker and Office 2010 deployed and never thought about macros being much of a risk, but they are, even if they couldn't call dlls and exes).

    >And, as one other user pointed out, administrators already are excluded from AppLocker
    >rules, so why such by-design holes. Makes no sense, at all.
    Because putting in a rule like allow Adobe, Google, Microsoft, Oracle, IBM and so on in the whitelist to allow users to install, keep updated and run a lot of application without them needing to call helpdesk directly safes money. This is all that counts for the target users of Applocker, MS only responded to their demands.

    >I wonder why such design isn't mentioned in the Technet library resources o_O
    Yep, I agree they should link to these functions more prominently in the Applocker documentation.
     
  13. RichieB2B

    RichieB2B Registered Member

    Joined:
    Jan 25, 2011
    Posts:
    13
    Personally I can't fathom allowing end users to update applications by themselves and still keeping the desktops secure. But let's assume this is a valid business case for some organizations. At the very least AppLocker should allow to limit which applications/installers can be run. Such as: only those signed by Microsoft, Adobe and IBM, or only those on drive S:. With the current backdoor, each and every msi that uses the right flags are allowed. No way to limit them = no control = no security.

    It looks like Microsoft didn't really think this through. Also, I have not yet found a technet or other article outlining a scenario where the AppLocker bypass flags are explained and put into a business case perspective. I really doubt there is one that makes real sense.
     
  14. katio

    katio Guest

    That's exactly what it does...
    No, you didn't think this through and you clearly don't understand how these functions work :/

    Only an already whitelisted (i.e. trusted) installer can call those functions, or trusted macros or an exploit shellcode but certainly not "each and every msi that uses the right flags".
     
  15. RichieB2B

    RichieB2B Registered Member

    Joined:
    Jan 25, 2011
    Posts:
    13
    True, but my point is that all it takes is one rogue/careless whitelisted installer/exe/macro to completely circumvent AppLocker using these special flags. It would have been much safer to have tied them to a control mechanism like a group membership, registry key or specific AppLocker rules.

    Now that I think about it some more: these flags should only be allowed to be used when an msi is allowed by the AppLocker Windows Installer Rules.
     
  16. Joeythedude

    Joeythedude Registered Member

    Joined:
    Apr 19, 2007
    Posts:
    519
    If an exploit shellcode can do this isn't that bad enough !
     
  17. katio

    katio Guest

    No, it doesn't. There is a tmp file race possibility but I'm sure you weren't thinking of that.

    https://www.wilderssecurity.com/showpost.php?p=1818043&postcount=22
    https://www.wilderssecurity.com/showpost.php?p=1818848&postcount=79
    and so on.
    Use EMET, patch your software, sandbox Flash and other notoriously insecure software.
     
  18. RichieB2B

    RichieB2B Registered Member

    Joined:
    Jan 25, 2011
    Posts:
    13
    I thought it was interesting to note that Microsoft now warns for this specific situation in this Security Considerations for AppLocker technet article. They also updated the Understanding AppLocker Policy Design Decisions article.

    I have been told that a proper fix to control these flags is being tested though.
     
  19. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623

    Thanks for the heads up! :thumb:
     
  20. J_L

    J_L Registered Member

    Joined:
    Nov 6, 2009
    Posts:
    8,738
    So AppLocker gets priority over fix. What about SRP?
     
  21. pcunite

    pcunite Registered Member

    Joined:
    Oct 22, 2009
    Posts:
    15
    This makes me so mad ... Windows 7 could be so secure ... all you have to do is have an OS mark read, write, execute areas and let ME decide what does what ...
     
  22. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    Will the so-called fix be offered as a gift in Christmas or New Year's? :rolleyes: I never heard of a fix coming during all this time. Have you? :doubt:

    -edit-

    Maybe the fix will only come with Windows 8. lol
     
  23. 1chaoticadult

    1chaoticadult Registered Member

    Joined:
    Oct 28, 2010
    Posts:
    2,321
    Location:
    USA
    Maybe with SP2 if they feel like it LOL. But I think with the focus on Windows 8, it seems more like to be fixed in it.
     
  24. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    Well, I found link where a hotfix was mentioned.

    -http://www.mountknowledge.nl/2011/01/28/bypassing-windows-applocker-using-vb-script-in-word-and-excel/

    But, when going to the Microsoft's hotfix page, there's nothing there.

    http://support.microsoft.com/kb/370118

    o_O

    According to the first link, the fix is suppose to be offered in October. Let's see what happens.
     
  25. 1chaoticadult

    1chaoticadult Registered Member

    Joined:
    Oct 28, 2010
    Posts:
    2,321
    Location:
    USA
    Thanks for the link. Hopefully they do get the fix in October.
     
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.