Once in a while we get questions here in the Security forum about how to erase all evidence of Tor on a computer. Is it enough to simply delete the browser bundle folder? I'm a paranoid person and usually recommend a full disk wipe, even though LE is not going to forensically analyze the free disk space of the average SR user. Mainly my recommendation comes from not knowing what the TBB is leaving behind. Finally we have answers! Runa Sandvik of the Tor Project is forensically analyzing the traces left behind by the TBB on Linux, Windows and OS X. Her first analysis, published a few days ago, covers Linux (specifically Debian). ====== As part of a deliverable for two of our sponsors (Sponsor J, Sponsor L), I have been working on a forensic analysis of the Tor Browser Bundle. In this three part series, I will summarize the most interesting or significant traces left behind after using the bundle. This post will cover Debian Linux (#8166), part two will cover Windows 7, and part three will cover OS X 10.8. Process I set up a virtual machine with a fresh install of Debian 6.0 Squeeze, logged in once and shut it down cleanly. I then connected the virtual drive to another virtual machine and used dd to create an image of the drive. I also used hashdeep to compute hashes for every file on the drive, and rsync to copy all the files over to an external drive. After having secured a copy of the clean virtual machine, I rebooted the system, connected an external drive, and copied the Tor Browser Bundle (version 2.3.25-6, 64-bit) from the external drive to my Debian home directory. I extracted the package archive and started the Tor Browser Bundle by running ./start-tor-browser inside the Tor Browser directory. Once the Tor Browser was up and running, I browsed to a few pages, read a few paragraphs here and there, clicked on a few links, and then shut it down by closing the Tor Browser and clicking on the Exit-button in Vidalia. The Tor Browser did not crash and I did not see any error messages. I deleted the Tor Browser directory and the tarball using rm -rf. I repeated the steps with dd, hashdeep, and rsync to create a copy of the tainted virtual machine. Results Using hashdeep, I compared the hashes from the tainted virtual machine against the hashes from the clean virtual machine: 68 files had a hash that did not match any of the hashes in the clean set. The most interesting files are: ~/.local/share/gvfs-metadata/home: contains the filename of the Tor Browser Bundle tarball: tor-browser-gnu-linux-x86_64-2.3.25-5-dev-en-US.tar.gz. GVFS is the virtual filesystem for the GNOME desktop, so this result will probably vary depending on the window manager used. I have created #8695 for this issue. ~/.xsession-errors: contains the following string: Window manager warning: Buggy client sent a _NET_ACTIVE_WINDOW message with a timestamp of 0 for 0x3800089 (Tor Browse). It is worth noting that a file named .xsession-errors.old could also exist. I have created #8696 for this issue. ~/.bash_history: contains a record of commands typed into the terminal. I started the Tor Browser Bundle from the command line, so this file contains lines such as ./start-tor-browser. I have created #8697 for this issue. /var/log/daemon.log, /var/log/syslog, /var/log/kern.log, /var/log/messages: contains information about attached devices. I had an external drive attached to the virtual machine, so these files contain lines such as Mounted /dev/sdb1 (Read-Write, label THA, NTFS 3.1) and Initializing USB Mass Storage driver. ====== She doesn't discuss the results, but I find them interesting. The bash commands in the history file are obvious (and won't exist when starting TBB from the file manager or a menu item), but I didn't expect the TBB archive filename to show up in something called gvfs-metadata. I wonder if there is some way to prevent that? And if there isn't at least you now know to shred the files in that folder! Mitigation strategies are mentioned in the bug reports below. In her next blog post, she will cover Windows. I bet there will be a lot more traces. References https://blog.torproject.org/blog/forensic-analysis-tor-linux https://trac.torproject.org/projects/tor/ticket/8166 https://trac.torproject.org/projects/tor/ticket/8695 https://trac.torproject.org/projects/tor/ticket/8696 https://trac.torproject.org/projects/tor/ticket/8697