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.

Monday 15 November 2010

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:

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.

Monday 8 November 2010

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.