Home > Information > Blog > Show blog article
Show blog article
03.10.2014
Passcape Wordlist Collection
Over 3 Gb of new dictionaries were added
29.09.2014
Wireless Password Recovery v3.4
Improved performance processing a big list of WPA hashes
11.09.2014
Windows Password Recovery v9.8.0
Speed improvement brute-forcing a big list of hashes, animated reports, etc.
14.08.2014
Reset Windows Password v4.2
with SYSKEY password lookup feature

Articles and video

You may find it helpful to read our articles on Windows security and password recovery examples. Video section contains a number of movies about our programs in action

Vulnerability of DPAPI data protection in Win2K, Win2K3, Windows Server 2008, and Windows Server 2012

16:27:51 10.06.2014 posted by Passcape_Admin at 16:27:51 10.06.2014

Brief description of the vulnerability

Technical details

Utilizing the vulnerability

Conclusion


View this article in pdf format


Brief description of the vulnerability:
The problem

One of our previous articles described the operating principles of the DPAPI system, its exceptional reliability, functional value, and cracking resistance. Not long ago, our support team received a message from Michael Clark, who had discovered that some DPAPI blobs were having decryption issues. After determining the cause of the problem (thanks to Michael, who has provided us with exhaustive information necessary for the analysis), we have revealed a rather interesting breach in the security system of DPAPI which seems common to all server operating systems, beginning with Win2K and ending with Windows Server 2012.

Briefly, the essence of it is the following: By default, the Master Keys of all domain users with interactive logon privileges, except for built-in accounts, are created in the Windows 2000 compatibility mode; therefore, the decryption of the data encrypted with DPAPI doesn't require the owner's logon password.



Brief description of the vulnerability:
Affected software

This means that any Administrator or any other user who has physical access to the server can decrypt the following personal data of vulnerable user accounts:

  • Passwords and form auto-completion data in the popular browsers: Internet Explorer,Google Chrome, Opera Browser, etc.
  • E-mail account passwords in Outlook,Windows Mail,Windows Live Mail, etc.
  • Account passwords of the Windows FTP manager
  • Access passwords to shared folders and resources
  • Keys and passwords to wireless networks
  • Encryption keys in Windows CardSpace
  • Encryption keys in Windows Vault
  • Remote desktop connection passwords
  • .NET Passport passwords
  • Windows Live ID personal data
  • Private keys in encrypting file system (EFS)
  • Encryption keys in S-MIME mail
  • Users' certificates
  • Private data in the Internet Information Services
  • EAP/TLS and 802.1x authentication
  • Network passwords in the Credential Manager
  • Personal data in any application, programmatically protected with the Windows API function CryptProtectData, such as Skype,Windows Rights Management Services,Windows Media, MSN messenger, Google Talk, etc.


Technical details:
DPAPI encryption in Windows XP and higher OSes

This is what the process of decrypting private data encrypted with DPAPI looks like (some details are omitted): Initially, the data owner's logon password is passed through SHA-1 to get the password hash; the password hash and the owner's SID are then fed to PBKDF2 function. At the output, that produces a prekey, which participates in the decryption of the Master Key. The decrypted Master Key in its turn is used for the decryption of the actual DPAPI blobs. Here is what it looks like in a chart:

DPAPI encryption in Windows XP and higher OSes



Technical details:
DPAPI encryption in OS Windows 2000

The first implementation of DPAPI used in Windows 2000 had other Master Key encryption algorithms. But that wasn't what has made it extremely vulnerable; it was the fact that in order to obtain the user's password hash, it used MD4 hashing function instead of SHA-1. Here is what it looks like:

DPAPI encryption in Windows 2000

Amusingly, the same hashing function is also used in validating users' logon passwords, the hashes of which are stored either in the SAM registry or in the Active Directory (for server operating systems). Thus, the user's plaintext password is not really necessary do decrypt the Master Key. It is sufficient to just take an existing MD4 hash of the respective user from SAM or NTDS.DIT and use it as data-in. The rest is already known.



Technical details:
DPAPI encryption flaw in Windows 2003, 2008, 2012 server OSes

Which algorithm is used – SHA-1 or MD4 – is specified in the header of the Master Key. Bit 4 of the dwPolicy flag indicates that the Master Key uses the SHA-1 algorithm. Newly created users with interactive logon privileges in Windows server OSes do not have this flag set by default. Respectively, the decryption of their private data doesn't require the logon password.

DPAPI security flaw



Utilizing the vulnerability:
Creating an interactive domain user in Windows 2012 server

Let's move on from theory to practice and try adding a new user to a Windows Server 2012 domain, then create some DPAPI secret and then decrypting it offline without the owner's logon password.

Open the “Active Directory Users and Computers” console and create a new domain user named Test. Grant that user an interactive logon privilege. To do so, you can simply add that user to the local administrators group.



Utilizing the vulnerability:
Creating the Master Key and DPAPI secret for the new user

