Didier Stevens

Tuesday 14 December 2010

HeapLocker: Private Memory Usage Monitoring

Filed under: My Software,Vulnerabilities — Didier Stevens @ 17:30

Explaining how Private Usage Memory Monitoring in HeapLocker works is easy, so let’s start with this technique.

When a malicious document performs a heap spray, allocation of private virtual memory will skyrocket. HeapLocker allows you to set a maximum to the amount of private virtual memory a process is using. If the maximum is exceeded, HeapLocker will suspend the process and inform the user.

To configure HeapLocker to monitor Adobe Reader’s usage of private memory and set a maximum, create these registry keys:

[HKEY_LOCAL_MACHINE\SOFTWARE\DidierStevens\HeapLocker\Applications\AcroRd32.exe]
"PrivateUsageMax"=dword:00000100

This will set the maximum to 256 MB (0x100).

When HeapLocker is loaded inside Acrobat Reader (AcroRd32.exe process), it will find the PrivateUsageMax setting and start a new thread inside the Adobe Reader process. During most of its life, this thread will do nothing (sleep). Every second, it will wake-up and check the amount of private memory allocated by the process (PrivateUsage). If this amount is equal to or larger than the maximum value specified in PrivateUsageMax, the thread will suspend all other threads in the process and display a message box to the user.

The user can decide to terminate the process, or decide to continue using the program. When the user decides to continue, HeapLocker will resume all threads and disable its monitoring of private memory usage for the life of this process.

The user is offered this choice to be able to deal with false positives. If you set your PrivateUsageMax value too low and you open many different documents in the same application, you could exceed the limit without an actual heap spray taking place. For applications that (mostly) just display data, like Adobe Reader and Internet Explorer, this is not a real issue, because no data is lost when you terminate the application. But with Microsoft Word or Excel, you will loose unsaved data when the process is terminated.

If you don’t trust your users to make the right decision when presented with this dialog, you can set registry key ForceTermination to 1. When this key is set, the user will not be offered a choice: the threads are suspended, a message box is displayed with just an OK button, and the application is terminated when the OK button is clicked.

I’ve tested this feature of HeapLocker for several months with Adobe and MS Office, limiting the private usage to 1024 MB. I don’t recommend you use the other HeapLocker techniques yet, I’m still testing these features.

This feature of HeapLocker is compatible with EMET, I’ve used both tools concurrently to protect Adobe Reader.

You can use Process Explorer to get an idea of the private memory usage of your applications.

Monday 6 December 2010

HeapLocker

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

HeapLocker is a new tool I’m releasing to mitigate heap spray attacks. But be patient, don’t use this version (V0.0.0.2) yet for other reasons than experimenting! I’m still testing newer versions that I’ll release soon.

HeapLocker uses 5 mitigation techniques.

1) Like EMET, HeapLocker will pre-allocate virtual memory pages to protect the addresses often used in exploits with heap sprays. HeapLocker can go one step further than EMET: it can inject its own shellcode to warn the user in case of an attack:

2) HeapLocker can also pre-allocate memory page zero, like EMET.

3) To detect heap sprays in action, HeapLocker monitors private memory usage:

4) HeapLocker can monitor the application’s memory for NOP-sleds:

5) The last technique, monitoring the application’s memory for specific strings, proved to be very successful to detect malicious PDF documents:

I will detail these techniques in upcoming posts.

Wednesday 1 December 2010

Runasil

Filed under: My Software,Windows 7,Windows Vista — Didier Stevens @ 9:56

Because I didn’t find a program to start an application with a given integrity level from “Image File Execution Options”, I wrote runasil.

The following command launches notepad.exe with a low integrity level, instructing notepad to open test.txt:

runasil.exe notepad.exe test.txt

To automatically launch notepad via runasil.exe, using “Image File Execution Options”, create this registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\notepad.exe and create a value debugger equal to “runasil.exe -d” (don’t forget option -d).

You can also specify the integrity level via an option:

  • -l for low
  • -m for medium
  • -h for high
  • -s for system

