Ethical Security Research on SecureDrop
The SecureDrop engineering team welcomes the contributions of security researchers. SecureDrop is relied on by sources to talk with journalists at dozens of news organizations, many of whom are taking significant risks to bring information to the public eye. We want to do everything we can to make the whistleblowing process as safe for them as possible. Testing by external security researchers is an important part of that process. In order to minimize risk to SecureDrop users throughout the security research process, in this post we will describe how to ethically perform security research on SecureDrop and what constitutes acceptable and unacceptable behavior.
To further encourage ethical security research, we’re also excited to announce today that we are adding rewards for security issues found in SecureDrop - up to $2,500 - to our bug bounty program hosted by Bugcrowd.
This month we sent out a security advisory regarding malware attacks that aimed to exfiltrate data from the SecureDrop airgap by tricking journalists into scanning QR codes. This attack was due to a security researcher sending malware to live SecureDrop systems at news organizations. In the case of this recent incident, the full attack code was disclosed in public on Twitter by one of the journalists impacted. This gave an opening to potential bad actors to copy the security researcher’s code and conduct similar attacks. We want to encourage creative attacks like the one demonstrated this month but ensure that undue risk is not placed on users of SecureDrop.
Minimize Risk to Users
We consider the following activities to be unacceptable behavior:
- Do not send malware to live instances.
- Do not attempt to trick journalists or administrators at news organizations into disclosing information about their SecureDrop.
- Do not attempt to hack into the servers (either SecureDrop or the web server listing the onion address) of news organizations.
- Do not launch denial of service attacks on live instances.
Recall that Freedom of the Press Foundation is not directly running any SecureDrop instances. If you attack the SecureDrop of a given news organization, you are attacking a news organization, not the Freedom of the Press Foundation. If you wish to perform red team exercises on a given site, you should discuss this directly with the organization running the instance to get their consent before proceeding.
Responsible Security Research
If you wish to alert the SecureDrop engineering team to a security vulnerability, you are strongly encouraged to do so responsibly through our Bugcrowd program. This program enables security researchers to discuss security issues directly with the SecureDrop engineering team.
Today we’re also announcing the addition of financial rewards as much as $2,500 for the disclosure of security issues that can be used to recover the plaintext of SecureDrop submissions, the recovery of the SecureDrop submission private key, the disclosure of source codenames or other serious violations of our threat model.
Vulnerabilities anywhere in the SecureDrop technology stack, including those that are not in the SecureDrop application code are in scope, as long as the vulnerability can be used to exploit the SecureDrop system.
If you prefer not to use Bugcrowd and wish to communicate with us directly, we also accept security issues by PGP-encrypted email at [email protected] using the fingerprint 734F 6E70 7434 ECA6 C007 E1AE 82BD 6C96 16DA BB79.
Correction, March 19, 2018: A broken link in this post (to our threat model) was fixed.