Microsoft has issued a hotfix for this bypass: KB2532445

It is only for Windows 7 and Windows Server 2008 R2 though, it will not help you if you use SRP on Windows XP or Vista.

Thanks to @mount_knowledge.

Circumventing SRP and AppLocker, By Design

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:

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.

The .LNK vulnerability mitigation examples I gave with Ariad (no file execute) and SRP prevent loading of DLLs from untrusted locations (USB sticks, network drives, …). These will also prevent DLLs from loading from untrusted sources in the case of DLL Preloading exploits.

Start the Local Security Policy manager from Control Panel / Administrative Tools:

Software Restriction Policies need to be defined the first time:

We exclude our system drive (C:) from being restricted (add other drives if you have more):

To protect against .LNK exploitation, we need to restrict DLLs too, not only EXEs:

And finally, switch from blacklisting to whitelisting:

After configuring SRP, execute a logoff/logon to apply them immediately.

From now on, only executables on your C: drive will be allowed to run.

.LNK exploitation from removable media is blocked:

My shellcode is based on Joachim’s code.

In previous posts, I showed how to load a DLL or shellcode with VBA in Excel. This is a combination of both techniques: a VBA macro loads and executes shellcode in Excel’s process space, and the shellcode loads a DLL from memory into Excel’s process memory.

With the code of the previous post, the DLL appears in the list of loaded DLLs:

With this shellcode, it doesn’t:

Software Restriction Policies allow you to force specific applications to run with a restricted token. As Michael explained it with AD GPOs, I’ll show it with local policies.

Enable SAFER policies for SRPs by adding DWORD registry key Levels (value 0×31000) to HKLM\SOFTWARE\Policies\Microsoft\Windows\Safer\CodeIdentifiers:

Start the Local Security Policy administration tool and go to the Software Restriction Policies. You’ll have to create new policies if this is the first time you configure SRPs.

Create a new rule in Additional Rules. We’ll identify the application to restrict by its path and name, so create a Path Rule:

For the security level, select Basic User:

If you have no Basic User option, you forgot to update the registry before launching the administration tool:

Select the application to restrict:

This rule will force Adobe Reader to run with a restricted token:

Writing to SYSTEM32 is denied:

In stead of creating and loading a temporary DLL from VBScript, I inject and execute shellcode directly from the VBA application.

Some HIPS would prevent my previous script from running, because it loaded an unapproved DLL. But my new version doesn’t load a DLL.

Of course, writing shellcode is more difficult than developing a PE executable.

In a nutshell, Cd-MaN configures SRP to restrict allowed DLLs to those found in the Windows and Programs Files directories (a restricted user is not allowed to write to these directories).

To bypass this SRP configuration with my Excel macro, I had to update it so that it would perform the process manipulation directly, in stead of doing this manipulation from within the embedded DLL. And here his how I did it:

The trick is to call WriteProcessMemory directly from within the script to disable SRP. Because I didn’t want to recode my search-and-write function from C to VBscript, I hardcoded the addresses to write to (this will only work for the specified version of advapi32.dll). The effect of these 2 WriteProcessMemory calls is to patch advapi32.dll inside the Excel process, thereby disabling SRP so that the embedded DLL is allowed to load (of course, now that SRP is disabled for Excel, I can also just start another program).

A new version of my bpmtk utility (with the DLL version of bpmtk.exe) will be posted soon.

You have to provide it 2 arguments: the name of the executable to embed and the name of the VBscript to generate, like this:

file2vbscript cmd.exe cmd.vbs

This will generate a VBscript that will write cmd.exe to the current directory and execute it (create a new process). If you want to load a DLL in stead of executing an EXE, use the -l option:

file2vbscript -l mydll.dll mydll.vbs

And to use it in an Office application (Office VBA doesn’t take long subs), use the option -o:

file2vbscript -ol mydll.dll mydll.vbs

This will split the embedded file over several subs, to accommodate for the size limitation of Office VBscripts.