SecureDrop has completed its sixth security audit, conducted by 7ASecurity and sponsored by the Open Technology Fund. The audit surfaced one medium-severity and two low-severity issues, which were all fixed in SecureDrop 2.10.0.
To quote from the conclusion of the auditors’ report:
“The SecureDrop project defended itself well against a broad range of attack vectors. In fact, despite the large attack surface in scope, only three vulnerabilities could be found during this engagement, and from those, only one had a medium severity. Continued cycles of security testing and hardening will further fortify the platform, making it even more resistant to potential attacks.”
Scope
This audit focused on SecureDrop’s web applications, including recent major changes like migrating to Sequoia-PGP and redesigning how sessions are stored. The auditors also investigated our supply chain security and conducted black box testing of our APT repository servers, motivated by a recent security incident.
Finally, the auditors performed a lightweight review of SecureDrop’s threat model.
Findings
The three vulnerabilities that were found, SEC-01-001 WP4: Arbitrary 2FA Enrollment via IDOR, SEC-01-003 WP4: Possible User DoS via Logout CSRF, and SEC-01-008 WP3: Unauthenticated Access to Local Redis, were fixed in SecureDrop 2.10.0 and described in detail in the release announcement.
In addition, the auditors made several recommendations for further hardening of SecureDrop, which we detail in the next section.
Hardening Recommendations
SEC-01-002 WP4: Insufficient Password Complexity Requirements
This was fixed in SecureDrop 2.10.0, see the release announcement for details.
SEC-01-004 WP4: Multiple Leaks via API Error Messages In Development Mode
Our developer environment intentionally reveals more information for debugging purposes. An administrator would have to go out of their way to put a production SecureDrop server into this state. We don’t plan to change this behavior.
SEC-01-005 WP3: Boot Loader Password Not Set
We will consider further work on this. Follow progress via this Github issue.
SEC-01-006 WP3: File Access via Insecure Permissions
Most of the files in question contain no secrets and are publicly available on GitHub; we only plan on fixing permissions for /var/lib/securedrop. Follow progress via this Github issue.
SEC-01-007 WP1: Multiple Vulnerabilities in Third-Party Libraries
We regularly review vulnerabilities in our dependencies to see if they affect us, and concluded that none of these merit non-routine upgrading.
SEC-01-009 WP3: Usage of Obsolete Redis Version
We rely on Ubuntu packages for keeping Redis up to date. After setting up password access, our review concluded that none of the unpatched vulnerabilities affect us. We plan on upgrading to Ubuntu Noble next year, which will bring a more up-to-date version of Redis.
SEC-01-010 WP4: Missing 2FA Enforcement for Sensitive Operations
We will be investigating this further. Follow progress via this Github issue.
SEC-01-011 WP3: Missing SSH MFA & Auth Hardening
We will be investigating this further. Follow progress via this Github issue.
SEC-01-012 WP3: Weaknesses in Network Stack Configuration
Our default position is to minimize logging, and SecureDrop’s architecture involves a physical firewall. We will be investigating this further. Follow progress via this Github issue.
SEC-01-013 WP3: Possible SSRF via Redis Listening on TCP
This is no longer an issue now that Redis is behind password authentication.
SEC-01-014 WP3: Lack of DoS Mitigation for Onion Service
SecureDrop supports enabling Tor’s Proof-of-Work defenses as of 2.9.0; we will be investigating the other recommendations further. Follow progress via this Github issue.
SEC-01-015 WP1: Potential Race Condition in Source Creation
We will be investigating this further. Follow progress via this Github issue.
SEC-01-016 WP3: Insufficient Logging and Monitoring
We will be investigating this further. Follow progress via this Github issue.
SEC-01-017 WP3: Lack of Full Disk Encryption
This is a known issue that is mitigated by having all source data and messages encrypted at rest. See this issue for details.
SEC-01-018 WP3: Insufficiently Restricted Host-Based Firewall
We will be investigating this further. Follow progress via this Github issue.
Supply chain analysis
With the recent focus on supply chain attacks following Solarwinds and other high-profile compromises, auditors examined our APT repository servers (no issues found) and our compliance with the “Supply-chain Levels for Software Artifacts” framework, better known as SLSA.
The auditors found that we met Level 1 of SLSA, but are prevented from reaching Levels 2 and 3 because builds are currently done on developers’ workstations instead of on a dedicated build machine, which is a requirement for Level 2. (We already meet the specific requirements for Level 3.)
The SecureDrop build process is already containerized and consistent across developer workstations. We plan to finish our work on verifiable, reproducible builds, and will include improving our SLSA compliance as part of that.
Threat model
SecureDrop’s threat model has been refined over the years in consultation with security experts, journalists and sources. It is important that we stay up to date with changes to security practices and in the real world (e.g. shift to remote work).
One theme that we want to highlight across multiple threats is the handling of compromised or malicious users: once an attacker or malicious user has access to SecureDrop, there is little to stop them or slow them down within their level of access. Additional safeguards like further MFA checks and accountable logging could be beneficial. The all-powerful “Administrator” role also merits reconsideration: for example, should it be split into a “web admin” role (creates new accounts, resets passwords, etc.) and “server admin” (full access via SSH)?
Along that vein, we’re planning to redesign SecureDrop’s MFA model so that it is user-driven, as in most web applications today, rather than administrator-driven. Some of the other recommendations we’ll be acting on in forthcoming tickets (tagged “2024 audit recommendation”), while the rest will be taken into consideration for the next update to our threat model and in the development of the next-generation SecureDrop.
Final thoughts
Overall we’re pleased with the auditors’ findings and believe they’re a testament to all of the work by contributors past and present to make SecureDrop a secure platform. While there’s always more hardening to be done, this audit confirms that the current generation of SecureDrop remains solid as we shift focus to developing the next-generation SecureDrop architecture.
Once again, we’d like to thank 7ASecurity for collaborating with us on conducting this audit and Open Technology Fund for sponsoring it.
Researchers may submit any security vulnerability either through our bug bounty program, or via encrypted email to securedrop@freedom.press (public key, fingerprint: 734F 6E70 7434 ECA6 C007 E1AE 82BD 6C96 16DA BB79).