Forensic Analysis of Tor on Linux

by Runa | April 13, 2013

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…”.

Comments

Please note that the comment area below has been archived.

regarding

regarding ~/.bash_history:

running
> unset $HISTFILE

in the terminal used to run the bundle prevents logging (bash on Ubuntu; ymmv)

Terminal commands are logged to $HISTFILE when the terminal exits, so this command can be run at any time and will prevent logging in the current terminal.

what about a for browser VM?

Whonix?

You only looked at files.

You only looked at files. There are probably a lot of traces left around that aren't in files at all: contents of deleted temporary files, stuff in the swap, etc. Some of it may show not only that you've run the TBB, but something significant about what you're doing. I don't think the TBB can really do anything to make a system forensics proof against somebody who has physical possession of the machine. And even if you clean a VM, that may or may not clean the physical machine it was on.

You can look for some of this by dding out entire disks, or perhaps by comparing the virtual disk files directly. But it's going to be a lot of work to figure out which changes are TBB traces and which aren't. And after you figure it out, you may very well not be able to do anything about it.

There may also be unusual or error conditions that cause trouble. For example, it may be possible to (intentionally or unintentionally) crash the browser without having it clean up various temporary data, or to get it to forget to clean something, or to get it to drop some piece of debugging information somewhere.

You may be trying to do something that's simply not achievable. If you want to be truly forensics-proof, I think you're probably at least going to have to boot from the Tor media. And there's a good chance you're going to have to boot the PHYSICAL MACHINE from the Tor media.

Sounds like good reasons to