By default, runasil launches the application with a low integrity level.

Don’t forget you need at least Windows Vista to use integrity levels, and that a process can’t create a new process with a higher integrity level than itself.

Download:

runasil_V0_0_0_1.zip (https)

MD5: 5B8CE64715903DD7EEF4AF3B89E6E6FD

SHA256: 15841A9D9985E626C5B70B4BC3B2BF2CD68C38102B6BB1D92BA352D19F5C8A65

Monday 15 November 2010

Password Auditing With a Password Filter

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

A TechEd Europe attendee asked Marcus Murray about password auditing. He expressed his worry about the confidentiality of audited passwords. This question reminded me about an often overlooked feature of Windows: password filters.

A password filter is generally used to implement custom password policies, but can also be used for password auditing and pentesting purposes. It is a DLL loaded by the LSA (on a stand-alone machine or a domain controller) and called each time a new password is set. The DLL is designed to check the new password according to custom password policies, and reply back to the LSA if it accepts the new password or rejects it.

But you could also write a password filter that accepts all passwords, while building statistics about the new passwords or while (secretly) logging them.

I wrote a simple password filter to report on password length. By using this password filter, the passwords never leave the LSA. The main advantage of this password auditing technique is that it will not reveal actual passwords. The disadvantage is that it does not report on existing passwords, but only on new passwords (changing a password or setting an initial password). So it will take some time to report on all passwords, depending on your password expiration policy (assuming you have one).

My password filter builds a histogram of the length of all new passwords, limited to a password length of 14 characters (this is an arbitrary limit and can be changed in the code). This report is written to file C:\NewPasswordStats.txt and looks like this:

0: 1
1: 0
2: 1
3: 0
4: 0
5: 0
6: 0
7: 0
8: 4
9: 0
10: 0
11: 0
12: 0
13: 0
14: 0
>=15: 2

As you can see, my test system has one password of 0 characters long, one of 2 characters long, 4 of 8 characters long, and 2 of 15 or more characters long.

I recommend you change the ACLs of the report so that only admins can read it (or change the code to store the report in an ACLed directory). When the machine is rebooted, the statistics are reset to zero and the last report is renamed to C:\NewPasswordStats.bak. To prevent the loss of your statistics, you need to save this backup before the next reboot.

If you plan to expand my code to build more sophisticated statistics, please keep the integrity of the LSA and the confidentiality of its data in mind. If you pass the passwords around to functions in your code, be sure to erase all confidential data securely after use with SecureZeroMemory. If you plan to provide input to your password filter (for example the previous password statistics after a reboot), be sure to validate your input as to not introduce vulnerabilities in the LSA. And don’t make your statistics so specific that they can be used as a guide to quickly crack your passwords. Think about performance too: the password filters runs inside a critical process, you don’t want it to take too much time to audit/validate a password.

Here’s how to install a password filter. I tested this password filter on Windows XP SP3 and Windows 2003 (domain controller), but not on a production machine, so please use this in a test environment first should you consider using this password filter.

Download:

NewPasswordStats_V0_0_0_1.zip (https)

MD5: FAF362F49C7B3FA8CCE7AF600B6D91A8

SHA256: 3D9BBD195F55FBB8F6CE523B3E7BE95A531725570336C55911EE0F312FE95A4D

Monday 8 November 2010

EnforcePermanentDEP

Filed under: My Software,Windows 7,Windows Vista — Didier Stevens @ 0:45

Like its name reveals, EnforcePermanentDEP is a DLL to switch on permanent DEP in the loading process.

When loaded inside a process, this DLL will call SetProcessDEPPolicy with argument PROCESS_DEP_ENABLE, hereby enabling DEP permanently on the loading process. After this, DEP can’t be disabled anymore for this process.

Once DEP is set, this DLL unloads itself. There is no need for this DLL to remain loaded once it has enabled DEP. This is done via the entry point DllMain function which returns FALSE for DLL_PROCESS_ATTACH, hereby making that the DLL doesn’t remain loaded inside the process.

