Didier Stevens

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:

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.