In July, we announced the release of SecureDrop 0.3.4 and published the accompanying security audit by iSEC partners (now NCC Group). The audit found 10 issues, one of which – issue 7, Finding ID iSEC-15FTC-4 – was redacted. It was redacted because it was not an issue in SecureDrop itself, but in one of its dependencies. At the time, NCC Group and Freedom of the Press Foundation agreed that NCC Group should responsibly disclose the issue to the affected project's team, and that we would wait until the project team had had time to develop a fix before publicizing the issue.
It has been nearly 6 months since the issue was reported to the maintainers. Today, we received notice from NCC Group that the maintainers have given us permission to publish the details of the issue. Unfortunately, the issue has not been fixed. We are publishing the unredacted final report to raise awareness and potentially encourage open source contributors to lend in hand in resolving the issue. NCC Group has filed a bug on the project's public issue tracker.
What is the issue?
SecureDrop uses OSSEC, a popular open source host-based intrusion detection system (HIDS). The OSSEC architecture consists of a single central server, called the Manager, which monitors one or more systems. The monitored systems have programs called Agents, which collect a variety of information and forward it to the Manager for analysis and correlation.
The Manager and the Agents may communicate with one of two protocols: "syslog" or "secure". The "secure" protocol is a custom crypto protocol based on shared secret keys that are set up during OSSEC deployment. NCC Group reviewed the custom protocol and found two serious issues in its cryptographic design:
- Protocol messages are encrypted with the shared secret key using Blowfish in CBC mode. Unfortunately, the protocol uses a static initialization vector (IV) to encrypt and decrypt all messages. This essentially reduces CBC mode to ECB mode and fails to achieve semantic security.
- Protocol messages are not authenticated. Each message includes an MD5 hash of the plaintext payload with the encrypted content, but this is not a strong authenticator. Among other things, it violates Moxie Marlinspike's "Cryptographic Doom Principle".
For more detail, see the finding in the unredacted audit report.
NCC Group did not take the time to investigate a proof of concept (PoC) attack based on this vulnerability, but that is not surprising given the limited duration of their engagement and the fact that their focus was on SecureDrop, not OSSEC. Nonetheless, these are serious cryptographic design flaws that could lead to a practical attack in the future. We encourage all OSSEC users to examine their current deployments, consider the level of exposure of any OSSEC "secure" protocol traffic to potential adversaries, and make changes accordingly.
How does this affect SecureDrop?
Fortunately, a properly installed and configured SecureDrop instance is not vulnerable to this issue, due to network segmentation. This is because OSSEC protocol communication only occurs between the Application Server and the Monitor Server, which are both isolated on separate subnets and segmented from the rest of the network with a hardware firewall. As a result, the potentially insecure traffic is not exposed to any public network, and we believe it would be difficult for an adversary to access the OSSEC protocol traffic in order to perform an attack.
In the long term (in light of this issue and others), we are reconsidering our use of OSSEC for HIDS, and we have filed a GitHub issue to discuss alternatives.
