On the evening of Monday October 16th, just as the SecureDrop team was about to head home for the day, two of our engineers, while doing some testing for a new version of SecureDrop expected to be released the following week, discovered a serious vulnerability in the SecureDrop code.

The vulnerability was identified in the configuration logic used during initial installation, and caused three packages, tor, ntp, and the tor keyring, to be installed without proper verification of cryptographic signatures. This failure to properly verify packages occurred due to developer error in the use of the force option in Ansible, the tool we use for system configuration. Automatic nightly updates are not affected by the vulnerability, making the window of exploitation quite narrow. (See the full technical details of the vulnerability and its severity below.)

Late last week, we issued a private patch to news organizations affected who wished to reinstall SecureDrop immediately, and we are releasing the fix publicly today in SecureDrop 0.4.4.

We believe all news organizations are at very little risk from this bug, but we want to be 100% transparent on how we reacted to this discovery, our thought processes behind our conclusions, what news organizations can do if they are worried, and what we’re doing to prevent a similar incident in the future.

First, it’s important to note that an attack needed to exploit this vulnerability would be incredibly difficult to pull off. It’s likely that only a nation-state actor with network-level access would have the ability to conduct such a sophisticated man-in-the-middle attack to replace the affected packages with malicious code. Any attacker would also have had to have had invasive, targeted surveillance on either the news organization or Freedom of the Press Foundation to know exactly when the installation was occurring and be able to target that specific network, making the window for such an attack very narrow.

After we discovered the bug last week, we immediately forensically reviewed our installations, as well as a binary logs from a number of high profile news organizations to see if there was any evidence of tampering or active exploitation. Again, no evidence was found.

It’s also important to note we discovered the bug internally, no outside researcher or attacker alerted us to it before we discovered it. We had this code audited by a professional pentesting firm and they did not discover it either. And in all of our forensic testing, we have not seen any indications that this attack has occurred.

However, because we cannot 100% rule it out, we consulted with several news organizations with the highest threat models over the potential risks, and engaged with several outside security experts to determine the best course of action.

We also asked outside experts about their opinion on feasibility of the attack over the past week. While it is technically possible, everyone agreed that the chances that any such attack occurred are extremely remote. But out of an abundance of caution, we have still made several recommendations for news organizations who are particularly concerned.

For most news organizations running SecureDrop, we believe no action is necessary. For news organizations who are concerned about a coordinated nation-state attack like the one we’ve described above, we’ve recommended they consider installing the just-released version of SecureDrop. We’ve recommended some organizations take an extra step and reinstall on new hardware to completely eliminate any potential risk.

We are deploying our engineering team to news organizations who would like our assistance reinstalling and are on call to answer any remote support questions as well. You can reach out to us through our support portal or at securedrop@freedom.press for more.

Some news organizations have chosen to reinstall, and others have decided that the chance of an attack was so remote that they do not believe a reinstall is necessary. These news organizations know their own threat models better than we do, so we respect any decision they make in this regard.

As anyone who works in computer security knows, there is no such thing as perfect security; security is not a single state, it’s an iterative process. While SecureDrop is far, far safer for sources to communicate with journalists than phone calls or emails, there is always the risk that our code can have bugs in it too. It’s our job to mitigate the risk of those bugs, fix them quickly when they are discovered, and work with news organizations to make sure we keep everyone as safe as possible. We hope we’ve lived up to that promise here.  

In the coming months, there will be a lot of changes to SecureDrop to make it both easier to use and more secure. It will be audited again by an outside penetration testing firm, like it has been three times before. We also have a bug bounty program through BugCrowd with cash rewards, and encourage open source contributors to help us find bugs in the future.

The full advisory is posted below.

Security Advisory: High Severity Security Vulnerability in SecureDrop

We have no evidence that the vulnerability in question has been exploited in the wild, and have begun the process of reviewing a number of installations in order to confirm this. While significant in terms of our threat model, successfully exploiting this vulnerability would require a premeditated attacker with ‘man in the middle’ capabilities during installation time only. We recommend sending logs to FPF for analysis and then we will work together to determine next steps.

We believe it is unlikely anyone was affected by this vulnerability, however, out of an abundance of caution, organizations particularly concerned about this threat can perform a full re-installation on SecureDrop 0.4.4 in order to be absolutely certain. Before deciding on this step, we recommend first sending logs to FPF for analysis to determine if there is any evidence of compromise.  

Remote Code Execution Vulnerability in SecureDrop 

During initial provisioning of the SecureDrop servers, three packages - `tor`, `ntp`, and the `Tor keyring` are installed without verifying cryptographic signatures. As these packages are fetched over HTTP, an attacker with network access could gain remote code execution on the SecureDrop servers if they are able to man-in-the-middle (MitM) the connection to the apt server.

This vulnerability was first introduced in SecureDrop 0.3, released February 11, 2015. Any SecureDrop installation that was installed before February 11, 2015 is not impacted unless your organization completely re-installed SecureDrop since.

While the code in question was audited by a professional penetration testing firm, this vulnerability had been missed by both the firm and SecureDrop engineers until it was found during internal code review on Monday, October 16th 2017. We have no evidence that any third party researcher or adversary knew about the vulnerability before we found it.

It’s important to note that any attacker exploiting this vulnerability would have to be sophisticated and have targeted surveillance on news organizations installing SecureDrop and/or Freedom of the Press Foundation to determine the exact time to execute it. Again, we have no evidence that any news organization has actually been compromised, and we believe it is very unlikely that they were. As an initial step, we recommend sending logs to FPF for analysis.

However, out of an abundance of caution, we are recommending the following steps for news organizations who consider themselves vulnerable to this kind of sophisticated state level attack.

Mitigation

It is possible that you do not think that your organization could have been attacked this way based on your threat model, and it is ultimately up to each individual news organization whether they believe it is possible they could be affected by attacks exploiting a vulnerability such as this one. Some news organizations may choose to not do a full reinstall.

As we take even distant risks to compromise seriously, we are advising all SecureDrop instances with state-level adversaries to reinstall after an emergency fix is released on Monday, cycle the private keys used for Tor (which will change all onion addresses), and refresh the hardware used for the SecureDrop application and monitoring servers. Provided an attacker has sufficiently advanced capabilities to successfully execute the attack, they could persist malware within firmware. While we are not aware of any active exploitation, again, this is the most conservative course of action and what Freedom of the Press Foundation is recommending.

For instances that have HTTPS on the SecureDrop source interface, private keys must be rotated and new EV certs will need to be acquired.

Fortunately, due to the use of an airgap in SecureDrop, the SecureDrop GnuPG submission key on the Secure Viewing Station does not need to be rotated.

On-Site Assistance

We understand that a full re-install and a recycling of hardware is an inconvenience for everyone involved, so Freedom of the Press Foundation will offer both free on-site assistance and hardware at no cost to any high-risk organization running a production SecureDrop instance should they choose to proceed with a reinstall. All high-risk organizations have been contacted through the support portal if we recommend this path.

SecureDrop administrators should continue to use the support portal and encrypted communications to securedrop@freedom.press to discuss.