An attacker who is able to gain access to both the Journalist Interface (JI) hidden service and a recent API session token could reuse that token against the web UI until it naturally expires (8 hours). We consider this to be a low severity vulnerability because it requires an attacker to first gain access to the secret JI onion address, the authentication token, and a non-expired API session token. Despite the exploitability requirements, given the potential impact, this vulnerability is classified as "Medium" with a CVSSv3 score of 5.0. Thank you to brian-1, who first reported this to us through the SecureDrop bug bounty program, we've awarded $500 for the discovery. We'd additionally like to thank the other 25+ reporters who notified us about this issue. Score breakdown | Factor Name | Factor Value | Description | |---|---|---| | Attack Vector (AV) | Network (N) | The attack can be performed against any unpatched SecureDrop Server. | | Attack Complexity (AC) | High (H) | Given the requirement to first gain access to the secret Journalist Interface, complexity is High. | | Privileges Required (PR) | High (H) | An attacker must also have access to a recently valid API session token. | | User Interaction (UI) | None (N) | No user interaction is required. | | Scope (S) | Unchanged (U) | The vulnerability lies in the Journalist Interface and only gives access to that component. | | Confidentiality (C) | Low (L) | Confidentiality impact is low, because the attacker would only gain access to encrypted submissions. | | Integrity (I) | High (H) | Integrity impact is high, as a compromised journalist would have broad access to all source submissions. | | Availability (A) | None (N) | There is no availability impact as a compromised journalist is not able to affect the running system. | Technical details SecureDrop Server is a Flask application that runs using mod_wsgi with Apache. In 2.5.0, journalist sessions were changed to be stored server-side in Redis and split between the API and web UI so the two could have different expiries and renewal policies. The implementation of the SessionInterface contained a mutable session key prefix that differed between the web and API sessions. The vulnerability is that when the session prefix is changed based on an incoming request, that state persists between requests, allowing an attacker to take advantage of the prefix corruption to use a API session against the web UI. Additionally because the session prefix was corrupted, logging out may not properly delete the session out of redis, however it would still expire within a few hours based on the normal redis expiry. We are not aware of any exploitation in the wild. As explained earlier, this attack requires significant prior compromise of a SecureDrop server before it can be performed.