I’m writing this quickpost just in case you hadn’t figured this out for yourself: the techniques I described to protect machines from the .LNK vulnerability also help you mitigate the DLL preloading issue.
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.
As I’ve used Software Restriction Policies (SRP) on several occasions in my blogposts, and several people have suggested using SRP to protect against .LNK exploitation as an alternative to Ariad, I’ll describe how to configure SRP for the first time on a workstation that is not a member of a domain. For domain members, you have to configure SRP in the GPO on the domain controller.
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:
I finally took time to develop shellcode to load a DLL, not with LoadLibrary, but directly from memory. Not storing the DLL on disk prevents it from being detected by AV software; not using LoadLibrary bypasses HIPS software that monitors this system call.
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:
I wasn’t going to mention SAFER to restrict the rights of an application, because Software Restriction Policies can be bypassed. But a Tweet by Edi Strosar made me review my viewpoint. In this particular case, bypassing SRP is a non-issue, because the user is already local admin!
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:
I developed another variant of my “Excel macro injects embedded DLL” script.
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 my last bpmtk post, I argued that although whitelisting DLLs (supplementary to whitelisting EXEs) prevents my Excel macro from loading the embedded DLL, it would be far too difficult to build and maintain such a whitelist of DLLs. However, Cd-MaN commented with a technique to add DLL restrictions to the Software Restriction Policies without building an exhaustive DLL whitelist, the details are in his excellent blogpost (step 3).
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.
My latest bpmtk post got some people to ask me for the VBscript. I’ll do better, I’m posting the Python program I wrote to generate the script. You can download it here.
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.
After having showed you how my Basic Process Manipulation Tool Kit can be used to bypass Software Restriction Policies, I wanted to follow this with a post showing how SRP whitelisting can prevent this. However, while preparing this new post, I got an idea how I could bypass SRP whitelists (under certain conditions), but I’ve no idea how to prevent this. I finally decided to post this without a solution, maybe you’ll come up with one.
With a SRP whitelist, starting a program is denied by default:
As an administrator, you’ve to explicitly specify the programs that are allowed to be executed by your users (if there are many programs, maintaining this whitelist becomes time consuming). Because of this whitelist, tools like gpdisable or bpmtk can’t be executed to disable SRP. However, if I can execute these tools without starting a new process, SRP will not block them …
Applications with embedded scripting can also be used to manipulate processes. For example, the scripting features of Microsoft Office allow you to call the system APIs I’ve been using in my bpmtk. It’s often not easy (even impossible) to convert a C program to VBscript, but I’ve a workaround.
First, we adapt our C program from an EXE to a DLL (entrypoint DllMain in stead of main), because VBscript can load a DLL.
We’ll use Excel’s scripting features. I’ve created an Excel spreadsheet that embeds a DLL that can be executed with a mouse-click:
The MyDLL dialog is displayed by the embedded DLL.
The DoIt button starts this Sub:
DoIt will create a temporary file (in the user’s temporary file folder), write the embedded DLL to it (DumpFile), and then load the DLL (LoadLibrary).
Generating the temporary filename:
Writing the embedded DLL to the temporary file:
Each DumpFileX sub writes bytes to the temporary file (the DLL is embedded in these subs by including the hex dump in strings). It’s necessary to split this over several subs, because of the sub size limitation.
Once the DLL is stored in the temporary file, we call LoadLibrary to load our library in the Excel process. And this executes our code inside the Excel process. Because of this, SRP will not deny it, and our code can disable SRP.
Creating temporary files and loading libraries is normal behavior for programs, SRP will not block this. Even most HIPS will not block this, because loading a library is not the same as injecting a DLL (injecting a DLL is loading a library inside another process). The only thing that might be considered abnormal by the HIPS, is that a temporary file is mapped into memory, but there are also legitimate programs that do this.
SRP has an option to whitelist DLLs, but then you’re facing the huge task of identifying and specifying all DLLs your programs use!
If you implement a SRP whitelist because you absolutely want to control the programs executed by your users, take some time to reflect on your users and the scripting capabilities of your whitelisted applications. And if you really have to prevent the technique I show here, you’ll have to find another solution than SRP whitelists. Unfortunately, I’ve not found one yet… If you’ve an idea, post a comment (banning applications with embedded scripting or disabling scripting is not an option).
Gpdisable is a tool to bypass group policy as a limited user, posted by Marc Russinovich on his blog when he was still the owner of Sysinternals. But now that Sysinternals is owned by Microsoft, the tool is not available anymore.
My Basic Process Manipulation Tool Kit can replace Gpdisable, I’ll show how and give you one more trick.
LikeMarc did, you can inject a DLL that will patch the IAT to subvert NtQueryValueKey, but I’ll leave this technique for an upcoming post.
My example doesn’t require you to program a DLL to inject: since we want to hide the TransparentEnabled registry key, we will just rename the key in the process memory of the programs that impose Software Restriction Policies on us (like explorer.exe). Here is the bpmtk config file to achieve this goal:
dll-name advapi32.dll #rename TransparentEnabled to AransparentEnabled search-and-write module:. unicode:TransparentEnabled ascii:A
This will patch each process you’ve rights to and who has loaded advapi32.dll (this DLL enforces SRP).
But as Mark writes in his blog, this will not work for running processes because they have already cached the value of TransparentEnabled and are thus not querying the registry anymore. This is why many people reported that Gpdisable didn’t work for them. Gpupdate /force will force a refresh of the policies, and invalidate the cache.
But if you’re in a restricted environment, there’s a chance you’re prevented from doing a gpupdate. Here’s another way: set the variable _g_bInitializedFirstTime to 0, this will also invalidate the cache. For advapi32.dll version 5.1.2600.2180, this variable is at address 77E463C8. Our script becomes:
dll-name advapi32.dll #rename TransparentEnabled to AransparentEnabled search-and-write module:. unicode:TransparentEnabled ascii:A write version:5.1.2600.2180 hex:77E463C8 hex:00
