Didier Stevens

Friday 1 January 2010

The Undeletable SafeBoot Key

Filed under: Malware, My Software — Didier Stevens @ 12:53

I present you a new program to create the SafeBoot registry key with special permissions protecting it from deletion. After using this new program, you’ll be able to restore the SafeBoot registry keys with my .REG files.

Many malware deletes the SafeBoot registry key to prevent you from booting into Safe Mode. I provide a registry fix to restore these keys.

But there exists malware that goes even further and actively monitors the registry to thwart every attempt to restore the keys by deleting them as soon as they are restored. Untill now, I recommended to use a Live CD to restore the keys in such a case (this is a complex procedure). This way, the malware is not running while you restore the SafeBoot keys.

Now I developed another solution: a program to create the SafeBoot registry key with permissions to deny Administrators and System accounts to delete the key. This way, the malware can’t delete the keys because it lacks the permissions to do so.

Here are the SafeBoot permissions on a default Windows XP install:

And here are the permissions of the SafeBoot key created with my new program:

I designed my program to create the SafeBoot key only when it is missing, and to set the special permissions while it is created:

My program will not set the special permissions when the key exists. If the SafeBoot keys exists and you can’t boot into Safe Mode, you’re dealing with another issue than a Safe Mode disabling malware (probably a buggy driver).

The program is a console program, but it will pause at the end so you can read its output, even when you launch it from Windows Explorer (i.e. double-click it). If you want to use it in a script and prevent the prompt from appearing, use option -n.

If the SafeBoot key exists, my program will tell this (SYSTEM\CurrentControlSet\Control\SafeBoot exists.) and it will leave the permissions unchanged. If your system is clean but you want to protect the SafeBoot keys, I recommend you change the permissions manually using RegEdit.

My program creates only registry key SYSTEM\CurrentControlSet\Control\SafeBoot, and not the subkeys. To restore the subkeys, you just need to use the appropriate .REG file.

Having read this, you might have thought that malware authors could bypass this protection by changing the permissions before deleting the keys. You’re right. I don’t deny Administrator and System accounts the permission to change the permissions, because I don’t expect there is malware in the wild that changes permissions of the SafeBoot key. I’ll deal with it when it eventually appears.

Download:

UndeletableSafebootKey_V0_0_0_1.zip (https)

MD5: 2FAC291AD547657E31B157B8581D4601

SHA256: 7A1E42A57BBF8E804491318671AE992947C82DCC9C2001E3033B45E4AEAB2DDE

Wednesday 23 December 2009

LoadDLLViaAppInit

Filed under: My Software — Didier Stevens @ 12:20

How do you load a DLL in every new process on a Windows machine? One way to do this is the AppInit_DLLs registry key (this key is frequently abused by malware). Every new process loading user32.dll, also loads the DLLs listed in AppInit_DLLs on startup.

But you can’t use this key to load hook-createprocess.dll, because it will load it in every process, and your Windows machine will stop working.

To selectively load DLLs, I developed a new DLL: LoadDLLViaAppInit.dll. Copy LoadDLLViaAppInit.dll to system32 and add it to the AppInit_DLLs registry key (HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows). This way it gets loaded in every new process. LoadDLLViaAppInit.dll will consult config file LoadDLLViaAppInit.bl.txt in system32, this config file contains the list of processes we want to load a particular DLL into. Here’s an example:

acrord32.exe    hook-createprocess.dll
winword.exe    hook-createprocess.dll
excel.exe    hook-createprocess.dll
powerpnt.exe    hook-createprocess.dll

This config file instructs LoadDLLViaAppInit.dll to load hook-createprocess.dll into Adobe Acrobat (acrord32.exe) and Microsoft Office (Word, Excel and PowerPoint). Important remark: the separator between the executable name and the dll name must be a TAB character. For debugging purposes, LoadDLLViaAppInit.dll logs the DLLs it loads to the debug console.

If you want to prevent a DLL from being loaded (for example to allow Adobe Reader to update itself), you’ll just have to temporarily modify the config file. And be careful with this tool, a wrong configuration can render your machine unusable (for example, if you load hook-createprocess.dll into every process, Windows won’t be able to create new processes).

Be sure to allow only administrators to write to the config file, otherwise you’re opening your machine to elevation attacks.

Starting with Windows Vista, AppInit_DLLs is not enabled by default for security reasons (it’s used a lot by malware). To enable it, you’ve to set the value of LoadAppInit_DLLs to 1. But be aware that this makes your Windows Vista (and later) machine less secure, as from then on, malware will also be able to use AppInit_DLLs to autorun.

Download:

LoadDLLViaAppInit_V0_0_0_1.zip (https)

MD5: 60B93BAF4B0F973C3EC920F2F4A180E8

