Didier Stevens

Thursday 27 October 2011


Filed under: Windows 7,Windows Vista — Didier Stevens @ 17:46

I discovered the flag FORCE_INTEGRITY last year when I released my tool setdllcharacteristics. This flag will force a check of the executable’s digital signature (on Windows Vista and Windows 7) and will prevent the program from running if the signature is invalid (or missing).

But it’s only now that I hold all the pieces to test this flag. A normal authenticode signature is not enough. And you can not use a selfsigned certificate. You need to buy a certificate (aka Software Publisher Certificate, SPC) from a commercial CA for which Microsoft issues a cross-certificate. And then you need to use your SPC and the related cross-certificate to sign your executable (with flag FORCE_INTEGRITY set) as explained here.

This is the same process for signing kernel-mode binaries, or user-mode binaries for AppInit_DLLs or other protected components.

I have the habit of signing my tools with a self-signed cert, so that I can quickly check if my tool has not been altered when I use it on another system (think infected machine). But now that I have a commercial SPC, I can go a step further: I can force Windows to check the integrity of my tools before executing them. If they have changed, Windows will warn me and refuse to run my tools:

There is a small performance hit because the loader has to check the signature, but you will not feel this if you don’t run the executable hundreds of times per second. There’s no problem with casual use.

If you want to test this, you can download a dummy application I signed here (32-bit). When you change the executable (TestIntegrityCheckFlag.exe), Windows will refuse to run it.

If this feature of Windows interests you, consider also the fact that you don’t need to own the source code to sign executables. If you use applications that are not protected by this flag, you can set the flag yourself and then sign the executable. But I don’t recommend that you publish this application, unless you get the author’s permission.

This method is good to protect your tools from malware, but not from malicious individuals: they just need to remove the FORCE_INTEGRITY flag from your executable and Windows will happily execute it regardless of the validity of the signature (I’m not speaking about kernel-mode binaries or other protected processes that require the FORCE_INTEGRITY flag to be set).

Remember that this is for Windows Vista and Windows 7; Windows XP will just ignore this flag. Windows 2008 R2 should also honor this flag, but I’ve not tested this. And it works on 32-bit and 64-bit systems.

Sunday 23 October 2011

HeapLocker 64-bit

Filed under: My Software,Vulnerabilities — Didier Stevens @ 19:40

I’m releasing my first 64-bit version of my HeapLocker tool.

I had to change many pointer calculations, and had to replace 32-bit shellcode with 64-bit shellcode.

This 64-bit version gets configured via the registry, exactly like the 32-bit version of HeapLocker. The only difference is when you want to protect specific addresses, you need to use a QWORD registry value in stead of a DWORD (QWORD is 64-bit wide, DWORD is 32-bit wide).

And there is a new feature: Bottom Up Randomization. To enable it, create a DWORD registry value with name BottomUpRandomization and value 1.

I will be adding this feature to HeapLocker 32-bit too, but I want to do this from the same code base. The next release of HeapLocker 32-bit will be compiled from Visual Studio 2010 and not from Borland C++ anymore.

HeapLocker64_V0_0_1_0.zip (https)
MD5: F3D43A29CE64F9418AA154C66B0B06A4
SHA256: 7EFF1D9EA20B522D76034DC4CB66E2FD7AC43E585987FC9ABF7EF8EB801FBC6C

Thursday 20 October 2011

RunInsideLimitedJob 64-bit

Filed under: My Software — Didier Stevens @ 6:00

RunInsideLimitedJob is a tool to sandbox applications by containing their process inside a limited job object. There are 2 versions of my RunInsideLimitedJob tool: a .EXE and a .DLL.

As a 32-bit executable, RunInsideLimitedJob.exe is perfectly capable of launching a 64-bit application contained in a limited job object.

But the 32-bit RunInsideLimitedJob.dll can’t be loaded inside a 64-bit process. That’s why I’m releasing a 64-bit version of RunInsideLimitedJob.dll.