To load this DLL inside a process, you can add it to the import table of the target process (EnforcePermanentDEP.dll exports function Dummy), use LoadDLLViaAppInit or use your own preferred injection method.

Download:

EnforcePermanentDEP_V0_0_0_1.zip (https)

MD5: B0A89B0CE8DC5BA2472B3D744D40E4A3

SHA256: 525BA6EF82BD2B0ABD30DAD0D676CE085A9FA6E0DE3E3A8A0ADD6DF050F5A635

Tuesday 26 October 2010

Update: LoadDLLViaAppInit

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

This new version of LoadDLLViaAppInit allows you to load more than one DLL inside a process. You separate the DLL names with a semi-colon (;).

For example, to load DLLs hook-createprocess.dll and EnforcePermanentDEP.dll inside process acrord32.exe, you configure this:

acrord32.exe    hook-createprocess.dll;EnforcePermanentDEP.dll

Download:

LoadDLLViaAppInit_V0_0_0_2.zip (https)

MD5: F458DAEAB1A3E68870EE0608E2A1FFFC

SHA256: 9C8BA52A68893F33E0019CC64264C24A7EEC09C5D0DAE6F43C110ACFD45E621F

Sunday 17 October 2010

setdllcharacteristics

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

The PE-file format specifies flags to enable DEP and ASLR. You can set these flags with a hex-editor or a PE-file editor.

Because I need to set DEP and ASLR flags in a script, I wrote a C-program to read, set or clear these flags (together with another flag to check AuthentiCode signatures, more about this later).

It’s a standard C program, you can compile it under *nix too.

The option handling is simple, you can’t combine flags into one option string. For example, to set DEP and ASLR, you issue the following command:

setdllcharacteristics +n +d program.exe

This will not work:

setdllcharacteristics +nd program.exe

Don’t forget that by changing these flags on signed executables, the signature is not valid anymore. But that shouldn’t be a problem to run the program.

Later, I’ll post tools to force DEP (and maybe ASLR) without changing the PE file.

And I also updated the PE-file format template for the 010 editor to support these 3 flags.

Download:

setdllcharacteristics_v0_0_0_1.zip (https)

MD5: F96358BF90AA4D8C6B32968B2068BFCB

SHA256: 5A9D3815F317C7C0FF7737F271CE0C60BE2CB0F4168C5EA5AD8CEF84AD718577

Monday 4 October 2010

LowerMyRights

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

Last year I posted about some techniques and tools to restrict the rights of applications on Windows XP when you run with admin rights. I mentioned a new tool, LowerMyRights, which I forgot to publish. So here it is.

You would use LowerMyRights.dll only if the other tools and techniques are not appropriate for your specific case. LowerMyRights is useful when you can’t create a new process with restricted rights, but when you’ve to restrict the rights of an existing process.

When this DLL is loaded inside an existing process, it will check a whitelist and a blacklist to decide if it has to restrict the process’ rights (it also checks if it’s running on Windows XP). If the application’s name if found in the blacklist and not in the whitelist, LowerMyRights will do its job.

First, it will remove all the privileges of the primary token, except the SEChangeNotifyPrivilege.

Second, it will create a restricted token (with ACLs denying Administrator and Power Users rights) and use this token for impersonation (it uses impersonation because Windows doesn’t allow modifications to the ACLs of a primary token).

This impersonation is also a weak point of LowerMyRights compared with the other tools: exploit code can switch back to the unrestricted primary token by calling RevertToSelf.

You can load LowerMyRights inside all processes by adding it to the AppInit_DLL registry key, but be careful, this might cripple your system as it is loaded inside every process (even at boot time), so please test first.
Or else you use LoadDLLViaAppInit, or add it to the import table like explained here.