SHA256: 3B528A3BAF593A2740D5655CF18BC0932801D4DF1750DE8F9C8229C0FF51E8BE

Friday 4 December 2009

Quickpost: New EICARgen Version

Filed under: My Software, Quickpost — Didier Stevens @ 14:58

I never expected to release a new version of EICARgen, but I’m forced to: EICARgen.exe generates just too many false positives.

The new version contains the EICAR string an XOR-encode string (key 0xFF). It has only a couple of detections. Kaspersky and VBA32 shouldn’t actually detect this. EICAR clearly specifies that the presence of the EICAR test string inside a file (like an executable) shouldn’t be detected. As to why AVG needs to detect EICAR test file droppers, I have no idea…

Quickpost info

Sunday 22 November 2009

Quickpost: SelectMyParent or Playing With the Windows Process Tree

Filed under: Forensics, My Software, Windows 7, Windows Vista — Didier Stevens @ 20:36

I read something very interesting in “Windows via C/C++” today: starting with Windows Vista, CreateProcess can start a program where you specify the parent process! This is something forensic investigators must be aware of when they analyse processes running on a Windows machine.

Normally the parent process of a new process is the process that created the new process (via CreateProcess). But when using STARTUPINFOEX with the right LPPROC_THREAD_ATTRIBUTE_LIST to create a process, you can arbitrarely specify the parent process, provided you have the rights (i.e. it’s your process or you have debug rights).

I developed a small tool to start a program while specifying its parent process: SelectMyParent. Here I use it to start notepad as a child of lsass.exe:

2 remarks about this example:

  1. to make lsass.exe a parent process, you need to use SelectMyParent with admin rights and elevate its rights (Run as administrator)
  2. the notepad process takes over the parent process’ account: NT AUTHORITY\SYSTEM

I don’t know how one can detect that a process’ parent is not the process that created it, because a process has no access to its extended startup info (only to its startup info). And it is the extended startup info that contains the attribute list with the handle to the parent process.

SelectMyParent version 0.0.0.1 is available here.

Quickpost info

 

Thursday 19 November 2009

Update: bpmtk with hook-createprocess.dll

Filed under: Hacking, My Software, PDF, Update, bpmtk — Didier Stevens @ 19:32

There are no real changes in this new version of bpmtk, only a new DLL (hook-createprocess.dll) was added. You can use this DLL to protect your Windows machine from getting infected by the current malicious documents found in-the-wild.

You can download bpmtk version 0.1.6.0 here.

Hook-createprocess.dll is a DLL that patches the process into which it is loaded to prevent it from creating new processes. It does this by patching the Import Address Table of kernel32.dll for ntdll.dll to hook API functions NtCreateProcessEx, NtCreateProcess and NtCreateUserProcess.
Calls to these functions are intercepted and not passed on to the original functions. Instead, a code is returned indicating that the operation was blocked. The result is that functions in kernel32 used to create new processes fail (like WinExec) and hence that the patched process can’t create new processes.
This is all it takes to block most shellcode found in malicious documents like PDF malware. Shellcode like this does the following:


Of course, since this protective measure is taken by patching the process, shellcode could undo this patching and bypass our protection. Or it could use the ntdll API and not be hindered by our patch. But actual malware found in-the-wild doesn’t do this (not talking about targeted attacks) and is thus prevented from executing the trojan it just downloaded or extracted from the PDF document.

If you want better protection, you’ll have to use something that works at the level of the kernel, like sandboxing software.

However, this patch comes with some drawbacks, because it also blocks bening new processes. For example, the update function of Adobe Acrobat requires the creation of a new process. To reenable the creation of processes, you have to unload hook-createprocess.dll (unloading removes the hooks). bpmtk has a function to unload DLLs from a process (reject).

There are a couple of trick to load this DLL with the program you want to protect. I’ll describe a generic method in an upcoming post, but now I want to explain it for a specific program.
Programs have a list of DLLs they need for their execution. We will use a PE-file editor to add our hook-createprocess.dll to this list. hook-createprocess.dll exports a dummy function (_Dummy) just so you can add to the imports table of an executable. We will use LordPE to add hook-createprocess.dll with _Dummy to Adobe Reader:

Right-click the Import table:

And don’t forget to save…

Monday 9 November 2009

Quickpost: “Hiding” a PDF Document

Filed under: Entertainment, My Software, PDF, Quickpost — Didier Stevens @ 15:00

Here’s some Python code (it uses my mPDF module) to append a new PDF document to an existing PDF document to “hide” the original document. Recovering the original is trivial, you open the PDF document with a HEX-editor and delete the appended document (starting after the second %%EOF counting from the end of the file). This trick uses incremental updates.

20091107-172245

