Adam Caudill

Security Engineer, Researcher, & Developer

UPEK Windows Password Decryption

On August 28th ElcomSoft announced that they had determined a method to extract Windows passwords from the registry for users of UPEK’s fingerprint readers and Protector Suite software (UPEK is now owned by AuthenTec, which is now owned by Apple). What they didn’t announce was the technical details of how they did it. Myself and Brandon Wilson have been working to recreate their research – and we have.

We have not been in contact with ElcomSoft, so this is an independent re-discovery of this vulnerability. ElcomSoft has committed to not release details, which I understand – but given how likely it is that others will determine this technique, I believe that this information should be available to pen-testers and auditors so that these insecure credentials can be identified.

The Details #

ElcomSoft blasted the security of UPEK’s product, saying:

we found that your Windows account passwords are stored in Windows registry almost in plain text, barely scrambled but not encrypted

This isn’t quite accurate – but certainly close enough. The data is stored in the following location (varies by version):

HKEY_LOCAL_MACHINE\SOFTWARE\Virtual Token\Passport\4.0\Passport\<user>\ExData

The first 24 bytes are header and size information, after the encrypted data there is a 4 byte number that indicates the number of bytes in the next section, the following bytes are used in the IV. The encryption key is ‘generated’ using a PBKDF2-like function that uses MD5 hashing, but unfortunately when storing data in the registry they aren’t using a password – so the outcome is based purely on an MD5 hash that they are using as a ‘seed’ value. This means that the key used is always the same.

Better: the key is only 56 bits.

AES-56 #

On the AuthenTec’s website they mention using 56-bit AES (due to the old export restrictions) – this confused me for quite some time, not only does AES not support 56-bit (or anything else less than 128 bits), from looking at the algorithm trying to make it support a key size that isn’t a multiple of 32 bits would be quite challenging. So how did they do it? They cheated.

They are actually using AES-256, and padding both the 56-bit key and IV with nulls. In other words, they are taking a very strong crypto and stripping it of its value.

The Data #

Besides the Windows password, the data also includes the domain and login (all in Unicode), along with other various bits that’s less interesting from a pen-testing perspective. Looking at the raw data, you can identify the password from the P1 header, 0x11 denotes the login, and 0x12 indicates the domain.

The biometric data may be of some interest, but not to me.

Code #

We’ve posted a proof-of-concept tool to Github, it’s written in C#, and thus requires the .NET 4.0 framework be installed (download here). I also plan to write a Metasploit post module, but it’s not ready yet.

UPDATE #

So it turns out that AuthenTec released a patch for this on 9/18 – and we missed it (as did pretty much everybody else). We were alerted to the patch late on 10/10, and last night (10/11), we completed work on breaking it. We’ve updated the Github repository with the new code, it supports both the old versions and the new version they released on 9/18. They are now using DPAPI (among other things), so if you have the new version, you’ll need to run it in the context of LocalSystem so that you can access the correct encryption keys. This can be done quite easily with psexec – see the README for details.

From a security perspective, the new version is somewhat more secure – but obviously, still easily attacked. They are now using a ‘seed’ of 16 random bytes (which is stored in ExData and protected via DPAPI), which is then hashed with SHA1, the hash is then passed into their key derivation method to produce the 56 bit key that is used to encrypt the main data block. Within the main data block there is another DPAPI block where the password was previously stored – this was something of a surprise to us at first, as they had obfuscated the code to hide this part. This second DPAPI block contains the user’s password, and can be easily decrypted with the same method used to decrypt the block containing the ‘seed’ data.

Both of the DPAPI calls use the same entropy data – a block of 0x86 bytes, at the beginning is the word ‘Software’ and a 0x01 at offset 0x2B and a 0x05 at 0x43 – and as said above, the DPAPI calls are made in the context of the LocalSystem user, and thus needs to be decrypted within that same context.

The new homepass.dll file contains new anti-debugging code, as well as obfuscated code to complicate reverse engineering – fortunately, or unfortunately depending on your point of view – these new ‘protection’ mechanisms are trivial to bypass. To avoid this becoming a cat & mouse game, we won’t be releasing further updates to this code – but I think it’s safe to say that it’s fundamentally broken, and any fixes they release can be bypassed without excessive effort.

I would not trust this software in a corporate environment.

Adam Caudill


Related Posts

  • Dovestones Software AD Self Password Reset (CVE-2015-8267)

    Software AD Self Password Reset v3.0 by Dovestones Software contains a critical vulnerability in the password change functionality, that allows unauthenticated users to change the password of arbitrary accounts. The vendor has been working with customers to upgrade them to a fixed version. The /Reset/ChangePass function doesn’t validate that the validation questions have been answered, or validate that the account in question is enrolled. This allows an attacker to reset any account that the service account is able to reset, even if they aren’t enrolled.

  • Decrypting Spark Saved Passwords

    A friend of mine has been evaluating an open source instant messaging client called Spark, which can be linked to Active Directory for authentication. Like most IM clients, Spark allows users to save their password – and me being me, I was curious as to how it’s doing this – as storing Windows domain logins is kinda a big deal. So, within a few minutes I found all of the details – and none of them make me feel any better.

  • 1Password 8 Early Access: Security, Comments, & FAQs

    A few days ago, 1Password (my employer) released the first preview of the new application for macOS. The response has been rather dramatic. The release was followed by an excellent blog post by Michael Fey explaining the story of how we got here, and some of the decisions that were made in the process. I’d like to now to a few minutes to answer some questions, provide some insight, and share my thoughts on this release.

  • PL/SQL Developer: Nonexistent Encryption

    (See here for another issue discovered during this research; Updates over HTTP & Command Execution.) PL/SQL Developer by Allround Automations has an option to store the user’s logon history with passwords – the passwords are encrypted with a proprietary algorithm. At this point, you should know how this is going to go. For those that don’t know, PL/SQL Developer is a tool for developers and database administrators to access Oracle – an essential tool in many enterprise environments.

  • Breaking the NemucodAES Ransomware

    The Nemucod ransomware has been around, in various incarnations, for some time. Recently a new variant started spreading via email claiming to be from UPS. This new version changed how files are encrypted, clearly in an attempt to fix its prior issue of being able to decrypt files without paying the ransom, and as this is a new version, no decryptor was available1. My friends at Savage Security contacted me to help save the data of one of their clients; I immediately began studying the cryptography related portions of the software, while the Savage Security team was busy looking at other portions.