The whitelist (lowermyrights.wl.txt) is just a text file with a list of applications to whitelist (i.e. not lower the rights). You must use full pathnames in the whitelist.
The blacklist (lowermyrights.bl.txt) is just a text file with a list of applications to blacklist (i.e. to lower the rights). You must not use full pathnames in the whitelist, but just the application’s name.
The idea I had with this different operation of the whitelist and blacklist, is that you would be able to whitelist specific applications while blacklisting copies/fakes of these applications.
An example with notepad will make this clear: by adding c:\windows\system32\notepad.exe to the whitelist and notepad.exe to the blacklist, you would be able to use the original notepad.exe with full rights, while copies of notepad (located at other locations) or other programs with the name notepad.exe would be restricted. With hindsight, I don’t think this dual list feature is useful, but I left it in anyways (the program is a year old, I used it for a year and I haven’t modified it).

Download:

LowerMyRights_V0_0_0_3.zip (https)

MD5: FF937173AB1CD2C7A9DF050D7ADF0696

SHA256: 9AA83F24031029F60862CAAE477B02DF0C0887BD6E9078A1E186FEF6DF873253

Monday 13 September 2010

RunInsideLimitedJob

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

Here’s another tool to mitigate exploitation of vulnerable (office) applications.

I discovered Job Objects in this book. Job objects allow processes to be grouped and managed together.

An interesting aspect of job objects for securing applications is the ActiveProcessLimit property. With this, you can limit the number of processes running inside the job object. Set this limit to 1 and run an office application inside the job object, and the office application will not be able to start another program. Because once a process is assigned to a job object, all its child processes are also assigned to the job object. Processes can’t change the limits of the job object they are running in, and once a process is assigned to a job object, it can’t be removed from this job object or assigned to another job object. So once a process is assigned to a job object, it is trapped inside and constrained by the limits of the job object.

To prevent a vulnerable application from launching malware, put the vulnerable application inside a job object and limit the number of processes to 1. And the good news is that job objects were introduced with Windows 2000, so this works on Windows XP too.

RunInsideLimitedJob is a program I wrote to constrain programs with a job object. There are 2 versions: an .EXE and a .DLL.

RunInsideLimitedJob.exe takes one argument: the program you want to restrict. It creates a new job object, restricts the number of processes to 1, starts the program you passed as an argument and assigns it to the new job object. If you want to allow more than 1 process, use option -n.

While RunInsideLimitedJob.exe is for new processes, RunInsideLimitedJob.dll is for existing processes. When this DLL is loaded in a running process, it will create a new job object, restrict the number of processes to 1, and assign its host process to the new job object (assuming the host process is not yet assigned to a job object).

There are several ways to automatically load RunInsideLimitedJob.dll in your favorite office application, like my tool  LoadDLLViaAppInit or by importing RunInsideLimitedJob.dll’s dummy function as explained here.

Here I started notepad inside a restricted job object, and then tried to start calc.exe from notepad.exe (via the open file dialog box):

Process Explorer supports job objects. It highlights processes assigned to job objects in brown, and it adds a Job tab to the properties of these processes.

If you try this with my tool, you won’t see the process highlighted brown or the Jobs tab in Process Explorer. Process Explorer does not display the job info when the handle to the job has been closed (the screenshots above are with a modified version of my tool that doesn’t exit and leaves the job handle open). I don’t know yet if this is a bug or a feature in Process Explorer. I need to find out.

The runas command also uses job objects, and these do appear in Process Explorer.

Download:

RunInsideLimitedJob_V0_0_0_1.zip (https)

MD5: 90055BA2928D06EC7A883DEF6E7F37C6

SHA256: EF88A2963436F5893727A90413CE624B473352190E936E35EEF85E246655486D

Friday 3 September 2010

PDFTemplate

Filed under: My Software,PDF — Didier Stevens @ 10:36

I’m starting a series of posts with new PDF tools and new versions of my PDF tools as preparation to my Brucon workshop.

Here is a PDF template for the 010 Editor. It’s particularly useful for malformed PDF files, like this example with PDFUnknown structures:

« Previous Page — Next Page »

Blog at WordPress.com.