Search This Blog

Happy DPAPI!

Last October, I participated as speaker at the SANS DFIR Summit in Prague. It was a great meeting and I am very happy to have been able to participate. My speech was focused on DPAPI, the WindowsData Protection API, and how it could be used during a post-mortem digital investigation to access protected information: overcoming system's security it's sometimes necessary to access data otherwise not available. I like to call this "process" ODI, Offensive Digital Investigations.

I want to be brief, skipping any DPAPI introduction and only providing some links for readers who don't know what DPAPI might be. Consider simply the fact that the technology was introduced with Windows2000(!!) and you and/or your system/applications use it every day... Moreover, if you wonder how wifi passwords are protected, how IE or Chrome treats saved credentials, how Dropbox encrypts its databases, how iCloud protects user credentials, how EFS (Encrypting File System) gets unlocked and so how your private asymmetric key is safeguarded... then you need to know what DPAPI is and how it works. You can download my slides "Give Me the Password and I'll Rule the World" from here and this is the links list:

The last work is an awesome research made by Elie Bursztein and Jean-Michel Picod, who first published DPAPI intimate details. They even provided dpapick, an Open Source Python tool able to offline decrypt DPAPI blobs (aka the encrypted information) up to Windows Vista. Their work is a milestone to deeply understand this technology, and it was my entrance and reference when I started to dig inside DPAPI. For this reason I decided to try improving dpapick by adding Windows7 and Windows 8.1 support: after some nights inside WinDbg, I was able to decrypt blobs coming from these systems, just in time for the SANS conference. Then Jean-Michel took my patch, refactored the code and added some other cool features, releasing the dpapick version 0.3 in the middle of October: check the new features added in his blog post here.

Just a note on Windows 8.1: DPAPI decryption is supported only for local accounts, not for online accounts. As you can read here, "[DPAPI is] used to encrypt and decrypt static data on a single computer. Cloud computing, however, often requires that content encrypted on one computer be decrypted on another": so Microsoft introduced DPAPI-NG to allow sharing of secrets/whatever on different computers, after proper authentication and authorization. DPAPI-NG is used when working with online user accounts, and it's not currently supported by dpapick.

Ideally this post should have been published few days after the meeting, anyway it's here: some examples on how you can use dpapick to access data protected by DPAPI tech.

prerequisites

First, you must download the dpapick version 0.3 from bitbucket (the zip file or the mercurial clone) or (cool news) install from pypi! The pro with the installation option is that it will take care of dependencies, otherwise you must set the correct PYTHONPATH and provide the 3rd part packages: dpapick itself is pure Python, so no issues with the OS you're using. In the post examples, I used both Linux and Windows.

Second, you should have a Windows OS mounted somewhere: I'll use the vmdk virtual disk files coming from the Windows 8.1 and Windows 7 VmWare guests I used during the reverse engineering phase. Alternatively you should extract the needed files from your target Windows and place them wherever you prefer.

Besides that, you should know that user's login password is the main key that unlocks user's masterkeys and allows later blobs decryption; that the system has its own secrets protected with a system password. In the first case the password should be only in user mind; in the second case the password must be inside (or, at least, known to) the system, so no security at all...

no more (lsa) secrets

One of the cool features added is the capability to decrypt Windows7-8.1 LSA secrets (credits to mimikatz too): this feature is needed to grab the system key (DPAPI_SYSTEM) used by Windows to dpapi-protect some info. Moreover it could expose some other interesting info. Let's use the script lsasecrets in dpapick folder "examples": in the first instance use '--hex' to avoid unpleasant string conversion errors, it's not all a string there (note that command and parameters used are splitted on more lines to ease reading).

The DPAPI_SYSTEM value it's the data needed to unlock system masterkeys and to decrypt system blobs. Then we were able to get NL$KM value, used by Windows to encrypt domain cached credentials, and... what? DefaultPassword (aka user auto-logon password)? I can't figure out why it's there, perhaps VmWare easy-install? Anyway, let's get only those values.

Ok, 'fuffa' is the current user password and 'ROOT#123' the old password. That's a windfall, since getting the user password in this way it's too easy... and so we'll able to unlock DPAPI for the user. Later we'll see another way to unlock user DPAPI.

wifi credentials