Sounds like good reasons to use Tails or Linux Liberte` if not leaving traces is necessary.

Of course, you have to trust a respective third-party product. In the case of Tails, the ambiguity of the affiliation with the Tor Project doesn't help instill confidence. (See
https://blog.torproject.org/blog/new-tor-browser-bundles-firefox-1705es… )

If you download Tails or

If you download Tails or Liberte Linux you leave traces that you downloaded Tails or Liberte Linux. These are equally difficult to remove.

So now it's this. What sort

So now it's this. What sort of public announcement would make you more confident?

Could you do a part 4 on

Could you do a part 4 on FreeBSD? I'd be especially curious to see how FreeBSD compares to Linux.

Too little, too late, but

Too little, too late, but thank you very much for doing this, Runa!

I am unable to contact Tails, and the Tails forum is down, but there is also significant leakage about usage of this supposedly "amnesiac" OS booted from a R/O DVD.

In a desktop or laptop running Debian Squeeze (with Gnome desktop), try

find -mtime -1 | grep metadata | grep gconf

Nautilus stores information about the desktop icon you see when you mount an encrypted USB or DVD. This information includes the name, time, and position of the icon.

Please thank Tom L for his work, especially on tutorials for the masses.

If this comment works I may add more later about metadata issues when running TBB. Runa, I think you need to do more faux "work" than you describe above to see how bad the problem is.

Please create tickets on

Please create tickets on https://bugs.torproject.org/ for metadata issues when running TBB, I'd love to know about them.

Using a Live Linux Distro

Using a Live Linux Distro with encrypted AES persistence solve the problem of leakage information.

How do you download it

How do you download it without leaving traces? It's a bootstrap problem. Download without Tor? Download with your every day OS? How to delete traces of download of your every day OS?

Does not exist total

Does not exist total security but you can try to limit the inconvenience....
- Use VPN with no logs
- Use a live OS distro on Usb stick to keep separate from the rest of the computer (I use Linux on a 16GB micro SDHC)
- Use encryption for whole disk or partition or files, where store personal data, leakage trace left by the OS on your local system
In my case:
1° passphrase to unlock encrypted AES partition to run OS with my personal settings (in case of incorrect key it starts a normal linux live distro)
2° passphrase to unlock encrypted AES container to run Tor and my web hidden server and gain access personal data
3° passphrase to unlock an hidden encryped AES file inside the previous container where i preserve key file, bank details, password, private photos
AES is better than nothing
- Use Tor and hijack all outgoing Internet traffic
- Use Advanced Tor options (control port 9151)
- Swap is disabled
- Change MacAddress
- Don't use Tor to download big size files or you'd be old before the end
- Use strong and long Passphrase (mine are about 29 characters)
- Use Bitcoin
- Use PGP
- Have many identities
- I forgot something ?
- Good Look

Anything can be hidden in the dark ... you just hope not to meet ever!

Runa, I'll try, but in case

Runa,

I'll try, but in case it doesn't work: one quick point: in doing similar studies of TBB to what you did, I observed that when you start with a fresh TBB under Debian stable, as you surf to dozens of popular websites, more DOM storage files are created, and they seem to change in ways I cannot yet predict. ( I hash, do one browser action, rehash, and the results appear inconsistent.) I speculate that this might be due in part to "harmless" attempts to update indexes for the various tables, but fear this could be used to harm users in certain circumstances.

Also as noted above, nautilus, gedit, and other hard to avoid utilities add cruft such as plaintext names of encrypted files, paths, and... at least one my Debian stable, the situation is not good at all.

@ preceding comment, regarding "using a live Linux distro with encrypted AES persistence solves the problem".

I disagree, and urge you to read about concerns about AES (Bruce Schneier has explained better than I can) and about wear leveling (if you boot Tails from a USB). Beyond that, many Tor users feel the threat model badly needs revision.

I've looked a bit at Tails too and I think Tails also has potential metadata issues. A simple example: when a Debian stable user simply sticks a Tails DVD in a CD tray, or a LUKS encrypted USB in a USB tray, Nautilus seems to record the name and a large integer seems to be a timestamp. If so, even a remote intruder who simply has the permissions of the ordinary user can probably deduce quite a bit about what the Debian user was doing when. (If you want to boot from a Tails DVD, it can be inconvenient to try to get the DVD in the tray unless you do this while your Debian OS is booted.)

We know that some of our adversaries know this, have been exploiting such issues with thousands of trained humans, and further, are having those humans train an AI system which will do it better, automatically, and potentially on a much more massive scale in the next few years.

I use Knoppix, not tails. I

I use Knoppix, not tails. I load the OS from USB stick. As a live distro it gives me the opportunity to create an encrypted persistence where to save my data, customization, applications, browser history, bookmarks, TBB, and so on.
Intruders who were in possession of the USB could not access the data encrypted (I hope) stored in the file.

Runa: Which objective are

Runa: Which objective are you going after?

to counter forensic analysis on a machine that the user does not own, like in a library or internetcafe?
to counter forensic analysis on a machine that the user owns and has admin rights to?

These objectives are different, and from this post it appears that it's option number one.

For option number two, whole disc encryption seems to be the fastest means to this end. But this solution may not be available for the first objective, since you need admin rights to install the disc encryption software.
See: https://www.schneier.com/essay-199.html
Also, OpenBSD supports encrypted partitions from scratch.

Another thought:
USB sticks leave their serial number in the logs in Linux, which you may already have noticed. Windows leaves serial numbers in the registry and/or home directory.

A third point:
Admins of some public computers have disabled USB ports or DVD's from reading and booting their system, which is another cause for concern.

I'm the first "Anonymous",

I'm the first "Anonymous", with the "You only looked at files" comment. The other anonymous comments aren't mine.

Last time I looked, Knoppix would by default search the disk for any swap partition and happily start swapping on it. I don't know if they encrypt the swap or not. If it's not encrypted, you're boned. If it is encrypted, the presence of the encrypted swap data from Knoppix on the probably unencrypted swap partition of your computer is going to at least raise questions about when you booted Knoppix and why. If you forget to type the advanced "no swap" boot option, you lose.

Tails at least doesn't do that. But there's still the rubber hose attack if they find the USB stick. And as the other anonymous points out, if you ever put that stick into your computer while your regular OS is running, you're made as a user.

I still think it's a total fool's errand for a pure user mode suite like the TBB to try to hide the mere fact of use, or probably even the browsing history, from serious forensic analysis. Casual poking around by your average roommate, yes. Intelligence agencies, or national-level law enforcement when they're motivated? No. And the day they decide automate it, every beat cop in Iran will be able to tell.

Far safer to just tell users who need to be worried about forensics to "turn off the computer, go retrieve this USB key, boot from it, do secret stuff, then turn off the computer again, take a walk and hide the key, come back and boot the computer again".

Good job, keep it up. Even

Good job, keep it up. Even if the tor developers can't change it, the information is appreciated.

#Sounds like good reasons to

#Sounds like good reasons to use Tails#

I dont know.........
Tails developer insistent ignore problem of NON-persistent EntryGuard.
Implemented like Bridge mode in TAILS. The average TAILS user don't hack his copy of TAILS.

They work this,say that but
dont solve this very hard problem.
Why? May team themis?
I would say this is a serious problem.

https://www.torproject.org/docs/faq.html.en#EntryGuards
https://www.torproject.org/docs/tor-manual.html.en
UseEntryGuards 0|1
This is desirable because constantly changing servers increases the odds that an adversary who owns some servers will observe a fraction of your paths.
https://gitweb.torproject.org/tor.git/blob/tor-0.2.4.12-alpha:/ChangeLog
Raise the default time that a client keeps an entry guard from
"1-2 months" to "2-3 months", as suggested by Tariq Elahi's WPES
2012 paper.

Think about this.

"But there's still the

"But there's still the rubber hose attack if they find the USB stick. And as the other anonymous points out, if you ever put that stick into your computer while your regular OS is running, you're made as a user."

Yes, and the fact that US intelligence attempts to keep a database of the unique identifier of every USB stick (and hard drive) in the world is public information. (They say they use this for forensic analysis of "pocket litter" when they search the house of someone suspected of opposing US policies.)

I believe the previous comment may refer to the Tails forum nixing a detailed analysis of confirmation attacks. In any case, I also urge you (Runa) to liase with the Tails developers in performing further forensic analysis of TBB running under Debian stable and other popular OSs, and of Tails. I also agree with the poster who suggested more carefully defining what kind of potential problems you seek to prevent.

I decided my own results are too inconsistent to try to file a bug report; rather, it seems better for the Tor and Tails developers to define their goals and perform their own analysis using hints above about some things to look for.

Thanks for your work on this, and more please!

Can somebody make a USB plug

Can somebody make a USB plug that sits between a USB device and the computer that changes these unique IDs?