Now we need to log off the system and then logon under this account. The new account doesn't have the Master Key yet. It will be created during the first call of the CryptProtectData function.We'll speed that process up by forcing the call for the respective function. For that purpose, we have a homonymous utility CryptProtectData.exe, which simply calls the API function CryptProtectData with command-line parameters (the utility source code is available on the website). Launch it with the following parameters: CryptProtectData mysupersecret out.dat. At the output,we'll have the out.dat file with a DPAPI blob containing our encrypted text (mysupersecret).

So, the Master Key has been created and stored in the folder
C:\Users\test\AppData\Roaming\Microsoft\Protect\<SID>\<mk>
Where <SID> – the owner's sid.We'll still need it, so either memorize it or copy the entire catalog.
<mk> – name of DPAPIMaster Key; e.g., 6cdd0a92-eacc-4a6a-9af5-263ba1afdbf5

Other than that, for the offline decryption of the out.dat file we'll need the MD4 hash of the data owner, which is stored in the Active Directory. To get it, we'll take advantage of our utility and make a copy of the NTDS.DIT file, as well as a copy the SYSTEM registry required for obtaining the hash.



Utilizing the vulnerability:
Decrypting the user DPAPI secret without knowing the owner logon password

As the result, we'll have:

  • The out.dat file with the encrypted secret, which we need to decrypt
  • The data owner's textual SID
  • His Master Key
  • The owner's hash (files NTDS.DIT and SYSTEM).

DPAPI offline decoder
Now, launch the DPAPI offline decryption utility and tell it the path to the out.dat file.



DPAPI offline recovery: setting Master Key
On the second step of the Wizard, specify the path to the data owner's Master Key: select the path and then click Next. The program pops a warning that a vulnerability is found in the Master Key, and therefore the decryption can be carried out two ways: with the user's password and without it.We, certainly, want the latter.



DPAPI offline recovery: setting NTDS.DIT and SYSTEM
So, on the next step of the Wizard, enter the owner's SID and the path to the NTDS.DIT and SYSTEM files, leaving the password field blank.



DPAPI offline recovery: decrypted secret
Click Next, and here we have the decrypted secret. As you can see, the owner's password wasn't necessary.



Conclusion

What remains quite unclear is whether this flaw in the interactive users is related to an error or it shouldn't be treated as such. Perhaps this is a peculiarity of the DPAPI implementation in the server operating systems; for instance, to provide backward compatibility. On the other hand, this seems to be highly unlikely, as the safety of user's confidential data is not properly ensured, while DPAPI was specifically meant to be the data protection system based on the owner's password. Funny, but it turns out that desktop PCs are more resistant to offline password recovery than those running the server operating systems. One way or the other, system administrators should be aware of this vulnerability, as forewarned is forearmed.




BlinkList (http://www.blinklist.com) Blogmarks (http://www.blogmarks.net) del.icio.ous (http://del.icio.us) Digg (http://www.digg.com) Facebook (http://www.facebook.com) Folkd (http://www.folkd.com) Furl (http://www.furl.net) Google Bookmarks (http://www.google.com/bookmarks/) Linkarena (http://www.linkarena.com) Livejournal (http://www.livejournal.com) Mister Wong (http://www.mister-wong.com) Newsvine (http://www.newsvine.com) reddit (http://www.reddit.com/) Squidoo (http://www.squidoo.com) Stumble Upon (http://www.stumbleupon.com) Technorati (http://www.technorati.com) Twitter (http://twitter.com/) Webnews (http://www.webnews.de) Yahoo My Web (http://myweb2.search.yahoo.com) Yigg (http://www.yigg.de) 
Rating
Current rating RatingRatingRatingRatingRating
Avarage rating Ø 7.00
Number of votes 8
Your vote Rate this message: 1Rate this message: 2Rate this message: 3Rate this message: 4Rate this message: 5Rate this message: 6Rate this message: 7Rate this message: 8Rate this message: 9Rate this message: 10

Comments

Disable LM hash
posted by Ugljesa Novak at 18:06:26 05.08.2014
Maybe you can prevent Windows from storing a LAN manager hash of your password in Active Directory and local SAM databases and thus for DPAPI to use SHA-1?

Microsoft article: http://support.microsoft.com/kb/299656
Passcape_Admin
RE: Disable LM hash
posted by Passcape_Admin at 08:59:44 06.08.2014
Well, actually it's not difficult to add the feature. But it may be dangerous because an inexperienced user can turn off backward compatibility and ruine a server, for example. I think, it is better to left it up to Admin.
What about DPAPI and SHA-1. It appears that things are even worse than described in the article. It it funny but new version of our software can decrypt any DPAPI blob of any domain user without knowing the owner logon password. The decryption key (for all users) are stored in Active Directory. So anyone who has access to AD (in a domain) can decode and view DPAPI secrets of other users.
Add comment

Spamprotection