RunInsideLimitedJob-DLL64_V0_0_0_1.zip (https)
MD5: A6048613CE00C9F401A8AC7943A451E3
SHA256: 279F6BE0EB124814D37A5E70F2D906B1756B27CDDC7E7AEA40B2B42B39C0CFCA

Wednesday 19 October 2011

LoadDLLViaAppInit 64-bit

Filed under: My Software — Didier Stevens @ 16:47

Many of my security tools are DLLs. If you want to use these tools inside a 64-bit process, you’re stuck, because you can’t use 32-bit DLLs inside a 64-bit process (and vice versa).

LoadDLLViaAppInit is a tool I released to load DLLs inside selected processes. If you want to use this 32-bit version of LoadDLLViaAppInit on a 64-bit Windows machine, you need to configure AppInit_DLLs in this registry key:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Windows NT\CurrentVersion\Windows

You also need to copy LoadDLLViaAppInit.dll in this directory: C:\Windows\SysWOW64

Today I’m releasing a 64-bit version of LoadDLLViaAppInit: LoadDLLViaAppInit64.dll. This will help you to load DLLs inside 64-bit processes.

This 64-bit version has to be installed and configured just like its 32-bit version on a 32-bit OS: you copy the DLL in directory C:\Windows\System32 and you configure the registry:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows

The configuration file is LoadDLLViaAppInit64.bl.txt.

This 64-bit version has only been tested on 64-bit Windows, not on 64-bit XP neither on 64-bit Windows Server. I expect it to work on these systems too, but you need to test first. I’ve also compiled this 64-bit version with Visual Studio 2010 and an option to include the runtime Visual C++ libraries inside the DLL, so you don’t need to install the Microsoft Visual C++ 2010 Redistributable Package. But this option has a drawback: when Microsoft releases a patch for the libraries, I (or you) will have the recompile the DLL with the new version of the libraries.

LoadDLLViaAppInit64_V0_0_0_1.zip (https)
MD5: 94C38717690CE849976883FFE4B22CA1
SHA256: 447C8F61A6398CBE6BD5E681FCE28C55D426D4E4EA49BBE367AE5B334B073A55

Tuesday 18 October 2011

HeapLocker: Preventing Heapsprays

Filed under: My Software,Vulnerabilities — Didier Stevens @ 8:34

I’ve been using my HeapLocker tool for almost a year now, and I’ve encountered no issues, except for the NOP sled detection. When used with Adobe Reader, HeapLocker will generate too many false positives when looking for NOP sleds. So I’ve disabled NOP sled detection for Adobe Reader.

The last feature I want to talk about is heap spray mitigation.

Like EMET, HeapLocker can pre-allocate memory pages so that they can’t be used by the heap. And this renders a heap spray useless, as it will not be able to inject shellcode at the addresses HeapLocker protects. But unlike EMET, HeapLocker has 2 modes of pre-allocating memory pages. The first mode is just like EMET, while the second mode will write special shellcode to the pre-allocated pages. When this shellcode is hit due to an exploit, it will callback to HeapLocker which will suspend all threads and display a warning dialog. This is what you see in the video. There are 2 advantages to this mode: the user is warned that she opened a malicious document, and you can also use this in a malware lab to find out which address the exploit is hitting.

To prevent the HeapLocker shellcode from being used for ROP exploits, I randomized the injected NOP sled and shellcode. But if you still find this too risky, just use the standard mode for pre-allocating pages.

For more details about the exact way to configure this, read the documentation found in the HeapLocker download.

FYI: I’m also working on a 64-bit version of HeapLocker.

Monday 17 October 2011

Quickpost: Some Windows 8 Observations

Filed under: Quickpost,Windows 8 — Didier Stevens @ 20:36

I assume you know Microsoft released Windows 8 Developer Preview.

1) The UserAssist registry keys still exist, and still use ROT13 encoding:

Notice that there are also entries for the launching of Metro apps (e.g. alarms).

But there are also a couple of extra keys, I’ll analyze them when more definitive versions of Windows 8 are released:

