Publishing the unredacted SecureDrop 0.3.4 audit report
Garrett Robinson
December 11, 2015
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.
Threats to press freedom around the world are at an all-time high. Sign up to stay up to date and take action to protect journalists and whistleblowers everywhere.
Thanks for signing up for our newsletter. You are not yet subscribed! Please check your email for a message asking you to confirm your subscription.
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:
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.
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.