Firefox Add-ons FTW!

Just a quick post on passwords saved in the browser. After my post on credentials stored in the Windows 7 Vault, I started to think about browser passwords and the risks that lurk there. Chris Gates had a similar thought which he posted about yesterday, and Larry Pesce wrote up a detailed analysis last September.

I personally disable this feature in Firefox but a strong master password would certainly be advisable if you do save passwords within Firefox. While I do not use this feature, I do use a lot of Firefox add-on's. Gmail Notifier, Xmarks Bookmarks, and Echofon Twitter add-on's to name a few. So I naturally turned my attention to those.

I pondered where these add-on's were storing saved credentials. The answer is in same place Firefox stores them. What a more ironic way to verify this than to use a Firefox add-on (SQLLite Manager) to query the signons.sqlite database.

As previously covered by Gates and Pesce, conversion of the encrypted passwords is trivial as long as you also have access to the key3.db and there is no master password configured. If you are interested in the details of this, I suggest checking out the documentation here and tool available here.

While this may have been obvious to others, it was not to me. That is one of the many reasons I love this field.


Update August 09, 2010: Jeremiah Grossman presented his work entitled Breaking Browsers: Hacking Auto-Complete at Black Hat last week. The presentation included examples of using XSS to steal saved credentials in the Firefox and Chrome password managers.

Post Exploitation Pivoting with the Windows 7 Vault

I have been poking around with the updated version of Credential Manager in Windows 7 which has been commonly referred to as "Stored User Names and Passwords" in previous version of Windows. Much like its predecessors, the current version of Credential Manager still uses Data Protection API (DPAPI), but Windows 7 now stores saved credentials within the Windows Vault. Such credentials can include; user names and passwords used to log on to network shares, websites that use Windows Integrated Authentication, Terminal Services, and many third party applications such as Google Talk .

Credential Manager and DPAPI has been under scrutiny in the past. Cain & Able has had a decoder for some time. More recently, researchers from Standford University presented at Black Hat DC 2010 about their DPAPI research.

While breaking the crypto associated with this feature might be useful (i.e. if credentials are re-used elsewhere), it is not always necessary. The purpose of the Credential Manager is to pass saved credentials to resources commonly accessed by the user. Once you have gained access to a host as the unprivileged user  (take you pick of code execution bugs, Adobe pdf's seem to be popular these days), then you can certainly leverage this feature to pivot to resources referenced within the Windows Vault. Keeping a low forensics profile would be preferred, so I attempted to find existing command line tools that were already available on the host. After poking at Windows 7 for a while, I found an undocumented utility called vaultcmd.exe in the System32 folder that appeared useful. The following is the output of the supported switches for vaultcmd;

The /list switch allows us to view all Windows Vaults available on the host for the current authenticated user.

It appears in this example, the two default Vaults are the only ones that exist on this host. Also note that since the user is already authenticated, the vaults are in an unlocked state. Running the /listproperties switch against each vault lists some more details, including the number of credentials saved in each location.

Finally, the /listcreds switch gives us our newly found targets.

It appears, our unprivileged user has stored domain administrator credentials for two domain controllers. While this is certainly more secure than running as domain administrator locally, DPAPI adds no added security in this scenario since local access to this host has been gained. Now that we have completed our reconnaissance, we can pivot and access the servers by simply using the installed tools at our disposal. In the following example, I use psexec and the SET command to verify I have domain administrator access to DC-01 without having to specify a user name and password.

I was also able to access the the domain controller's Admin shares via the NET USE command using stored credentials within the Windows Vault.

net use P: \\dc-01\C$

In addition, since the Windows Server Administrator tools were also already installed on the host, I also verified that the Windows Vault was passing these credentials to Active Directory Users and Computers and the Remote Desktops Client.

I attempted to change some of the default settings for the vault using the /setproperties switch. For Example; it appears that vaultcmd has the ability to set a password on a vault;

vaultcmd  /setproperties:"Windows Vault" /set:AddProtection /value:Password
vaultcmd  /setproperties:"Windows Vault" /set:DefaultProtection /value:Password

But any attempt I made was met with the error; "The request is not supported.". So I would be interested to see if anyone can find additional documentation on this utility or the Windows Vault. I have not been successful in finding anything to date.

Some have suggested that any password management tool that hooks into the browser or operating system is more of a risk than a stand alone application that requires additional authentication mechanisms. While I generally agree with this, the emerging capabilities of attack and forensic tools that acquire volatile memory from a host (and consequently decrypted credentials), only require a bit more patience. Of course such tools, must be loaded on the compromised host increasing the forensic footprint the intruder leaves behind.

Happy Hunting!

Socs vs Greasers: The Pentesting Debate

During the Podcasters Meetup at Shmoocon 2010 a conversation began about the worth of penetration testing in the corporate environment. On one side of the tracks, business folks questioning why it was necessary to active exploit business systems while penetration testers argued for such. The conversation and debate has continued on many mediums since Shmoocon and many involved have made some valid points. I have not heard much from anyone who is in the trenches of security operations, however. Since this is my primary role for the small enterprise I support, I thought I could add some of my own perspective to the discussion.

I am the typical one man security show that is not uncommon within business the size of my employer. I deal with all aspects of security for the organization including vulnerability scanning and penetration testing. Other responsibilities include regulatory compliance, incident response, patch/vulnerability management, and security architecture. So my view on penetration testers and the services they have to offer is the same as any other consultant or contractor that walks through my door. I welcome the second set of eyes and assistance.

The reality is with all aspects of my daily responsibilities, I am going to miss things, make configurations errors, and downright fuck up from time to time. The fact the matter is I get tired, have a family, and often don't know my systems as well as I may think I do. I am a juggling clown balancing on a unicycle with a warped rim riding right down the middle of the train tracks separating these two groups.

This debate is not new and many others have already touched upon some of the pros of penetration testing. Defense in depth by way of post exploitation testing is one such argument that is completely valid. There are a few additional arguments I would like to make in regards to the usefulness of penetration testing, however.

1. Your penetration tester should not be testing things that you know are broken. This wastes the consultant's time, your money, and does no one any good. If you know it is broken, evaluate the risk then fix it or put the appropriate mitigation in place so that it can be tested during the next engagement.
2. Sometimes exploitation is the only way to verify something is broken. The Symantec exploit I blogged about last October is a great example of the risk assessment and patch management process failing within an organization. This was a situation where the only way to verify that a system was vulnerable even though it was patched was to run the POC on it. Such situations, while not the norm, are also not unusual. If you are trusting your Vendors to secure your environment, you are doing it wrong. It should be noted that the vulnerability was weaponized several months later as reported by dshield.org here.
3. Incident Response! You do have an Incident Response plan right? Thought so! Do you review and practice it? What better time to see how well your IR plan works than when you're actively being attacked. A Penetration Test is a great time for the entire team to have a "fire drill" of sorts. I recently had the opportunity to listen to Andy Ellis speak about incident response. Andy serves as Akamai's Senior Director of Information Security and Chief Security Architect. His statements about availability made an impression on me. If your management is really serious about maximizing up time, then you better have a lean, mean Incident Response team. It is not a matter of; if you have a compromise, it is a matter of when, and how well you respond to it.

What about APT do you ask? I will leave you with a recent description of APT from Matt Olney of the VRT Sourcefire team;

APT: There are people smarter than you, they have more resources than you, and they are coming for you. Good luck with that.

Matt's advice includes building a security team with "... at least one very bad person" on it. For the small business security professional, that person is often the penetration tester. Besides they are usually much more fun to have a beer with than senior management.