Let's see an example of system's secret, wifi credentials. As you should know, when you connect to a wifi network with the right password, this data will be saved inside your os (together with other info) for later reuse: a sort of SSO. This storage is not per-user, but system wide and the passwords are protected with DPAPI: you need the DPAPI_SYSTEM "secret" to decrypt them.

I just realized the current dpapick has not scripts to handle this task, so I wrote the following one which will provide wifi credentials (just wifi name and password): I called it wiffy, to train my talent in providing cool names... As is as usual, just quick&dirty coding.

Let's execute wiffy (it sounds like a name for dogs... but it's inside the urban dictionary... no copyright then...) against my real windows8.1 installation, so results will be offuscated (you too curious).

Our goal is not the user password, but to unlock user's DPAPI masterkeys: actually, if you have a memory dump (whatever contains the lsass process), you'll be able to (almost) always unlock user DPAPI. Sounds cool... but stay grounded. Let's recall the mimikatz matrix, next figure

As you can see in the Primary column, the SHA1 hash is always there with only one exception, the domain protected users. That SHA1 is the SHA1(UTF16LE(user_password)), which is exactly the only secret part of the pre-key needed to unlock masterkeys (refer to the slides)!

So despite the fact the Microsoft hardened Windows by removing default user password presence in some SSPs (Security Support Providers) or despite the user configuration (see this great post from Mike Pilkington)
the SHA1 will allow DPAPI decryption even if the user password is not
known. To the best of my knowledge you can't configure/remove (aka
harden) the primary SSP (msv1_0). Result: grab that hash and enjoy with
dpapick, which handles it wonderfully.

Consider the following mimikatz output, coming out from a Windows 8.1 with one local user account

As expected, no cleartext password but... the SHA1 is there! Since I know my password (do you remember the previous 'fuffa'?), that SHA1 is exaclty the SHA1(UTF16LE('fuffa'))... Rememeber, with virtualization you must know the user password to access DPAPI protected data (you can't reset the user's password): here, with dpapick, you only need the "always present" SHA1.

iCloud

Since I'm talking about ODI, I'd like to show how dpapick usage could help during a digital forensics investigation. Recalling the slides, if you face an "unbreakable" (something to say here...) turned off iPhone, with no passcode provided... you will not be able to access its data. Suppose you have the suspect's laptop (but no Apple LockDown certificates) too, and iCloud installed... or suppose you have only a laptop with iCloud installed... This scenario could be called "Access to otherwise inaccessible data".

The iCloud Windows application allows the users to backup their idata on the (i)cloud (too many 'i'...), a well-known feature with some well-known issues too... but it's another story. During the installation, iCloud asks for the user credentials once and then it starts doing its job every time the computer is powered on. In other terms, single sign on in action (and autorun, btw).

The iCloud credentials are kept inside the com.Apple.AOSKit.plist file, in "\Users\<username>\AppData\Roaming\Apple Computer\Preferences\". This file contains a data section which is a large DPAPI blob: to be short, it's enough to execute the icloud.py script inside dpapick/examples folder to get the job done. For any detail, refer to slides and to the icloud.py code.

(ERRATA: when using the --hash parameter instead of --password, as I do, a quick fix is needed in icloud.py code... add at line 65 "options.h.decode('hex')"... sorry, I forgot it, and it will be fixed).

