SecureDrop and the OpenSSL Vulnerability

Bill is a long time activist, programmer, and cryptography enthusiast. He's been code-slinging server and client-side web applications for ...

April 8, 2014

Update: The Tor Project has released a new version of the Tor Browser Bundle, 3.5.4. This further mitigates client-side vectors, and we recommend users (both sources and journalists) upgrade to the latest version for a stronger security assurance.

Today a serious vulnerability was reported on OpenSSL versions 1.0.1 through 1.0.1f: CVE-2014-0160, or Heartbleed. SecureDrop runs as a Tor Hidden Service, which we also know is affected. As such, this affects all properly configured instances of SecureDrop, and steps should be taken immediately to mitigate disruption of SecureDrop running services.

What should I do?

If you are a journalistic organization running SecureDrop and we've helped you set it up, you can work with our chief systems architect James Dolan to facilitate applying the fix. If you're running your own instance, here's the long and short.

If you've deployed your instance following our installation guide, here's the good news: you're running Ubuntu 12.04 LTS, and the fix has already been pushed to the upstream repositories. We have been using unattended-upgrades since the very first version, so your system should auto-upgrade and OpenSSL will be patched by tomorrow. However this alone is not enough to fix the problem.

After the above patch, you will need to re-generate your SecureDrop Tor hidden service keys.

Since SecureDrop's firewall blocks all incoming SSH connections unless they're coming from the authenticated Tor hidden services, you can't re-generate your keys remotely easily (your connection will get dropped, and you won't be able to ssh back in). Go to the physical SecureDrop servers, plug in a keyboard and monitor (or have a journalist connect the KVM/IP) and run these commands from there.

apt-get update
apt-get upgrade
rm /var/lib/tor/hidden_service/private_key /var/lib/tor/hidden_service/client_keys
service tor restart
cat /var/lib/tor/hidden_service/hostname # this is the SSH ATHS, which the sysadmin will need

The persistent volumes for each journalist will also need to be changed, which can be done by repeating the steps here starting from the creation of the "tor.sc.sh" script.

Once this is done, be sure to change the hidden service address on your public-facing website, Twitter, and anywhere else it has been published. It's a good idea to make an announcement that your .onion address has changed and why, so that sources realize that this isn't an attack. After you have a new address, if you send a GPG-signed email to [email protected], we will tweet it from @SecureDrop.

What information may have been exposed?

Submitters to a SecureDrop instance should be safe, providing:

They are using the Tor Browser Bundle to interact with SecureDrop (which we recommend)

A malicious clone of a legitimate running SecureDrop instance is not intercepting traffic at the point of submission (very unlikely)

Journalistic organizations may have leaked private key material, allowing an active malicious third party to impersonate a SecureDrop instance. Following the recommendations above will eliminate this risk.

List of updated onion URLs

Here we'll maintain a list of updated hidden service addresses as they come in.