Didier Stevens

Sunday 31 October 2010

Quickpost: Adding Certificates to the Certificate Store

Filed under: Encryption,Quickpost — Didier Stevens @ 13:31

A couple of people asked me how to get self-signed certificates recognized by Windows.

For example, when you check the digital signature of one of my programs (like ariad.exe), you’ll see this:

The digital signature is valid, but the root certificate used in the signature is not trusted. This is because this root certificate is not installed in the repository of trusted root certificates. I’ll show you how to achieve this, but understand that by installing a new root certificate, you automatically trust all signatures and subordinate certificates issued by this root certificate authority.

The first 2 methods I’ll present add the new root certificate to your own certificate repository (i.e. the one associated with your account). This means that under other user accounts, the new root certificate will not be trusted. The third method explains how to add the new root certificate to the computer’s repository, so that it is trusted by all users.

Say you’ve a root certificate, like one created using this method. Here’s how to install it in your account’s “Trusted Root Certificate Authorities” certificate store:

And from now on, all executables signed by this root certificate authority (or it’s subordinate authorities) are trusted:

As the root certificate we used in this example is good for all purposes, and because your certificate store also integrates with Internet Explorer, SSL certificates issued by this certificate authority will also be trusted by Internet Explorer.

If you don’t have the root certificate to install, you can also get it installed from the AuthentiCode signature like this:

And from here on, you follow the same steps as in the first method;

If you want to install certificates for all users, you’ll need to follow another method. But because this other method requires a certificate file, I’ll show you how to extract a certificate file from an AuthentiCode signature:

Follow the second method to view the root certificate, but instead of installing the certificate, look at the Details tab and export the certificate:

To install a root certificate for all users, you’ll need to start the Microsoft Management Console (mmc.exe) as an administrator:

And now you can import the root certificate following the same steps as in the first method:

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 11 October 2010

PDF, DEP, ASLR and Integrity Levels

Filed under: PDF,Vulnerabilities,Windows 7,Windows Vista — Didier Stevens @ 8:41

Frequently targeted document handling applications should be coded defensively and protect themselves with Windows security features like DEP, ASLR and Integrity Levels, just to name a few.

I tested a couple of PDF rendering applications: Adobe Reader, Foxit Reader and Sumatra PDF. If the application did not use DEP, ASLR or Integrity Levels, I changed some settings to make the application use these features. Setting DEP and ASLR is just setting a flag in the DllCharacteristics member of the Image Optional Header structure. You can do this with a hex editor, a PE-file editor, or a new tool (setdllcharacteristics) I’ll release soon. Using a Low Integrity Level is done by setting the appropriate ACE in the DACL of the application executable, see my post Integrity Levels and DLL Injection for details.

Adobe Reader 9 uses DEP and ASLR. It does not run with a Low Integrity Level by default. Configuring acrord32.exe to run with a Low Integrity Level fails, the application doesn’t run. It is said that the upcoming Adobe Reader 10 with sandboxing technology will run at a Low Integrity Level.

Sumatra PDF 1.1 uses DEP and ASLR. It does not run with a Low Integrity Level by default. Configuring SumatraPDF.exe to run with a Low Integrity Level succeeds, the application runs fine. Some preferences might get lost, but they are not important to me.

With version 4.2 of Foxit Reader released about a week ago, Foxit Software added support for DEP and ASLR. Setting Foxit Reader to use a Low Integrity Level results in a malformed opening dialog box:

Apart from this, Foxit Reader appears to work fine at Low Integrity Level, but don’t be fooled. At Low Integrity Level, Foxit Reader can’t read or set its preferences. For example, you won’t be able to disable JavaScript. Even if you disabled JavaScript with Foxit Reader running at Medium Integrity Level (the default), Foxit Reader running at Low Integrity Level will enable JavaScript. So you’re better off not using a Low Integrity Level for this version. I’ve talked to Foxit Software and they’ll fix this.

If your favorite application isn’t discussed here, you can easily check how it performs with Sysinternals’ Process Explorer. Just add columns DEP, ASLR and Integrity to Process Explorer’s main view and run your application.

Integrity Levels and DLL Injection

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

Blog at WordPress.com.