Circumventing SRP and AppLocker by design, with LoadLibraryEx

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.

 

That makes sense.

 

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?

 

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.

 

You can stop at "wasn't meant to protect".
A metal detector with no one making sure you go through it.

 

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 Why have a control mechanism to control what happens, if this control mechanism can be avoided, due to its own design?

 

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.

 

@ katio

Thanks for the facepalm 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

 

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.

 

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

 

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

 

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
Yep, I agree they should link to these functions more prominently in the Applocker documentation.

 

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.

 

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

 

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.

 

If an exploit shellcode can do this isn't that bad enough !

 

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.

 

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.

 

Thanks for the heads up!

 

So AppLocker gets priority over fix. What about SRP?

 

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

 

Will the so-called fix be offered as a gift in Christmas or New Year's? I never heard of a fix coming during all this time. Have you?

-edit-

Maybe the fix will only come with Windows 8. lol

 

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.

 

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



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

 

Thanks for the link. Hopefully they do get the fix in October.