We’ve seen it countless times before. A vendor designs a security product, but punches a hole in this shield to accommodate developers. Yet, I still love the irony of it.
Software Restriction Policies and AppLocker can be configured to whitelist DLLs. But LoadLibraryEx has a feature (LOAD_IGNORE_CODE_AUTHZ_LEVEL) to circumvent SRP and AppLocker. From the MSDN documentation:
If this value is used, the system does not check AppLocker rules or apply Software Restriction Policies for the DLL. This action applies only to the DLL being loaded and not to its dependents. This value is recommended for use in setup programs that must run extracted DLLs during installation.
I’ve blogged about a spreadsheet that creates a DLL in a temporary location, and loads it inside the Excel process with LoadLibrary. It’s easy to block this DLL with SRP or AppLocker. But now I found out it’s also easy to bypass this, much easier than what I’ve done before. I just have to replace a call to LoadLibrary with a call to LoadLibraryEx, and pass it argument LOAD_IGNORE_CODE_AUTHZ_LEVEL. That’s all it takes to bypass SRP and AppLocker.
Let it be clear that this only makes it possible to load arbitrary DLLs inside existing processes, it does not allow you to create a new process that SRP/AppLocker wouldn’t allow.
If you use SPR/AppLocker, should you worry? It depends against what risk you use it.
When you use SRP/AppLocker to prevent common malware or other unwanted programs from infecting your machine, there’s no problem (now). If you use it on corporate computers to prevent your users from using software you don’t support, there’s no problem.
But if you use SRP/AppLocker as a security layer against (skilled) evil haxors, then you have to be aware that there is a large hole in your security layer and that it’s easy to misuse. In that case, you should better look out for another whitelisting security layer without “designer holes”. Unless it turns out Microsoft has a (hidden) setting to disable this feature, but I’ve not found one.
If this value is used, the system does not check AppLocker rules or apply Software Restriction Policies for the DLL. This action applies only to the DLL being loaded and not to its dependents. This value is recommended for use in setup programs that must run extracted DLLs during installation.
Didier Stevens 
This “feature” should be reported as a security vulnerability just like the insecure DLL loading from current directory “feature” last year. MS needs to at least provide a registry key to turn off this bypass, otherwise Applocker is useless IMO. Trivial bypass.
Theres more where this came from. http://msdn.microsoft.com/en-us/library/aa446583(VS.85).aspx http://msdn.microsoft.com/en-us/library/ms722424(VS.85).aspx SANDBOX_INERT If this value is used, the system does not check AppLocker rules or apply Software Restriction Policies. For AppLocker, this flag disables checks for all four rule collections: Executable, Windows Installer, Script, and DLL.
When creating a setup program that must run extracted DLLs during installation, use the flag SAFER_TOKEN_MAKE_INERT in the SaferComputeTokenFromLevel function.
A token can be queried for existence of this flag by using GetTokenInformation.
Thanks M$ for making your security features useless. 🙂
Comment by cptanon — Monday 24 January 2011 @ 16:34
@cptanon Thanks a lot for pointing this out, I tested SRP with SANDBOX_INERT and can confirm that I can create a new process!
Comment by Didier Stevens — Monday 24 January 2011 @ 17:18
If you can run code, you can bypass SRPs in any number of ways. Misusing SANDBOX_INERT and LOAD_IGNORE_CODE_AUTHZ_LEVEL will cause problems, but they are not problematic in themselves.
Comment by Tom — Monday 24 January 2011 @ 17:44
If you’re doing blacklisting instead of whitelisting, this feature would seem to make it more trivial to bypass SRP than usual, but what kind of attacks did you image this being used for?
Comment by Mark D. Adams — Monday 24 January 2011 @ 18:24
@Mark D. Adams This can be used in shellcode that downloads and loads a DLL; there is malware around that does this. It’s simple to replace the call to LoadLibrary with LoadLibraryEx in said shellcode, and push 2 extra parameters on the stack.
Comment by Didier Stevens — Monday 24 January 2011 @ 18:38
[…] waardoor bedrijven risico lopen. Dat laat de Belgische beveiligingsonderzoeker Didier Stevens weten. Via Software Restriction Policies en AppLocker is het mogelijk om DLL-bestanden te whitelisten en […]
Pingback by Plaats hier software gerelateerd nieuws! - Page 29 — Monday 24 January 2011 @ 18:49
[…] There’s an interesting comment on my Circumventing SRP and AppLocker, By Design post. […]
Pingback by Circumventing SRP and AppLocker to Create a New Process, By Design « Didier Stevens — Tuesday 25 January 2011 @ 0:00
I just wanted to point out to the readers of this blog that there is an active discussion of this topic at
http://www.wilderssecurity.com/showthread.php?p=1818199 and http://www.wilderssecurity.com/showthread.php?p=1818225
Comment by RichieB — Tuesday 25 January 2011 @ 20:13
[…] looking into the usefulness of Windows AppLocker Belgian security researcher Didier Steven posted a blog entry explaining that he found a way to load DLLs that are not permitted by AppLocker. An anonymous […]
Pingback by Mount Knowledge » Bypassing Windows AppLocker using VB script in Word and Excel — Friday 28 January 2011 @ 22:53
[…] Microsoft has features to bypass its own Software Restriction Policies and AppLocker: Circumventing SRP and AppLocker, By Design and Circumventing SRP and AppLocker to Create a New Process, By […]
Pingback by Hotfix For SRP/AppLocker Bypass « Didier Stevens — Thursday 17 November 2011 @ 10:53
[…] Didier Stevens a montré que les premières montures pouvaient être abusées facilement. […]
Pingback by AppLocker et ses limites | Cryptobourrin — Tuesday 6 October 2015 @ 13:47
[…] update or mitigation to address this issue since AppLocker is functioning by design. In 2011 a bypass to AppLocker was discovered by Didier Stevens which was later addressed by Microsoft with a […]
Pingback by Windows AppLocker Bypass Disclosed | securityinaction — Sunday 24 April 2016 @ 20:40
[…] Также существует еще несколько способов обхода AppLocker, упомянутых в комментариях пользователем navion: раз и два. […]
Pingback by Очередной способ обхода Windows AppLocker - itfm.pro — Monday 25 April 2016 @ 10:11