#!/usr/bin/python

__description__ = 'make-pdf-hide-original, use it to "hide" the original PDF document'
__author__ = 'Didier Stevens'
__version__ = '0.0.1'
__date__ = '2009/11/07'

"""
Source code put in public domain by Didier Stevens, no Copyright

https://DidierStevens.com

Use at your own risk

History:
 2009/11/07: start

Todo:

"""

import mPDF
import time
import zlib
import optparse

def Main():
    oParser = optparse.OptionParser(usage='usage: %prog [options] pdf-file\n' + __description__, version='%prog ' + __version__)
    oParser.add_option('-s', '--line', default='Hello World', help='The line of text to print on the screen (default Hello World')
    (options, args) = oParser.parse_args()

    if len(args) != 1:
        oParser.print_help()
        print ''
        print '  %s' % __description__
        print '  Source code put in the public domain by Didier Stevens, no Copyright'
        print '  Use at your own risk'
        print '  https://DidierStevens.com'

    else:
        pdffile = args[0]
        oPDF = mPDF.cPDF(pdffile)
        oPDF.template1()
        oPDF.stream(5, 0, 'BT /F1 24 Tf 100 700 Td (%s) Tj ET' % options.line)
        oPDF.xrefAndTrailer('1 0 R')

if __name__ == '__main__':
   Main()
Quickpost info

 

Wednesday 21 October 2009

A Windows 7 Launch Party Trick!

Filed under: Entertainment, Forensics, My Software, Windows 7 — Didier Stevens @ 17:19

In search of a new trick for that Windows 7 Launch Party you’re invited to? ;-)

Here’s one:

20091021-190621

You can download a beta version of my UserAssist tool here. Soon I’ll be posting a final version with details and source code.

Wednesday 14 October 2009

Update: WhoAmI? Version 0.1.3

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

I’ve updated my WhoAmI? Firefox add-on for Firefox version 3.5.

You can download it here or get it from the Mozilla site. I’ve nominated it to leave the Sandbox. If you use it, please post a review on the Mozilla page to help it on its way out of the the Sandbox (or keep it there if it’s too buggy).

Tuesday 13 October 2009

Update: PDFiD Version 0.0.9 to Detect Another Adobe 0Day

Filed under: My Software, PDF, Vulnerabilities — Didier Stevens @ 21:23

PDFiD is updated to detect the latest Adobe 0day, CVE-2009-3459.

I’ll provide more details in an upcoming post, just now for know that PDFiD detects a /Colors name followed by a very big number (larger than 2^24 or 16777216).

pdfid009

You can download PDFiD here.

Monday 5 October 2009

Preventing Applications From Starting (Malicious) Applications

Filed under: Malware, My Software, PDF, Vulnerabilities, bpmtk — Didier Stevens @ 0:00

Another very effective way to prevent malicious documents from infecting PCs, is to prevent vulnerable applications from starting other applications. As almost all shellcode found in malicious documents in-the-wild (again, I’m excluding targeted attacks) will ultimately start another process to execute the trojan, blocking this will prevent the trojan from executing.

This is an old idea you’ll find implemented in many sandboxes and HIPS. I added a new DLL to my basic process manipulation tool kit to prevent applications from creating a new process. Loading this DLL inside a process will prevent this process from creating a new process. I’ll explain the technique used in my DLL and how to load it in vulnerable applications in upcoming blogposts, but I want to start with showing how it prevents malicious documents from infecting a PC.

When the DLL is loaded inside a process, it will patch the Create Process API to intercept and block calls to it:

hook-createprocess-010

As a first test, we’ll use my eicar.pdf document.

hook-createprocess-009

Clicking the button will save the eicar.txt file to a temporary folder and launch the editor.

Adobe Acrobat reader will warn you when an application is to be launched:

hook-createprocess-011

But when you accept, the editor will be prevented to execute:

hook-createprocess-012

That’s because the DLL intercepted and blocked the Create Process call:

hook-createprocess-013

As a second test, let’s use a real malicious PDF document. The hooks installed by the DLL prevent it from executing the trojan:

hook-createprocess-014

Adobe Reader starts and then just crashes, without spawning another process:

hook-createprocess-017

When opening the same malicious PDF, but without the protecting DLL, the machine gets trojaned (execution of 1.exe and Internet Explorer):

hook-createprocess-018

This simple way of preventing applications from launching other applications comes with some drawbacks. For example, the Check Update function in Adobe Reader will not function anymore.

When you have a sandboxing system of HIPS installed on the machines you manage, check if you can use it to prevent vulnerable applications from starting other applications. If it doesn’t provide such a feature, try the new DLL I’ll be posting in the new version of bpmtk.

« Previous Page — Next Page »

Blog at WordPress.com.