Вы находитесь на странице: 1из 10

Dropbox Forensics Forensic Focus: Articles / Papers

Forensic Focus: Articles / Papers


DIGITAL FORENSICS ARTICLES AND RESEARCH PAPERS

SEARCH

Search
Home Subscribe

HOME

ABOUT

SUBMIT ARTICLE

NEWSLETTER

FORUMS

INTERVIEWS

REVIEWS

JOB VACANCIES

SUBSCRIBE TO RSS

METHODOLOGY

DON'T MISS AN ARTICLE!

Dropbox Forensics
POSTED BY FORENSICFOCUS JULY 24, 2011 LEAVE A COMMENT FILED UNDER CLOUD FORENSICS, DROPBOX

Enter

your

email

address

to

subscribe to this blog and receive notifications of new posts by email. Join 56 other followers

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, thats what I do. So lets 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 weve 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 heres 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. Youre 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 users 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). Interesting/Unique features In their FAQ, they discuss how to recover files that youve deleted, or revert/recover from undesired changes to a file. Turns out when you delete a file from your computer or the web portal, its 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. Forensic Accounting Forensics 101 Hardware Legal Methodology Examiner Welfare File Systems
CATEGORIES
Sign me up!

RSS - Posts RSS - Comments

Data Recovery E-Discovery Employment

Follow

Follow Forensic
Mobile Devices

Focus: Articles / Network Forensics Papers


Organisations Regulation

Get every new post delivered Research to your Inbox.


Security

Join 56 other followers


Software

EnterSteganography email address

http://articles.forensicfocus.com/2011/07/24/dropbox-forensics/[10/3/2011 4:34:00 PM]

Dropbox Forensics Forensic Focus: Articles / Papers

Uncategorized
Sign me up!

Wireless
Powered by WordPress.com

(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.

(Deleted File) 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 Im just paranoid enough not to put in a document to be published on the internet).

http://articles.forensicfocus.com/2011/07/24/dropbox-forensics/[10/3/2011 4:34:00 PM]

Dropbox Forensics Forensic Focus: Articles / Papers

(File Versions) 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? Well 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? Theres 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 Installation Directory 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 well 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 (well discuss these and more a little bit later on as well).

(Installation Directory) 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: Im not sure if its due to some combination of OS and application version or what exactly but while every system Ive 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 havent tracked down yet. Registry Changes on Installation Okay, so weve 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 wasnt 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 Id 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.

http://articles.forensicfocus.com/2011/07/24/dropbox-forensics/[10/3/2011 4:34:00 PM]

Dropbox Forensics Forensic Focus: Articles / Papers

There were 173 RegCreateKey entries. Many are duplicate paths, and Im 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.

(RegCreateKey) 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, Im still not going to go through 58 entries here, either; again, Ill 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 its 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, theres uninstall info, and if I read it correctly, its uninstall only no repair, no modify. Network Activity Now that weve covered registry changes during installation, lets 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 whats 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! Theyre hosted by SoftLayer, or Aha! Theyre 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 dont know with Dropbox ).

(Network Connections) Database Files 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 its 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.

http://articles.forensicfocus.com/2011/07/24/dropbox-forensics/[10/3/2011 4:34:00 PM]

Dropbox Forensics Forensic Focus: Articles / Papers

Im 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 Im 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 Im just not sure. And held, well its just empty, at least on my systems.

(sigstore.db) 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; youd 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 Ive been working on this writeup, this system has changed to match the other, and dropbox.db no longer exists.

(filecache.db) Other Artifacts First Id 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) its just a way to launch the local folder, just the same as if the systray icon was double-clicked.

(Dropbox Properties) Touching on the installation subdirectories just a bit The bin folder is where the actual executables are (if you couldnt 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 thats part of the account. However, the current version of Dropbox seems to have replaced that with a hidden .dropbox.cache directory inside My Dropbox.

(.dropbox.cache directory)

http://articles.forensicfocus.com/2011/07/24/dropbox-forensics/[10/3/2011 4:34:00 PM]

Dropbox Forensics Forensic Focus: Articles / Papers

I have tested my theory on this, and what Im 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 dont know what each field signifies (you can see for yourself below). Maybe encoded filenames, paths, file IDs, etc?

(entries.log) Uninstall / Unlink The last thing I could think of to test is related to uninstalling the application. However, theres 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 whats left behind after each of these occurs. Ill 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).

(post-uninstallation) 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.

http://articles.forensicfocus.com/2011/07/24/dropbox-forensics/[10/3/2011 4:34:00 PM]

Dropbox Forensics Forensic Focus: Articles / Papers (systray menu) This opens the application settings, where the Accounts tab is selected. I think its pretty obvious how to unlink from here, so Ive 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 didnt 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 were interested in (obviously) is the Unlink button.

(Unlink Systems) 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

http://articles.forensicfocus.com/2011/07/24/dropbox-forensics/[10/3/2011 4:34:00 PM]

Dropbox Forensics Forensic Focus: Articles / Papers that were present before unlinking (ie, bin, shellext, etc). This, however, is where the congruency ends. Well, I guess thats not technically accurate, but close enough for a cloudy day (I was going to say, for government work, but theres no telling who might be reading this). What were 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).

(Local Unlinking)

(Web Unlinking) 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, its still helpful as config.db will provide the email address used to create the Dropbox account. Wrap Up 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 theres 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. Im not certain if its 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 systems 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 Ive thought of are: - What impact does uninstallation have on the registry? - Does unlinking (local or web) change the registry?

http://articles.forensicfocus.com/2011/07/24/dropbox-forensics/[10/3/2011 4:34:00 PM]

Dropbox Forensics Forensic Focus: Articles / Papers - 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? Ive 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 its 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. Frank McClain 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. Share this: Twitter Like this: Facebook

Like Be the first to like this post. Web History Visualisation for Forensic Investigations

Standard Units in Digital Forensics

DISCUSSION
NO COMMENTS YET.

LEAVE A REPLY

Enter your comment here...

Guest

Log In

Log In

Log In

Email (required) Name (required) Website

(Not published)

Notify me of follow -up comments via email. Notify me of new posts via email.

Post Comment

http://articles.forensicfocus.com/2011/07/24/dropbox-forensics/[10/3/2011 4:34:00 PM]

Dropbox Forensics Forensic Focus: Articles / Papers

Forensic Focus: Articles / Papers

Blog at WordPress.com. Theme: The Morning After by WooThemes.

http://articles.forensicfocus.com/2011/07/24/dropbox-forensics/[10/3/2011 4:34:00 PM]

Вам также может понравиться