Didier Stevens

Wednesday 29 December 2021

VBA: __SRP_ Streams

Filed under: Forensics,maldoc — Didier Stevens @ 0:00

Office documents with a VBA project that contains streams whose name starts with __SRP_, have had their VBA macros executed at least once.

As Dr. Bontchev describes in the documentation for his pcodedmp tool:

When the p-code has been executed at least once, a further tokenized form of it is stored elsewhere in the document (in streams, the names of which begin with __SRP_, followed by a number).

Thus in my maldoc trainings, I always explain that the presence of __SRP_ streams is an indication that the VBA code has been executed prior to the saving of the document, and vice-versa, that the absence means that the code was not executed (prior to saving).

I recently discovered that these __SRP_ streams are also created when the VBA project is compiled (without running the macros), by selecting menu option “Debug / Compile Project” in the VBA IDE.

Thursday 17 November 2011

Hotfix For SRP/AppLocker Bypass

Filed under: Windows 7 — Didier Stevens @ 10:53

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.

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

Tuesday 25 January 2011

Circumventing SRP and AppLocker to Create a New Process, By Design

Filed under: Vulnerabilities — Didier Stevens @ 0:00

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:

Monday 24 January 2011

Circumventing SRP and AppLocker, By Design

Filed under: Vulnerabilities — Didier Stevens @ 0:00

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.

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.

Tuesday 20 July 2010

Mitigating .LNK Exploitation With SRP

Filed under: Vulnerabilities — Didier Stevens @ 7:13

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:

Wednesday 25 June 2008

bpmtk: Bypassing SRP 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 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.

Thursday 5 June 2008

bpmtk: How About SRP Whitelists?

Filed under: Hacking,My Software — Didier Stevens @ 13:44

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).

Saturday 1 January 2022

Overview of Content Published in December

Filed under: Announcement — Didier Stevens @ 0:00
Here is an overview of content I published in December: Blog posts: YouTube videos: SANS ISC Diary entries:

Friday 3 January 2020

Overview of Content Published in the 2010s

Filed under: Announcement — Didier Stevens @ 0:00

Here is an overview of content I published in the 2010s:

Blog posts:

YouTube videos:

Videoblog posts:

SANS ISC Diary entries:

NVISO blog posts:

Thursday 26 August 2010

Quickpost: Ariad & DLL Preloading

Filed under: My Software,Quickpost,Vulnerabilities — Didier Stevens @ 12:11

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.

Quickpost info

Next Page »

Blog at WordPress.com.