Search This Blog

Brush up on Dropbox DBX decryption

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 and it's protected using DPAPI: I suggest everybody to read all the slides, since they cover much more than Windows Dropbox DBX files. When doing my DPAPI research ("From mimikatz to DPAPI" SANS@Night Milan 2014, "give me the password and I'll rule the world" SANS Prague 2014) I used their findings to code the dropboxprobe for dpapick, to get post-mortem the Dropbox User key.

The core question now becomes: is the same schema still used for Dropbox Encryption? Short answer, yes: almost nothing changed since 2012. Assumed you read their analysis, to make the DBX decryption process easier I created a GitHub project called decwindbx which provides the Open Source toolkit I will show in action in the next lines [https://github.com/dfirfpi/decwindbx].

Quick review.

Not every DBX file is an encrypted sqlite: some are simple... sqlite files, some are base64 files etc. As DFIR guys, we should not trust extensions, should we? Take a raw look at files before trying to decrypt them.

There are two registry keys (values) which contain the Dropbox users keys, not just one.

Those two registry keys are DPAPI blobs, so you'll need the user's login password (or its SHA1, see "Happy DPAPI!") to allow their decryption.

The registry values containing the DPAPI blobs have data before (version, length) and after (HMAC) them.

The DBX security is solely based on DPAPI security (strong, by the way).

The DPAPI blobs use a fixed entropy (a secret), d114a55212655f74bd772e37e64aee9b.

When decrypted, the registry DPAPI blobs will provide the so called User Keys: they will not decrypt the DBX files.

The DBX decryptions keys are derived from User Keys using PBKDF2 with 1066 iterations and a fixed salt, 0D638C092E8B82FC452883F95F355B8E.

From 'HKCU:\SOFTWARE\Dropbox\ks\Client' you'll derive the DBX decryption key for DBX files which reside in '\Users\%USERNAME%\AppData\Local\Dropbox\instance_db'.

Getting DBX decryption keys.

Live. If for any reason (e.g. testing) you are on the live machine, you have two scripts to get the DBX decryption keys: the Powershell script dbx-key-win-live.ps1and the Python dbx-key-win-live.py. They both do not require any parameter, just launch them and get the results.

ascell#> @powershell -ExecutionPolicy Bypass ".\dbx-key-win-live.ps1"

ascell#> py -2 dbx-key-win-live.py

ascell#> py -3 dbx-key-win-live.py

I modified the original Ruff's Python script dbx-keygen-windows.py (here) to work on both ks and ks1 registry keys and to run using Python2 or Python3. Take into account that the py script has two prerequisites, pbkdf2 and pypiwin32. It's far easier to use the PowerShell dbx-key-win-live.ps1, which should run as is on Windows, starting from Vista up to Windows 10.

Post-mortem. To grab the same information post-mortem, I refactored my Python script dbx-key-win-dpapi.pywhich needs dpapick: you need to have dpapick installed or put it in PYTHONPATH, assuming you have installed its requirements.

As already pointed out, you can use the user login sha1 password or the proper unlocked Master Key. Note that dpapick needs Python2 (even if it's quite easy to port it) since the crypto library M2Crypto will not work out of the box on Python3, especially on Windows.

Decrypting DBX files.

Now we got the decryption keys we can move forward by decrypting the DBX files: remember to choose the proper 'ks' key, depending on the DBX folder location. I provided Windows and Linux static binaries, both 32 and 64 bits: sqlite-dbx-win32.exe, sqlite-dbx-win64.exe, sqlite-dbx-tux32, sqlite-dbx-tux64. The suggested approach is the following:

The resulting config.db will be the normal (not encrypted) sqlite file that you can handle as usual. The reason to run the sqlite tool batchis due to the old sqlite source code used: you can try the sqlite shell, but most likely you'll get some issues. If, for any reason, you don't trust the cross compiled binaries I provided on GitHub, you can easily compile them by yourself using the source code inside the sqlite3dbx directory.

Conclusions.

I truly like Open Source Researches integration, which can allow us to achieve great results: every step is known, every step can be reviewed and analyzed. Here I guess we had a good example. Commercial tools often use such open researches or even the code, without giving the proper acknowledgements or even without saying just a "thanks": bad, but that's it. Coming back to Dropbox, DBX decryption is just a starting point: you have the data, now you need to analyze it... Given the level of details inside all those databases, I think there is more to be done... For example, correlating what Didier Stevens recently found out looking at Dropbox ADS files (here) with the information from the decrypted DBX...

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!

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…