by Frank McClain
A write-up about some forensic aspects of online storage/file-synching service Dropbox™
Cloud-based services are becoming more prevalent, and not just for businesses – end- and home-users are taking advantage of opportunities to automate backups, make files available offline or from any computer, share files and photos, and so on. Many of these services are free or very low cost, even for several GB of storage space. With smartphone apps allowing an even greater level of access, it almost becomes a no-brainer for people who want to be able to get at their files from anywhere. Of course, this leads to thoughts of forensic implications since, well, that’s what I do.
So let’s say we have a typical IP theft scenario, where someone leaving a company is suspected of taking the ‘secret sauce’ with them. In the past we’ve considered transfer methods such as USB devices, optical media, local email, webmail, and even printing files. Perhaps a file-sharing site here and there. But with cloud services, files can be replicated to the web and accessed by the user anyplace, anytime. This could even occur without an obvious, deliberate attempt to take the data; after all, with automatic synching the files are in the cloud anyway.
The services that provide synch or other automated capabilities will have some application on the local system that creates a connection to the web storage account, runs the synch or backup, and allows the user to interact with the files. Some, if not all, of these can be run from multiple systems to access the same web storage account. Quite naturally, I have used some of these myself, one in particular being Dropbox™. I was poking around in the web portal for my account some time back, and happened across some interesting things which I thought had forensic implications; this lead to some testing, research, and this article.
How Dropbox™ works
So here’s a little overview of Dropbox ™… It has applications that run on Windows ®, Mac, Linux, iPhone, Android and Blackberry; for the purposes of this article, I am focusing solely on Windows ®. You sign up for the service, which is free to store up to roughly 2GB of data. You’re provided the opportunity (and prompted to do so) to download and install their little application; this by default will run with when the OS starts. This also adds a systray item that allows you to access the settings (‘Preferences’), and your files. The application creates a ‘My Dropbox’ folder inside the user’s ‘My Documents’ folder, for local cached/offline copies of the files (this default location can be changed). These will then synch with the web storage and across all other computers connected to the account that are online. Multiple computers can be connected to one account; if these are on the same network, a feature called ‘LAN synch’ allows them to communicate with one another directly when synching files, in order to reduce bandwidth consumption (as a note, the synch only transfers the data that is changed, not the entire file).
In their FAQ, they discuss how to recover files that you’ve deleted, or revert/recover from undesired changes to a file. Turns out when you delete a file from your computer or the web portal, it’s not really gone. Well, we “forensicators” (to use the SANS ™ lingo) already knew that files deleted from a system were not actually gone, but from a web portal, too? So it turns out that it keeps the file around in a sort of live deleted state until permanently deleted (hmm, does this count against storage capacity?) or recovered (time frame is actually only 30 days for a free account). Said permanent deletion or recovery appears to occur only within the web portal. I have tested the local wiping of a file, which should remove all traces of it from the local system, only to find that it still exists in a deleted (but recoverable) state online. When you change a file, you can still go back to a previous version, using their version history/control feature. This is also for a limited time period with a free account (30 days); and unlimited with a paid account.
The deleted items can be accessed by clicking the ‘Show deleted files’ button at the top of the list of files for that directory. This button is only available if deleted files exist within that directory.
(Deleted Files Button)
The deleted files can then be seen; they appear in a lighter text, almost grayed-out. However, they can still be clicked on and selected; the file will even open or download. You will note that the numerical size value has been replaced with ‘deleted.’
Once selected (check the box) they can be recovered or permanently deleted. These features are accessed from the ‘More actions’ button (with dropdown menu).
(More Actions Menu)
There are a number of other options available in this menu, depending on the file selected. You will note that the ‘Previous versions’ option is available here; that shows up even if the current version is the only version. If multiple versions are available, clicking on this will give you the ability to recover previous ones. The whited-out area in the following screenshot actually gives the machine name of the system used for each version of the file (which I’m just paranoid enough not to put in a document to be published on the internet).
These findings led me to think about scenarios in which this knowledge might become useful. What if someone stole data from their employer this way? What if they did so and tried to cover their tracks? We’ll look at each of those possibilities a little bit.
What if someone stole data and transferred it using their Dropbox ™ account? How could that be accomplished, and what evidence would that leave behind? There’s a number of ways that the data could be uploaded – local application synching to server or direct upload to server would be the most common, and would leave plenty of artifacts, at least under normal circumstances (LNK files, web history, access dates, userassist, etc). There may be some other, more arcane, ways to transfer data to Dropbox ™ though, including sending files via email, and synching IM chat logs. I have not done any testing into those and so cannot comment as to the existence, functionality or efficacy thereof.
This type of investigation would seem to be fairly straightforward, though. Someone has allegedly taken data without authorization, their system is imaged and Dropbox ™ is found to be installed. LNK files, UserAssist, and web history artifacts all point to an upload to the web. In addition (just to make it really easy) the investigation shows that the application is still installed, set to run on startup, and automatically logs into the web portal.
But what if an attempt was made to cover tracks, to foil the “lethal forensicator” (another use of SANS ™ terminology)? This is where we start digging deeper. Where is Dropbox™ installed? What changes are made to the registry on installation? What about network activity (it uses the internet, after all)? These and other questions are coming up next…
First of all, Dropbox™ does not install into a ‘Program Files’ directory. It installs under the user profile, in ‘Application Data.’ On Windows® XP, this puts it under ‘Documents and Settings/username/Application Data/Dropbox,’ while on Win7 it falls under ‘Users/username/AppData/Roaming/Dropbox.’ Inside this directory are a few additional directories like ‘bin’, ‘installer’, ‘shellext.’ On XP (but not seemingly on Win7) there is also a ‘cache’ folder that we’ll discuss in a bit (Note: Further research indicates this is related to application version, not OS). There are also some DB files, such as ‘dropbox.db’ and ‘host.db;’ the first is SQLite, the second is actually plain text (we’ll discuss these and more a little bit later on as well).
The point of this is that if you are only reviewing the ‘Program Files’ directory you might miss it unless you expand your search. Obviously, there is more to look at to determine if an application is/was installed, such as registry entries and network/internet history.
Note: I’m not sure if it’s due to some combination of OS and application version – or what exactly – but while every system I’ve seen has the ‘host.db’ file and the ‘bin’ and ‘shellext’ directories, some of the others vary. As you can see in the above screenshot, there is no ‘installer’ on this system, yet another system across the room has ‘installer’ and ‘|’ as well; that system has no ‘dropbox.db’ but does have ‘filecache.db’ and ‘sigstore.db,’ among others. So there appear to be some variables that I haven’t tracked down yet.
Registry Changes on Installation
Okay, so we’ve already established that for synchronization to occur, the Dropbox ™ application must be installed on the local system. That being the case, their absolutely, positively, must be changes made to the system during installation. The installation directory, configuration, startup values, etc, must be put in place. One presumes that the registry will be impacted, but how?
In order to answer this question, I did a clean install of Dropbox ™ to a machine while capturing all activity with Sysinternals ™ Process Monitor. Since I wasn’t sure exactly what activity would occur, I did not pre-filter the capture of data; I let everything that occurred during the installation get logged to a CSV file. This way I figured I’d get directory, file, and registry changes. After reviewing the data and seeing that I already knew about installation directory, etc, I filtered down to only registry entries for the installer (Dropbox 1.1.31) based on Path begins with “HK.” That was further filtered by Operation contains “Set” or “Create” to get down to the nitty gritty.
There were 173 RegCreateKey entries. Many are duplicate paths, and I’m not going in to all of them here. However, I will hit a few highlights. As one might expect, all these entries are in HKCU and HKLM, so there are a lot of repetitive entries.
The above graphic shows a few I thought were very Dropbox ™ specific or otherwise interesting. As you might expect, there are a lot of SystemCertificates and EnterpriseCertificates entries. A few others of interest were: HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon, HKLM\Software\Microsoft\Tracing, and HKLM\System\CurrentControlSet\Services\Tcpip\Parameters.
There were 58 RegSetValue entries, with very little duplication. That said, I’m still not going to go through 58 entries here, either; again, I’ll hit some highlights. There are two MountPoints2 entries, same as before; the data value is “Drive.” The installation path is defined in HKCU\Software\Dropbox\InstallPath; we already knew this location but it’s possible it could be different with some other version of Dropbox ™ at some point in the future. The rest of them pretty much appear related to configuration – internet settings, icons, display information. Of course, there’s uninstall info, and if I read it correctly, it’s uninstall only – no repair, no modify.
Now that we’ve covered registry changes during installation, let’s move on to network activity. This list of connections was captured using CurrPorts by NirSoft. Obviously this is of little use to forensicators if I cut out all IP addresses to ease my security paranoia, so I have compromised and only cut ports. One of the connections, however, is not encrypted, and that one I did blank out as I did not do a packet capture, and thus do not know what’s in the non-encrypted stream (in other words, if I had, and could confirm the contents, I might be willing to publicize it).
The point of this is not to say, “Aha! They’re hosted by SoftLayer,” or “Aha! They’re using Amazon Web Services.” Rather if examining network history post-mortem (and the application is not currently installed), this would give some idea of significant artifacts. I do not know if the IP addresses or remote host names would change in different geographic areas (I know a lot of application updates do in general, but I don’t know with Dropbox ™).
Next up on the artifacts block are the ever so yummy database files. Yes, those are definitely worth looking at, especially if they exist and nothing else does. The ‘host.db’ is a plain text file containing what may be hash value(s). ‘Unlink.db’ is some binary/database file that I have not yet successfully parsed. Boring so far, right?
Then it’s on to ‘config.db.’ This little SQLite file contains some info about the local Dropbox ™ installation and account. It shows what it calls the “host_id” which appears to be an md5 hash value. It also lists the email address associated with the account (could be useful during an investigation). Also shown is the current version/build for the local application.
I’m not certain the extent of forensic benefit for ‘sigstore.db.’ It has three columns: Hash, Sig, Size, and Held. The ‘hash’ column value seems to vary in length, so I’m not certain exactly what it is supposed to be a hash value of. The ‘sig’ column apparently contains a Unicode character that does not translate well in Windows ® . If the hash were a standard md5 or sha1 of the files, that would certainly be handy. If not, well then I’m just not sure. And ‘held,’ well it’s just empty, at least on my systems.
The veritable motherlode, however, is ‘filecache.db.’ It has several tables, but the one I think is of the most interest is ‘file_journal;’ it contains a listing of all directories and files inside ‘My Dropbox.’ It appears these are only the live files, not deleted ones. Given past experience with SQLite databases, deleted entries probably remain around for a time, until the space is needed; you’d just have to devise a method to parse them out of the file (not through a standard viewer). This file appears to have replaced the ‘dropbox.db’ I mentioned previously (and showed in screenshot); as I’ve been working on this writeup, this system has changed to match the other, and ‘dropbox.db’ no longer exists.
First I’d like to offer up this information, gleaned from Sysinternal ™ Process Explorer. What I first thought was that perhaps there was some command line utility. Turns out (so sad) it’s just a way to launch the local folder, just the same as if the systray icon was double-clicked.
Touching on the installation subdirectories just a bit … The ‘bin’ folder is where the actual executables are (if you couldn’t tell from the screenshot just above). Earlier I mentioned the ‘cache’ directory; I have seen this before, containing additional – dated – subdirectories, and files in each of those that were created on a different system that’s part of the account. However, the current version of Dropbox ™ seems to have replaced that with a hidden ‘.dropbox.cache’ directory inside ‘My Dropbox.’
I have tested my theory on this, and what I’m seeing is that when a file is edited or created on one system, that file is added to this cache folder on other systems attached to the account. It shows up tagged as a deleted file (appended to the filename), inside a folder named for the date the file was created or edited. New cache files appear to be created when the active file is saved. These files will open normally in their default application.
There is also an ‘entries.log’ file inside these dated folders; it contains data about each file therein, in a pipe-delimited format. There are no column/field headers, so I don’t know what each field signifies (you can see for yourself below). Maybe encoded filenames, paths, file IDs, etc?
Uninstall / Unlink
The last thing I could think of to test is related to uninstalling the application. However, there’s also an option – available either online or through the preferences tab of the local installation – to ‘unlink’ the computer from the account. So then we have two more scenarios to test, to determine what’s left behind after each of these occurs. I’ll spoil some of the fun by saying right from the start that all the files remain accessible on the system.
Even though Dropbox ™ is not installed to the ‘Program Files’ directory, it still has uninstall entries in the Start–>All Programs menu, the Add/Remove Programs applet, or it can be uninstalled from within the installation directory (ie, ‘bin’). It will also show up in third party applications such as Revo Uninstaller. There is no option to Modify or Repair, only Remove.
For my purposes here, I only checked to see if the user files were still accessible, and the installation directory, for those artifacts. I did not check the registry to see if any of the created or set entries remain after uninstallation. As already stated, the files were present, including the ‘.dropbox.cache’ directory. The top-level folder, ‘My Dropbox’ was changed to ‘Dropbox’ and the icon was gone – but the location was unchanged. The installation directory did still exist, with the subdirectories and their contents. The various database files were no longer present (bummer).
So if a user uninstalled the application and wiped their files, best-case scenario the investigation would only show that Dropbox ™ had been installed, but possibly nothing more.
As to ‘unlinking’ the application from the account, this can be accomplished from the system, or online. On the local system, click the systray icon to get the menu, then select ‘Preferences.’
This opens the application settings, where the ‘Accounts’ tab is selected. I think it’s pretty obvious how to ‘unlink’ from here, so I’ve not circled anything. (Note to self: Contact Dropbox ™ to have them fix capitalization in last name.)
(Unlink local system)
The system can be unlinked from the web portal as well. Once logged in, click on Account at the top.
(Access Account Settings)
Once in the Account settings window, go to the ‘My Computers’ tab. All the associated systems will show up by name on the left (you didn’t really think I would post my system names, did you?), show the most recent activity, and give some options for actions to be taken. What we’re interested in (obviously) is the ‘Unlink’ button.
As far as I can tell from testing, once unlinked online, there is no way to recover that system, or to know that it was ever associated. However, if you uninstall or unlink locally, the system still shows up online. Thus, if you do that, then reinstall or reconnect to the account, you will show multiple entries for that system.
What remains behind after a system has been unlinked, and is there a difference between local and web-based action? Yes, there is a difference between the artifacts left behind from the two different methods. Both are helpful to the forensicator, and one is more so than the other.
Following either method of unlinking, the application is still installed, and if launched will provide a window to either setup a new account, or link to an existing one. The user files remain accessible on the system as already stated; the directory is changed from ‘My Dropbox’ to ‘Dropbox’ but the icon remains (as opposed to an uninstall, where the icon is gone). The installation directory still contains the subdirectories that were present before unlinking (ie, ‘bin,’ ‘shellext,’ etc).
This, however, is where the congruency ends. Well, I guess that’s not technically accurate, but close enough for a cloudy day (I was going to say, “for government work,” but there’s no telling who might be reading this). What we’re talking about here are the database files. A local unlinking leaves behind ‘config.db’ and ‘unlink.db (see ‘Local Unlinking’ screenshot below). A web-based unlinking, however, leaves behind all the databases in a fully intact state (see ‘Web Unlinking’ screenshot).
Thus if unlinked on the internet, the forensicator has access to all the files, as well as the various databases. If unlinked localy, you only have access to the files and two of the databases. In the latter case, it’s still helpful as ‘config.db’ will provide the email address used to create the Dropbox ™ account.
Where does all this get us? If we are investigating a system where there is concern about theft of data by the user, we have some additional areas to look. If we see a ‘Dropbox’ directory in the user profile, an ‘Uninstall’ entry in the registry – even if there’s no active installation – we still have the potential to shed light on the scenario.
We know where to look for additional configuration and account information, in the database files and registry. The email address will provide additional search capabilities, and may help point us in the right direction. The ‘.dropbox.cache’ folder may speak to the existence of other systems, as well as recent file activity. Internet history should provide information verifying the account synchronization or history of use that way.
I’m not certain if it’s possible to determine from one system the names or information about other systems associated with the Dropbox ™ account. However, if the ‘.dropbox.cache’ contains user files, we know there was at least one other system. And that may provide sufficient leverage to gain access to other systems or the web-portal. I have also seen files show up where the filename was parenthetically tagged as being a “conflicted” copy from another machine (and that system’s name was shown as well); this leads me to think that perhaps the ‘entries.log’ file (inside ‘.dropbox.cache’) contains encoded information regarding not only the file, but its host system.
There are a number of additional areas for research here, to help provide more useful information to forensicators. Some of these that I’ve thought of are:
– What impact does uninstallation have on the registry?
– Does unlinking (local or web) change the registry?
– What are the various “hash” values; what do they signify?
– Is it possible to upload/synchronize files via email or IM?
– Do the IP addresses vary with geographic area?
– What data is transferred across the unencrypted connection?
– Do the SQLite databases contain deleted entries, and how can those be parsed?
– Are file/system IDs or encoded info stored in the databases, ‘entries.log’ or elsewhere?
– hat artifacts remain on other platforms?
I’ve thoroughly enjoyed doing this research (although it took a long time to complete), and hope this article is of use to others. One thing that is obvious, given the time it took to complete the research, is that version updates definitely impact the artifacts remaining on the system. I got to see that first-hand, and it’s good to keep in mind the volatility this brings to an investigation; what is true now may not be true a few months down the road.
GCFA, GCIH, CHFI
31 May 2011
Frank McClain is a forensic analyst in the DFW area of North Texas, and has spent most of the last four years in consulting with a small local firm. He has worked on dozens of cases involving analysis for IP theft, computer abuse, banking fraud, malware analysis and other inappropriate conduct. In order to further his knowledge of forensics, he has spent near-countless hours researching and testing various applications, operating systems, and networks. Frank has attended SANS training courses and holds two certifications from there as well – GCFA and GCIH.