Didier Stevens

Friday 19 November 2010

Quickpost: Adobe Reader X

Filed under: PDF,Quickpost — Didier Stevens @ 18:03

In case you’ve not read Adobe’s announcement: Adobe Reader X is out. Use Adobe’s FTP server if you want to avoid their download manager.

Protected Mode Adobe Reader comes with a sandbox (like Internet Explorer, Microsoft Office 2010, Google Chrome) designed to prevent malware from writing to important system components.

If you’re interested in the design details of the sandbox, I recommend Kyle Randolph’s excellent series of posts.

To benefit the most of Adobe Reader’s sandbox, you need to use a Windows version that supports integrity levels (Windows Vista or later). Windows XP will not offer you this protection.

And don’t become complacent about patching your sandboxed applications. Because if there exists a vulnerability that allows one to escape from a sandboxed application, say in IE7 Adobe Reader X, then one can use this vulnerability to escape from other sandboxes, like IE7 Adobe Reader X, based on the same low integrity level design.

Quickpost info

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.


NewPasswordStats_V0_0_0_1.zip (https)

MD5: FAF362F49C7B3FA8CCE7AF600B6D91A8

SHA256: 3D9BBD195F55FBB8F6CE523B3E7BE95A531725570336C55911EE0F312FE95A4D

Monday 8 November 2010


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.


EnforcePermanentDEP_V0_0_0_1.zip (https)

MD5: B0A89B0CE8DC5BA2472B3D744D40E4A3

SHA256: 525BA6EF82BD2B0ABD30DAD0D676CE085A9FA6E0DE3E3A8A0ADD6DF050F5A635

Blog at WordPress.com.