-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 An independent audit found a substantial deficiency in one of the dependencies of the SecureDrop document submission / management protocol. SecureDrop gave the devs time to fix it before publishing, but so far the issue remains unresolved: Publishing the unredacted SecureDrop 0.3.4 audit report https://freedom.press/blog/2015/12/publishing-unredacted-securedrop- 034-audit-report vs. https://tinyurl.com/hgeyab8 FTA: 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. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (GNU/Linux) iQIcBAEBAgAGBQJW24ZTAAoJEDZ0Gg87KR0LJHAP/ihVjalG8ZNc8kvIQxgSCRro DtwCzakkNSxPzCSjX28UMhDy2nnBkz6IIBBcMP7A7p40lQHKmRRhg34ceGgk1rOw 1SGrPZWeZCZH+s2T30mGHZDGskpe6tmnlZTajbZ5oEe3qSNW1soRqsYTa3K4vNC6 ezPV28SNIwUaqKZ3JWu1Z+QMnHW6lLsbmIpGmCRByAI5tYOYoxpyXEoxRb4sA9Iq //B1vJgfhkAdE7eES2aVGwAidOfPGUHi6M3mWy5TP912yMUok9YW2kyIqDisBpjr BMJRutGCiK9ih0OFiJig/kcHpENGROQVtD0cAa7mEJhBLUB/Mt4brYHT2+XQFSC6 rpjEBbm4iHr+0mn4JBZC+Op4ImJpU8Bhx26EaDU2t5xVZ3m3GFMTQal7PuMieZS+ 05vKIFHMJhkg0tOS6SqC62wKYuxy9XcvlaUlpXcAfnKn9E3tYXP1P2Ez5Ahuqhml WXiIX+JCbE9nLcvuK6IFUvTvWe62JTP3IXv38vP1tFi7j2OWlnYd5PsVsvJecT/U ibiUb/uw8gdsmLHmcAXEJ/YgWsIC7zOul8ORL7MGwa2rcytOf8i3ckUbA6dGM9iA 6nzM//V/H91DsHicngwZ9+zMQRtm3vmp+biXPsSv+fXGdRhxOGiePbrbeeEuVvqq d67XJxo5T/IpitF2L4j0 =gRP3 -----END PGP SIGNATURE-----