Didier Stevens

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.

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.

Friday 23 September 2011

simple-shellcode-generator.py

Filed under: My Software — Didier Stevens @ 9:04

To help the attendees of my Brucon White Hat Shellcode workshop, I wrote a new program to generate simple shellcode. I’m releasing it now.

People regularly ask me for malware so they can test their security setup. First, that’s a bad idea, and second, you can do without.

Why is using malware a bad idea? It’s dangerous and not reliable. Say you use a trojan to test your sandbox. You notice that your machine is not compromised. But is it because your sandbox contained the trojan, or because the trojan failed to execute properly? It might surprise you, but there’s a lot of unreliable malware out in the wild.

So how can you reliably test your sandbox without risking infection, or even worse, have malware escape into your corporate network? Just use simple shellcode that creates a file in a location your sandbox should prevent, like system32.

To generate this shellcode with simple-shellcode-generator.py, create a text file (call it createfile.def) with these 2 lines:

kernel32.dll CreateFileA str 0x0 0x0 0x0 0x2 0x80 0x0
kernel32.dll CloseHandle eax

Each line in this definition file instructs the generator to generate assembler code to lookup the address of the WIN32 API function, and to call it with the arguments you provide. The first column defines the dll that contains the function to call, the second column is the actual API function, and the rest are arguments to this function. The arguments you provide are copied literally into the generated assembler code, except for 3 keywords.
Keyword int is used to represent any DWORD, it will result in the generation of a push 0x0.
Keyword str is used to reserve space for a string, and the address of the string is used as argument.
Keyword pint is user to reserve space for a DWORD, and the address of the DWORD is used as argument.

To generate our shellcode, issue this command:

simple-shellcode-generator.py -o createfile.asm createfile.def

This generates the following assembler code:

; Shellcode generated by simple-shellcode-generator.py
; Generated for NASM assembler (http://www.nasm.us)
; https://DidierStevens.com
; Use at your own risk
;
; History:
;   2011/09/23: generated

BITS 32

KERNEL32_HASH equ 0x000D4E88
KERNEL32_NUMBER_OF_FUNCTIONS equ 2
KERNEL32_CREATEFILEA_HASH equ 0x00067746
KERNEL32_CLOSEHANDLE_HASH equ 0x00067E1A

segment .text
	call geteip
geteip:
	pop ebx

	; Setup environment for kernel32.dll
	lea esi, [KERNEL32_FUNCTIONS_TABLE-geteip+ebx]
	push esi
	lea esi, [KERNEL32_HASHES_TABLE-geteip+ebx]
	push esi
	push KERNEL32_NUMBER_OF_FUNCTIONS
	push KERNEL32_HASH
	call LookupFunctions

	; call to CreateFileA
	push 0x0
	push 0x80
	push 0x2
	push 0x0
	push 0x0
	push 0x0
	lea eax, [STRING1-geteip+ebx]
	push eax
	call [KERNEL32_CREATEFILEA-geteip+ebx]

	; call to CloseHandle
	push eax
	call [KERNEL32_CLOSEHANDLE-geteip+ebx]

	ret

%include "sc-api-functions.asm"

KERNEL32_HASHES_TABLE:
	dd KERNEL32_CREATEFILEA_HASH
	dd KERNEL32_CLOSEHANDLE_HASH

KERNEL32_FUNCTIONS_TABLE:
KERNEL32_CREATEFILEA dd 0x00000000
KERNEL32_CLOSEHANDLE dd 0x00000000

STRING1: db "String 1", 0

You can replace “String 1” on line 57 with the file you want to create: “C:\Windows\System32\testfile.txt”.

This shellcode uses the library sc-api-functions.asm you can find in my shellcode repository.

Download:

simple-shellcode-generator_V0_0_1.zip (https)
MD5: 3A6D00C6EBC1F20589C952817174653E
SHA256: FEFD4059810DA7855CC3CBC6A198FD75607C4F7B7B2F71817689E1520B454C58

Friday 16 September 2011

Quickpost: create-remote-thread.py

Filed under: My Software,Quickpost — Didier Stevens @ 15:17

create-remote-thread.py is a new tool I’ll publish after my White Hat Shellcode workshop at Brucon.

It’s a Python program to create a thread in another process (using CreateRemoteThread), and you can specify the API function to execute.

In the example above, I call SetProcessDEPPolicy with an argument of 1 to force permanent DEP on calc.exe

But there are many more uses for my tool.

 

Friday 9 September 2011

DEP Enforcing Shellcode

Filed under: My Software — Didier Stevens @ 7:25

I developed shellcode that enforces permanent DEP when it is injected inside a process:

This is for my Brucon workshop. More details to be posted later.

BITS 32

KERNEL32_HASH equ 0x000d4e88
KERNEL32_NUMBER_OF_FUNCTIONS equ 1
KERNEL32_SETPROCESSDEPPOLICY_HASH equ 0x06f26f66

PROCESS_DEP_ENABLE equ 1

segment .text
	call geteip
geteip:
	pop ebx

  ; Setup environment
	lea esi, [KERNEL32_FUNCTIONS_TABLE-geteip+ebx]
	push esi
	lea esi, [KERNEL32_HASHES_TABLE-geteip+ebx]
	push esi
	push KERNEL32_NUMBER_OF_FUNCTIONS
	push KERNEL32_HASH
	call LookupFunctions

	; Enable permanent DEP in current process
	push PROCESS_DEP_ENABLE
	call [KERNEL32_SETPROCESSDEPPOLICY-geteip+ebx]

	ret

%include "sc-api-functions.asm"

KERNEL32_HASHES_TABLE:
	dd KERNEL32_SETPROCESSDEPPOLICY_HASH

KERNEL32_FUNCTIONS_TABLE:
KERNEL32_SETPROCESSDEPPOLICY dd 0x00000000

Wednesday 10 August 2011

Force “ASLR” on Shell Extensions

Filed under: My Software,Vulnerabilities — Didier Stevens @ 0:49

I’ve written about Shell Extension without ASLR support before.

Not only do they open up explorer.exe to ROP attacks, but other applications too, like Adobe Reader and Microsoft Office.

You could use EMET to force ASLR on these DLLs, assuming you know which applications load shell extensions. Because shell extensions are not only loaded into explorer.exe, but other programs too, I wrote a tool to force Shell Extension DLLs to load at another address than their base address, effectively simulating ASLR.

When my tool, SE_ASLR.dll, is loaded into a process, it will check for the presence of comdlg32.dll inside the list of loaded modules. When comdlg32.dll is used by an application, the likelihood of shell extensions being loaded into the process by user interaction with the file dialogs is significant.

Hence SE_ASLR will patch the IAT to intercept calls to LdrLoadDll. Each time the application loads a DLL (all DLLs, not only shell extension), SE_ASLR will check if the DLL supports ASLR. If it doesn’t, SE_ASLR will pre-allocate a memory page at the base address of the DLL, thereby forcing the loader to load the DLL at another address.

Although SE_ASLR’s primary goal is to relocate shell extensions, it will effectively relocate all DLLs without ASLR support once SE_ASLR is loaded into the process.

You need to load my tool into all applications that could use shell extension, for example via the AppInit_DLLs registry key. But before you do, be sure to test this out on a test machine. Not all shell extensions support relocation.

SE_ASLR_V0_0_0_1.zip (https)
MD5: 9D6AE1A96D554AEE527EB802FE59FB20
SHA256: 8A6C1406A757CD9788A2630D76A497E2C058333EE4D44CA0B85B2A05A39F257E

« Previous PageNext Page »

Blog at WordPress.com.