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

    Faronics like Comod and Appguard doesn't check dlls at all.

    Thanks RichieB2B for suggesting the two other products.
    The problem with those is they are seriously overkill for private or small business environments.
    McAfee gives an error on Windows 7 (and 32bit!). Even if it would work the install and licensing process is pretty convoluted :(

    I couldn't even obtain an installer for Bit9 Parity. To get a trial they need to manually answer by email (and they tell you about it after the fact, of course I entered some bogus credentials).
    At least I can confirm that Bit9 does handle dlls. It not only checks if dlls get loaded by an application but it flags them as soon as a dll is written to disk. From that perspective it looks like we have a winner here. However it does not protect against reflective injection/loading as noted here: http://seclists.org/metasploit/2010/q1/118

    If you have a look at this demo you''ll see like AL and SRP it's also only marketed as an application control management solution, not an anti-exploit layer
    http://www.bit9.com/flash/demo-parity.php

    What we can take home from this thread:
    If you deal with targeted attacks you need to design your security layers with tools like meterpreter in mind. Anti-exec is no and never was a silver bullet but that should hardly surprise anyone at this stage.
    The days of smug SRP signatures are over ;P
     
  2. Sully

    Sully Registered Member

    Joined:
    Dec 23, 2005
    Posts:
    3,719
    I don't know about that, but I suppose so.

    I was hoping the days of a light and effective (and free) tool would be around for some time, not dashed to pieces by the developers.

    While I understand that perhaps SRP was not supposed to be used by so many in the form it has, it was a planned part of the OS. You/they can state over and over that it is by design, and I will agree, it is by design. But that does not change the fact that they purposefully introduced a security layer (no matter what it was designed to do) and that they also purposefully introduced a weakness to that layer. It makes no sense at all. No matter what SRP and/or AppLocker was designed to do, if you have such an easy way around it, it fails EVERYTHING it was designed to do simply because they made sure it could be circumvented.

    While it may still be effective because of the "security by obscurity" principle, and the majority who use it probably will find it works fine for them, it still means you have to fit it into your equation, the fact that it is exploitable easily.

    Personally I am going to start from the ground up again with how I do things. I don't think much will change, but it can't hurt to examine it all again with this new information in the loop.

    As you say, these 2 threads give a lot to take away and think about.

    Sul.
     
  3. Sadeghi85

    Sadeghi85 Registered Member

    Joined:
    Dec 20, 2009
    Posts:
    747
    Let me see if I got it right.

    I can think of two ways a malware writer could use these holes:

    1) a program needs to be whitelisted in AL(e.g. copied to program files), it will then download a dll and save it to a temp folder and use LOAD_IGNORE_CODE_AUTHZ_LEVEL flag to bypass AL, or download an exe and use SANDBOX_INERT flag. The dll or process will inherit the integrity level of its parent.

    2) exploit a buffer overflow vulnerability to execute shellcode that does the above.

    Did I get it right? If so, what exactly has changed compared to dll loading from ram? The only thing I can see is these revelations make it easier for malware writers, as I guess it requires lesser code in memory.

    So the mitigation is the same? Tight AL rules, EMET, HeapLocker... ??
     
  4. Joeythedude

    Joeythedude Registered Member

    Joined:
    Apr 19, 2007
    Posts:
    519
    Faronics 2.2 did check dll's
     
    Last edited: Jan 25, 2011
  5. Didier Stevens

    Didier Stevens Security Researcher

    Joined:
    Nov 19, 2010
    Posts:
    68
    Maybe I'll have a better chance now that I'm a Microsoft MVP Consumer Security ;-)
     
  6. Didier Stevens

    Didier Stevens Security Researcher

    Joined:
    Nov 19, 2010
    Posts:
    68
    Correct. But there is a third major vector: the scripting language of a whitelisted application, like VBA in Excel.

    It's much easier, but also more reliable. You're using the WIN32 API as Microsoft intended it.
     
  7. wat0114

    wat0114 Guest

    The Bit9 Parity video states a couple things that throw me for a loop:

    1. Taking away administrative rights is too restrictive.
    2. When you ban by hash it is 100% accurate and effective.

    On the first point, what a crock. Most end-users in a corporate environment don't need - nor should have - administrative rights. Only those qualified and authorized especially for their job category should have it.

    On the second, unless I'm missing something, this is wrong. Hash values change when the executable changes, so banning by hash is largely useless. These guys seem to miss the importance of controlling a software environment by use of a whitelisting approach.
     
  8. Sadeghi85

    Sadeghi85 Registered Member

    Joined:
    Dec 20, 2009
    Posts:
    747
    Thanks Didier for your response, now I get it better.
     
  9. katio

    katio Guest

    Yeah, me too. But if you think like most corporate decision makers security is a nuisance. The goal isn't to design an IT environment soundly from the ground up with security in mind, you'd only be interested in passing PCI Compliance and preventing too much data leaks that could effect PR and so on. Bit9 offers an answer that provides protections without making too many tradeoffs.
     
  10. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    You actually raised very good points. :)

    Please @ anyone, bear with my thought, and correct whatever you see it needs to be corrected. I'm just trying to understand a bit more and learn, of course.

    Imagine that this program that has been whitelisted in AppLocker, such as user Sadeghi85 mentions, is your web browser.

    In a hypothetical situation, let's suppose this web browser has a security vulnerability allowing remote code execution. Someone enters a website hosting malicious code capable of exploiting such vulnerability. It would initiate what it called as a drive-by download or remote code execution. But, AFAIK, this malicious code would need to be download to a temporary folder first, as user Sadeghi85 mentioned. At least, that's how I believe the web browser behaves for any file a user wishes to download, or that gets downloaded without the user knowing it; first it downloads the file to a temporary location, which in Windows Vista and 7 is %AppData%\Local\Temp.

    Now, if this possibility, of first downloading the temp file is killed straightaway, then the nothing gets downloaded, nor executed; which on is turn, won't download and execute nothing as well.

    Hit me at will. :D
     
  11. katio

    katio Guest

    *hits*
    No, the way it works is that shellcode itself will download and execute a file. It can store this file anywhere the parent process has rwx access to. That includes memory. So if you think you can just monitor the filesystem and rule out that any malicious code is running on your system, that approach doesn't work. A memory only malware could then launch a separate privilege escalation and bury itself deep into the kernel and your other ring 0 protection wouldn't know a thing. That's why I keep stressing the importance of memory corruption mitigation which stops attacks at the shell-code layer, i.e. as early as possible.
     
  12. Didier Stevens

    Didier Stevens Security Researcher

    Joined:
    Nov 19, 2010
    Posts:
    68
    In any case, I won't post a patched ntdll.dll. It is copyrighted, there are countless versions of it, and there will be many new versions in the future. I might release a custom DLL to do the patching in memory. But of course, this patching can be undone by the attacking shellcode.
     
  13. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    OK, I understand that. The shellcode downloads the file to wherever the parent process has access to, which includes memory, and then executes it. This implies the file to be executed is not being saved to disk.

    But, my wonder was: What if the parent process would be removed any rights to allow anything to be transfered? Would this kill the whole downloading process, in the first place? Or, would the shellcode still be able to download and execute the file?

    I hope you understand what I'm questioning myself about. I truly don't know better words to explain it.

    And, thanks for the feedback. :)
     
  14. katio

    katio Guest

    If you block network access via software firewall for example you could catch the payload that way. This doesn't really work with browsers and other network facing programs (which are the primary target of such exploits). With malicious pdfs and media files it's different but it fails short again if the payload is already embedded in the file (no problem here given the size of those files). Removing the "rights to execute" is not possible: While you can prevent a target application from opening another executable at least to my knowledge there is no way to prevent reflective dll loading.
     
  15. CloneRanger

    CloneRanger Registered Member

    Joined:
    Jan 4, 2006
    Posts:
    4,978
    Just a thought.

    Whitelisting DLL's would surely help in prevention, would it not ?
     
  16. katio

    katio Guest

  17. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
    True, and that's why I didn't update the tutorial for v5.x. CIS v4.x however does. I posted the v4.x download links in the appropriate thread.
     
    Last edited: Jan 25, 2011
  18. pandlouk

    pandlouk Registered Member

    Joined:
    Jul 15, 2007
    Posts:
    2,976
  19. katio

    katio Guest

    Only for some attacks it will make a difference: dlls planted on webdav shares, archives and external media and only if you use a vulnerable software, but not with shellcode based exploits.
     
  20. pandlouk

    pandlouk Registered Member

    Joined:
    Jul 15, 2007
    Posts:
    2,976
    Thanks katio, you confirmed my thoughts.

    Now, I am wondering if this dll vulnerability is combined with the "SaferComputeTokenFromLevel Function" and especially "SAFER_TOKEN_MAKE_INERT" won't it become a nightmare for everyone that uses SRP and/or AppLocker?
    http://msdn.microsoft.com/en-us/library/ms722424(v=vs.85).aspx

    Panagiotis
     
  21. katio

    katio Guest

    If someone creates a VBA macro (which is simple now that all the parts have been posted on the net) to launch arbitrary exes and posts it publicly, yes, this would render both next to useless as longs as Office is installed. Without this "backdoor" one first needs to find a vulnerable application and that's not so easy if the admins keep everything updated.

    So, if you want to get this fixed, here's how it could be done:
    Create said macro, notify MS and demand an ETA, if they either give no ETA or don't issue a fix in time post the code to FD. Be ready for the hyenas (or don't use your real identity).
     
  22. Sadeghi85

    Sadeghi85 Registered Member

    Joined:
    Dec 20, 2009
    Posts:
    747
    I was thinking about this...

    From the MSDN documentation:
    And:

    If I recall correctly, I read an article on technet blog a while ago that encouraged developers to install their program into program files rather than user account. The installer needs admin right to write to program files, the admin account by default is exempt from AL rules. So what's the point of those flags??
     
  23. m00nbl00d

    m00nbl00d Registered Member

    Joined:
    Jan 4, 2009
    Posts:
    6,623
    It doesn't make sense, does it o_O I also don't understand it. AppLocker and SRP only make sense if we're talking about a LUA context; which obviously means that those rules do not apply to admin accounts. So, why such holes in AppLocker and SRP o_O

    It makes me wonder too.
     
  24. katio

    katio Guest

    See what we talked about Bit9 earlier in the thread?
    It's not very realistic in a large enterprise infrastructure to maintain whitelisting the same way we do on personal systems with mostly a single user. Admins can't block EVERYTHING and and tell their users to submit all their installation requests, approve or disapprove them and then install them themselves.

    Instead they are going to rely much on the more highlevel publisher rules. Take the average installer, it consist of lots of dlls and often several exe files, which often aren't all signed either. Having to approve only a single setup.exe as opposed to every single file it contains is a great feature from the perspective of a sys admin.
    AFAIK it's very common that users install software inside S/LUA. Also there are several update mechanisms that run as a limited user.


    Macros being able to call other dlls and exes is a loophole in that system. Lacking communication between the different dev teams, or they just figured, if you trust users to execute macros it doesn't matter anyway?
     
  25. Rmus

    Rmus Exploit Analyst

    Joined:
    Mar 16, 2005
    Posts:
    4,020
    Location:
    California
    This really depends on the institution and the level of resolve of management to maintain security.

    My favorite example is this case study:

    http://www.faronics.com/whitepapers/CaseStudy_LAPD.pdf
    In the college system where I worked, Deep Freeze was installed campus wide. Faculty submitted requests for new applications. They were checked/approved by Campus Computer Support and then installed. There was no difficulty with that arrangement.

    regards,

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