SecureDrop

Description

SecureDrop is an open-source whistleblower submission system that media organizations can use to securely accept documents from and communicate with anonymous sources. It is currently a project of Freedom of the Press Foundation and was originally created by the late Aaron Swartz. SecureDrop aims to help parties communicate securely by using a number of privacy enhancing tools, including Tor, Tails, Qubes OS and OpenPGP. There are three main components: SecureDrop Server: A Python web application (Flask/SQLAlchemy) and associated Ansible provisioning logic. SecureDrop Workstation: Runs on Qubes OS, provisioning multiple VMs that interact with each other to provide a virtual airgap for handling documents. SecureDrop Inbox: Electron application that runs inside a Qubes VM that fetches and decrypts submissions for journalists to triage. The server runs on dedicated hardware and is isolated from the media organization's corporate network with a dedicated network firewall. SecureDrop provides two web interfaces, both of which are only accessible as onion services in the Tor network; a public one that sources use to send messages or upload documents, and a private one that journalists use to check submitted information and reply to sources. All communication happens over the Tor network, and submissions are encrypted at rest using OpenPGP. SecureDrop is in the process of transitioning journalists from an airgapped Tails system (where the journalist interface was accessed) to the new SecureDrop Workstation, which is built on top of Qubes. Within the Workstation is the SecureDrop Inbox, an Electron application that syncs with the server, automatically downloading and decrypting messages and replies, and allowing journalists to view submitted documents in an offline, disposable virtual machine. We appreciate all security concerns brought forth and are constantly striving to keep on top of the latest threats. Being proactive rather than reactive to emerging security issues is a fundamental belief at the Freedom of the Press Foundation. We appreciate the community's efforts in creating a more secure ecosystem. To learn more, please read the FAQ and threat model document . If you have any questions, contact [email protected] with “BugCrowd” in the subject line.

Targets

In order to give researchers as much access to the SecureDrop system as possible, and thus provide a bounty that is more effective than just a black box test or code review, we recommend that researchers set up their own instance of SecureDrop for testing and analysis. You can do this quickly and easily with our automated deployment process. You can choose to deploy SecureDrop server code locally in a virtualized environment (Docker, Vagrant + Virtualbox or Libvirt), or you can deploy it on dedicated hardware to most accurately emulate a production installation. We recommend choosing the environment based on what you are interested in testing: for example, vulnerabilities in the web application or the server stack will be most likely auditable from a virtualized environment. Similarly, for the Workstation and Inbox, some functionality can be tested in development mode, but interactions with Qubes are best verified in Qubes itself. Note that all production instances are run on dedicated hardware and that virtualized environments are only meant for development and testing. Vulnerabilities that rely on those non-production environments will not be considered for a reward. Using SecureDrop Once you've set up a SecureDrop environment for testing, see these resources to learn how it is typically used: Source User Manual Journalist User Manual Administrator User Manual Here is some relevant background for the SecureDrop Workstation: Introduction to Qubes Qubes Installation Guide Eligible Submissions Attacks that rely on components other than the SecureDrop application code, such as Tor Browser or Qubes, will be considered as long as the attacks can be used to successfully exploit the SecureDrop system. The following are minimum awards for the following attacks: $500 - Stored or reflected XSS on the Server’s Journalist Interface $750 - SQL injection on the Server’s Journalist Interface $1000 - Authentication bypass on the Server’s Journalist Interface $1500 - Stored or reflected XSS on the Server’s Source Interface $2000 - SQL injection or Authentication bypass on source interface. $2000 - XSS or SQL injection in the SecureDrop Inbox $2000 - Code execution on a SecureDrop Workstation VM other than the Disposable VM used to open submissions (sd-viewer). $2500 - RCE on the SecureDrop Server’s source or journalist interfaces. $2500 - Extraction of private key material, successful extraction of decrypted SecureDrop submissions. Prioritization This program adheres to the Bugcrowd Vulnerability Rating Taxonomy for the prioritization/rating of other findings. Generally we will reward more for an issue exploitable through the source interface than through the journalist interface, since an attacker needs a valid ATHS token to access the journalist interface whereas the source interface is accessible by any Tor user. Similarly, attacks that require a compromised or malicious server will usually be treated as lower priority and receive lower rewards. Attacks against the SecureDrop Inbox that require a compromised or malicious server must be demonstrated with proof-of-concept server code or responses sufficient to demonstrate the attack on an unmodified client. Ineligible Submissions Pre-existing GitHub issues All Common "Non-qualifying" Submission Types from the Bugcrowd Standard Disclosure Terms . Submissions related to projects that are not in production usage. Pull requests are always welcome! Network and application level Denial of Service (DoS/DDoS) vulnerabilities. This includes continuous large submissions and continuous codename generation. Disclosure of known public files or directories, e.g. codename word lists or test-only PGP keys. Attacks that rely on other browsers (our threat model assumes Tor Browser or Tails). Attacks on 3rd party providers, e.g. use of Google for DNS and SMTP. Attacks that rely solely on the development environment and/or the virtualized platform (this includes the use of default credentials in these environments). Functional, UI and UX bugs and spelling mistakes. Pointing out that pip, npm or Rust packages aren't signed. Descriptive error messages (e.g. Stack Traces, application or server errors). Pointing out the lack of HTTPS since Tor Onion services are used. Pointing out that metadata is not removed from uploaded documents (this is intentional in order to allow journalists to use metadata to validate documents). Missing HTTP security headers , such as pointing out missing Cache-Control headers. Attacks on the SecureDrop workstation initiated from arbitrary commands run in dom0. Attacks on the SecureDrop Workstation that rely on the attacker having access to dom0. IDOR vulnerabilities based on every journalist and admin user having full access to all sources and submissions. Pointing out that the Flask session cookie discloses the source codename/passphrase Pointing out that after installation of SecureDrop Workstation, credentials are left behind in dom0, or that these credentials have insufficient permissions. Pointing out that HOTP or TOTP shared secrets or tokens can show up in server logs. Pointing out that a 2FA reset does not prompt for re-authentication. Attacks that can lockout a journalist that rely on knowing the journalist’s username and 2FA credentials, as well as the authenticated onion service token.