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).
Didier Stevens 
Wow this is a good question and quite out of my league but has got me thinking.
The only thing that I can see would be to go with the white list option. It certainly would be a large undertaking but at least in an enterprise environment with a standard computer template it should not need to be done very often. It would need to be created once and only updated every time new software was added. First installing any new software on a computer that had a fresh install and was never connected to a network should allow you to relatively easily identify any new Dll’s that would need to be added to the white list. Should should be able to push the updated whitelist out over group policy and limit the impact on users. But this would only really work in an enterprise environment, and no one ever said security was going to be easy.
The only other possible thing I can imagine would be to get updated AV signatures that would catch files with numerous strings of bytes in the scripting. It looks like that would be necessary to pull off the exploit and I can’t think of a legitimate reason for something like that to be included in a file, but I don’t really do any scripting so maybe there is some utility there.
Comment by DF — Friday 6 June 2008 @ 16:45
That’s very interesting. I tried to reproduce what you did … but failed miserably! I have some understanding of coding and managed to compile code that you supplied in relation to your Utilman series but I think I need some help here!
If I get it right, you produce your executable (maybe a HelloWorld.exe) but compile it as a DLL. I see that Sub DumpFile1(f) has a whole load of hex values and I presume that’s where the hex values of the DLL are entered?
I’ve managed to get the Macro Code into Excel 2003 but am not sure where the LoadLibrary and FreeLibrary declarations go. I don’t have a DLL but wherever I put these declarations on the Macro code, an error is generated when I run it from the button.
Can you post the code for your “MyDLL” (in the hope that I can compile it as I have done previously!) and give an indication about the Function Declarations?
Thanks for your efforts.
Comment by Dave — Sunday 8 June 2008 @ 18:29
[…] in a VBscript Filed under: My Software, Quickpost — Didier Stevens @ 11:53 My latest bpmtk post got some people to ask me for the VBscript. I’ll do better, I’m posting the Python […]
Pingback by Quickpost: Embedding an Executable in a VBscript « Didier Stevens — Monday 9 June 2008 @ 11:54
@DF
I really think whitelisting DLLs are too difficult to manage.
The problem with AV signatures, is that they are easy to bypass. This script is likely to be used in a targeted attack.
Comment by Didier Stevens — Monday 9 June 2008 @ 11:57
@Dave
Details can be found here: https://blog.didierstevens.com/2008/06/09/quickpost-embedding-an-executable-in-a-vbscript/
Comment by Didier Stevens — Monday 9 June 2008 @ 12:01
Thank you. It looks like I’m going to have to get “into” Python now. It’s something which I’ve wanted to delve into and this seems an ideal opportunity!
Comment by Dave — Monday 9 June 2008 @ 18:33
SRP is very good, you just have to configure it right 🙂
http://hype-free.blogspot.com/2008/04/windows-xp-high-security-configuration.html
Towards the middle of the page I describe how you change the default setting for SRP so that it applies to executables AND dlls, rather than just executables.
Comment by Cd-MaN — Tuesday 10 June 2008 @ 16:16
I’ve read your post, thanks! So you avoid building an exhaustive lists of allowed DLLs by defining that all DLLs (and EXEs) in folders c:\Windows and c:\program files are allowed? Clever!
I’ll have to test this and try to bypass it 😉
Comment by Didier Stevens — Tuesday 10 June 2008 @ 17:19
[…] with DLL Restrictions Filed under: Hacking, My Software — Didier Stevens @ 6:51 In my last bpmtk post, I argued that although whitelisting DLLs (supplementary to whitelisting EXEs) prevents my Excel […]
Pingback by bpmtk: Bypassing SRP with DLL Restrictions « Didier Stevens — Wednesday 25 June 2008 @ 6:52
How about using ramdisk overlay or using enhanced write filter (EWF) or embedded windows plus sandboxie plus your favorite hips under LUA?
Comment by jonpresty — Friday 9 January 2009 @ 14:13
@jonpresty Can you be more specific for the HIPS?
FYI: I’m doing this with LUA.
Sandboxie will not stop the DLL from running. It will block it from modifying the environment.
Comment by Didier Stevens — Monday 12 January 2009 @ 9:41
use forfiles (or equivalent approach) with objdump -x and sed (or grep or findstr) to generate a list of the dlls that programs use.
Comment by localhost — Wednesday 11 March 2009 @ 20:19
You forget that you would also need to do that on each used dll.
And then again …
Comment by Didier Stevens — Thursday 12 March 2009 @ 19:55
Including the dlls in the white list and defining the path rules as the windows dir and program files dir blanket, coupled with running as a limited user (no write access to windows dir or program files dir etc.) would seem to be effective, but I have yet to reproduce this trick… Very interesting approach I must say. Not 100%, but surely better.
Comment by Spiral — Friday 3 April 2009 @ 17:53
[…] 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 […]
Pingback by Quickpost: Shellcode to Load a DLL From Memory « Didier Stevens — Thursday 28 January 2010 @ 3:09
[…] blogged about a spreadsheet that creates a DLL in a temporary location, and loads it inside the Excel process with LoadLibrary. […]
Pingback by Circumventing SRP and AppLocker, By Design « Didier Stevens — Monday 24 January 2011 @ 0:04