Unredacted SecureDrop 0.3.4 audit report

[Steve Kinney]

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