A recent audit of SecureDrop by 7ASecurity found one medium-severity and several low-severity security issues. This audit is part of our commitment to routinely audit and harden the system.

Fixes for the following issues are in SecureDrop 2.10.0, released today; SecureDrop Application and Monitor Servers will be updated automatically within 24 hours. No manual administrator action is required. In all cases, an attacker would have needed to discover other vulnerabilities to exploit these issues.

This post explains the issues we fixed; a future blog post will discuss the full audit results.

SEC-01-001 WP4: Arbitrary 2FA Enrollment via IDOR (Medium)

An administrator could view other journalists’ TOTP secrets by visiting URLs like /admin/2fa?uid=1 in the Journalist Interface. This has been fixed by adjusting the two-factor authentication (2FA) setup process to no longer accept arbitrary GET requests.

In order to exploit this, an attacker would need to compromise an administrator's login and 2FA credentials, discover the hidden service onion URL for the Journalist Interface, and obtain the administrator's client authorization private key, which is stored locally on the administrator's Tails-based workstation.

Future changes to the 2FA workflow are planned to allow users to set up 2FA themselves without administrator intervention.

SEC-01-003 WP4: Possible User DoS via Logout CSRF (Low)

Logout in the Journalist Interface could be done by a GET request and did not protect against cross-site request forgery (CSRF). This has been fixed by requiring POST requests and an anti-CSRF token.

During review of this finding, we implemented setting SameSite=Strict on session cookies for both the Source Interface and Journalist Interface.

An attacker would have needed to discover the Journalist Interface hidden onion service URL and convince a journalist to navigate to an attacker-controlled web page in order to attempt CSRF.

It is worth noting that as a security measure, any CSRF failure will invalidate the session and trigger a logout. This effectively means a logout DoS is still possible, but we believe invaliding the session is a more important CSRF mitigation.

SEC-01-008 WP3: Unauthenticated Access to Local Redis (Low)

An attacker who had already compromised the Application Server via physical access or remote code execution could log in to the Redis server without authentication. A randomly generated password is now generated during install/upgrade and accessible by the www-data user only. SecureDrop is intended to be run on a dedicated, isolated network protected from the outside world by firewall rules.

SEC-01-002 WP4: Insufficient Password Complexity Requirements (Low)

SecureDrop generates strong diceware passphrases for journalists to use as a way of preventing weak or reused passwords. A journalist could have sent a specially crafted request to bypass this requirement and use any desired password as long as it had 7 words (e.g., “1 1 1 1 1 1 1” would have been accepted).

The server now verifies the exact same passphrase the server generated is submitted back by the user.

Other changes

The following changes unrelated to the audit are also included in 2.10.0:

• sequoia-openpgp (Rust crate) from 1.20.0 to 1.21.1 (Pull Request)
• setuptools from 56.0.0 to 70.3.0 for CVE-2024-6345 (Pull Request)
• openssl (Rust crate) from 0.10.60 to 0.10.66 for RUSTSEC-2024-0357 (Pull Request)
• Remove d2to1 and pbr (Pull Request)

Further changes can be found in the changelog on GitHub.

Translations

Because this security release was developed privately prior to 7A’s publication of their audit report, we did not solicit translation updates. Once translations (see documentation) have been completed, we plan to issue a point release with them.

What administrators need to do

SecureDrop Application and Monitor Servers will be updated to SecureDrop 2.10.0 automatically within 24 hours.

Please follow our upgrade guide, and get in touch with us if you require assistance.

Acknowledgments

Thank you to 7ASecurity for conducting the security audit and the Open Technology Fund for sponsoring it.

This release incorporates Freedom of the Press Foundation (FPF) contributions by Giulio B, Nathan Dyer, Kunal Mehta, Cory Francis Myers, Kevin O'Gorman, Francisco Rocha, and Rowen S.

Questions and comments

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).

SecureDrop administrators with any questions or comments regarding this release may contact us via our Support Portal.

We also encourage you to file non-sensitive issues you encounter in our GitHub repository (issue report form).

Thank you for using SecureDrop!