2) My USBVirusScan tool still works.

3) The AppInit_DLLs registry key still exists:

4) And the SafeBoot keys also still exists, but Safe Mode (F8) has a Metro-style GUI.

Saturday 15 October 2011

TaskManager Runs on 64-bit Excel

Filed under: My Software — Didier Stevens @ 11:21

I’m releasing a new version of TaskManager.xls that runs on Excel 2010 64-bit too. The previous version ran on 64-bit Windows, provided you used Excel 32-bit. But this new version runs on both implementations of Excel.

TaskManager_V0_1_0.zip (https)
MD5: 5ED2AB6036CA94FAC7DEE5352718D07C
SHA256: EBCF4832C4DBAB0AFE778E19423EBB56CA4644DA1FDB5B2EB1BB4C27A26DB18C

Saturday 8 October 2011

Update: USBVirusScan 1.7.4

Filed under: My Software,Update — Didier Stevens @ 0:00

This new version 1.7.4 adds some extra debug info to the debug option (-d) and adds a new option (-w) to disable WOW64 filesystem redirection.

When USBVirusScan launches the program that was specified as argument upon insertion of a removable drive, it will provide debug information regarding the launching of this program.

In case of failure to launch the program, the debug info will include the error message from the Windows API:

If successfully launched, the debug info will include the process ID of the launched program:

USBVirusScan is a 32-bit application, but it works fine on 64-bit Windows. It can launch 64-bit programs without problems, except Windows’ own applications that come in 32-bit and 64-bit versions. For example, if you configure USBVirusScan to launch calc.exe on 64-bit Windows 7, it will launch the 32-bit version of calc.exe and not the 64-bit version. This is due to the WOW64 filesystem redirection mechanism. USBVirusScan has an option (-w) to disable this WOW64 filesystem redirection (only for USBVirusScan, not for your other programs). Disabling WOW64 filesystem redirection allows USBVirusScan to launch the 64-bit version of calc.exe.

Wednesday 5 October 2011

The Matryoshka Router

Filed under: Networking — Didier Stevens @ 0:00

I had an unpleasant surprise when I connected a new Cisco 887W router I had just configured to the Internet via its ADSL interface.

As it was the first time I worked with a 887, I did an nmap scan of its ADSL interface to check that I had closed all ports. Surprise: ports 2002, 4002, 6002 and 9002 were open. Even bigger surprise: I could logon via telnet to these ports with the default password, although I had changed it…

I’m omitting the details of how I figured out what went wrong, so here is the explanation.

The 887W has a wireless interface. But in this particular router, the wireless interface is not integrated in IOS (that’s Cisco’s IOS, not Apple’s iOS) like in other wireless routers like the 877W. In the 887W, the wireless interface is a service module with its own IOS and configuration. Both devices communicate with each other via a Gigabit interface.

The router IOS can be accesses via the serial console. The wireless IOS not (at least not directly).

To list the installed service modules, you issue the service-module ? command on the router CLI:

  wlan-ap  Service module interface to embedded AP

To access the wireless CLI, you issue the command service-module wlan-ap0 session command on the router CLI, and you get a telnet session on the wireless CLI. After I configured and hardened the wireless IOS, the ports were still open. The service-module wlan-ap0 status command displays the following information:

Service Module is Cisco wlan-ap0
Service Module supports session via TTY line 2
Service Module is in Steady state
Service Module reset on error is disabled
Service Module heartbeat-reset is enabled
Getting status from the Service Module, please wait..

  Image path       = flash:/ap801-k9w7-mx.124-21a.JA1/ap801-k9w7-mx.124-21a.JA1
  System uptime    = 1 day, 6 hours, 0 minutes, 51 seconds

Notice that the session is accessible via the router’s TTY line 2. After I put an ACL on this tty (with the router CLI) to deny all traffic not originating from the internal network, all 4 ports were closed on the ADSL interface.

Another detail good to now: when you are connected to tty2, all ports are closed (because you can have only one session on tty2).

Blog at WordPress.com.