What you get is a new decrypted plist file, which contains a lot of useful and interesting info (mailToken, cloudKitToken, etc.). The iCloud token is the pair [dsPrsID, mmeToken]: with this token you can access the user's iDevices iBackups ('i' again...) stored online. For this last task I use Elcomsoft Phone Password Breaker (see here), simply because it's the only tool providing such a cool feature in the way I like. Anyway, you could also try with another iCloud by re-encrypting the decrypted token with your current Windows user DPAPI (not providing code, but it's simple).

dropbox

Dropbox obfuscated Python code it's an hard reverse engineering quest. There are at least three notable works on it, but here I want to cite the awesome one made by Nicolas Ruff and Florian Ledoux, "A critical analysis of Dropbox software security", more than two years ago! They even provide the useuful code to obtain the encrypted dbxdecryption key, which is protected by DPAPI. Being brief, check their work on https://github.com/newsoft: the dpapick dropbox script is based on their findings.

So, to get that decryption key, just run dpapick dropbox script, as shown in the next example (note: the same errata as icloud applies if using the '--hash' parameter), where I used dpapick from a Windows machine.

Then? As reported in my slides, you need EE Sqlite (Encryption Extension, see here), which is not publicly available. Newsoft provided a 3.7.0 sqlite3 source code with EE, so you can grab it from their github space and use it with the extracted password.

find your blobs

If you are curious as I suppose, you can even try to find out how many DPAPI blobs you have inside your Windows. To the best of my knowledge, actually there is only one crypto provider used, whose GUID is "df9d8cd0-1501-11d1-8c7a-0c04fc297eb": so, with a simple hex-searching you will be able to spot them. Then, with a next-to-come dpapick script, it will be easy to verify the bytes found and, in case, decrypt them.

conclusions

There are many secrets protected with DPAPI, for example Windows Vaults (lazy wip here). So feel free to write to me and/or to Jean-Michel providing some info regarding the usage of CryptProtectData in your target app, your scripts or whatever could help improving dpapick.

As you read, dpapick needs some tunings and addings, but it's an invaluable tool when you need to access protected data to go on with the investigation. So, Happy DPAPI(ck)!

[bonus track]

If you reached this last part of the post (without directly scrolling here, cheater!), then you deserve a bonus. When exploring LSA secrets, I pointed out the presence of the DefaultPassword old value, which surprised me.

I did some more tests on 6 different installations of Windows 7, 3 Windows 8.1 and 1 Windows Vista. All but Vista contained that DefaultPassword old value set, without having the auto-logon feature enabled: this password seems to be the first one inserted during the Windows installation and, by changing the current one, it does not change (not tested the auto-logon enabling and disabling).

The conclusion? Hardly definitive due to reduced dataset (please share your findings), but it could be said that starting from Windows 7, Windows keeps in the old DefaultPassword value your first password (assumed auto-logon disabled). The risk? It depends on you. The opportunity? It depends on them. Anyway, from today, I'll always check this value.

Get link

Facebook

Twitter

Pinterest

Email

Other Apps

Comments

Post a Comment

Popular posts from this blog

Those who follow this blog may have noticed few months ago a post that introduced WhatsApp Xtract: this script was able to display in an HTML document all the WhatsApp messages extracted from an iPhone. And those who follow the xda developers forum may have recently noticed a thread on it.
This last month, thanks to Martina Weidner (aka ztedd) who has decided to take control of its development, we have obtained valuable results. Intro:WhatsApp is a widespread instant messaging application for smartphones, available for iOS, Android, BlackBerry, Symbian and Windows Phone. The chance to replace the traditional SMS service avoiding its cost, has allowed this application to gain popularity very quickly. The automatic synchronization of the app to the phone address book, the unlimited message length and the possibility to share an high range of multimedia attachments have persuaded many people... and who cares if it has suffered from some security issues!

Few weeks ago I was contacted about how to decrypt Windows Dropbox DBX files and the same topic appeared on SANS DFIR mailing list too. So I decided to create an Open Source toolkit and this post to brush up on the DBX files create by the Dropbox client on a Windows machine.

The Windows Dropbox client keeps its own files - user info, configuration, 'my dropbox' files sync status and even more - inside the user profile: on the Windows 7 and Windows 10 machines I used for test they reside in '\Users\%USERNAME%\AppData\Local\Dropbox\' and sub folders. Among them there are files with .DBXextension, which are the target of this post. When you take a raw look at them, you see garbage, noise... encryption is in place.

Without too much suspence, this is well-known. Nicolas Ruff and Florian Ledoux had a talk at hack.lu2012 on the topic, “A critical analysis of Dropbox software security” (here). They discovered that the encryption key used for DBX files is kept in the registry …

Windows Phone 8 and greater allows the user to lock/unlock the phone by using a numeric PIN code: it's even possible to use a complex alphanumeric password. This post addresses how to obtain the simple numeric PIN code by cracking the authenticator kept in the SOFTWARE hive. an useless quest?
Actually if you have a physical access to a Windows Phone you don't need the user pincode to examine the user data: with the proper hardware you can usually get a whole dump of the un-encrypted device memory. To my current knowledge the pincode is not used anywhere if not for device locking, so it's almost useless to know it. If the device is under a properly configured MDM, you could face a fully encrypted phone with TPM: in this case you'll have no chance to crack the pincode, even if more testing should be done.

This is exactly what I thought when my colleague Mattia Epifanitried to lure me with the Windows Phone PIN issue: he knows the curious monkey inside me... but I was a re…