Penetration Test Report (UniWashington): UW CSE 13 08 02

DeadDrop/StrongBox
Security Assessment
Prepared On:
August 11, 2013
Performed By
Alexei Czeskis <aczeskis@cs.washington.edu>
David Mah <mahh@cs.washington.edu>
Omar Sandoval <osandov@cs.washington.edu>
Ian Smith <imsmith@cs.washington.edu>
Karl Koscher <supersat@cs.washington.edu>
Jacob Appelbaum <jacob@appelbaum.net>
Tadayoshi Kohno <yoshi@cs.washington.edu>
Bruce Schneier <schneier@schneier.com>
University of Washington
Department of Computer Science and Engineering
Technical Report: UW-CSE-13-08-02
Table of Contents
EXECUTIVE SUMMARY ........................................................................................................................................ 3
1.) ASSESSMENT SCOPE AND GOALS .............................................................................................................. 5
2.) BACKGROUND: DEADDROP THREAT MODEL AND GOALS ............................................................... 5
2.1) ASSETS ................................................................................................................................................................................ 6
2.2) ATTACKERS ....................................................................................................................................................................... 6
3.) DEADDROP DESIGN ASSESSMENT ............................................................................................................ 7
3.1) USAGE OVERVIEW ............................................................................................................................................................ 7
3.2) INFRASTRUCTURE OVERVIEW ....................................................................................................................................... 7
3.3) DESIGN ANALYSIS ............................................................................................................................................................ 9
4.) OBTAINING DEADDROP CODE/DOCUMENTATION ......................................................................... 11
4.1) ISSUES WITH SOURCE CODE ACCESS CONTROL ....................................................................................................... 11
4.2) ISSUES WITH BRANCHING AND VERSIONING ........................................................................................................... 12
4.3) TYPOSQUATTING ........................................................................................................................................................... 12
5.) DOCUMENTATION ASSESSMENT ........................................................................................................... 12
6.) IMPLEMENTATION ANALYSIS ................................................................................................................. 14
6.1) USABILITY ISSUES ......................................................................................................................................................... 14
6.2) ATTACKS ......................................................................................................................................................................... 15
Leaking the Source’s Identity ........................................................................................................................................ 15
Denial of Service Against Journalist ........................................................................................................................... 17
Codeword collision ............................................................................................................................................................ 17
7.) DEPLOYMENT AT THE NEW YORKER .................................................................................................... 18
7.2) TEST SUBMISSIONS ....................................................................................................................................................... 19
8.) USAGE ISSUES ............................................................................................................................................... 19
8.1) ATTESTATION OF SERVER-­‐SIDE CODE ...................................................................................................................... 19
8.2) ANONYMITY BEYOND DEADDROP ............................................................................................................................. 20
9.) CONCLUSION AND RECOMMENDATIONS ............................................................................................ 20
A.) APPENDIX: DOCUMENTATION ANALYSIS ........................................................................................... 22
A.1) THREAT_MODEL.MD ............................................................................................................................................... 22
A.2) README.MD (INSTALLATION INTRUCTIONS) ....................................................................................................... 24
About Us
We are a group of independent academic and industry security researchers who have no stake
in the outcome of this assessment. We performed this security assessment free-of-charge and
independently of the developers of this software or of any party using this system. This audit
was done purely as a public service. This is a technical report; while we believe that the
technical results are correct, the surrounding discussion may not reflect all of the authors’
personal opinions.
2
Executive Summary
Several media articles1 have recently reported on a newly developed system called DeadDrop,
which is specifically designed to provide anonymous communication between individuals
(sources) and journalists in the face of very powerful adversaries (e.g., oppressive regimes)2.
Initially designed and developed by the late Aaron Swartz, DeadDrop comes at an interesting
time when leaked documents are being discussed in the media3. If DeadDrop takes off, it could
significantly change the way that journalists and individuals communicate anonymously across
the world, which could have a significant impact on a wide variety of reporting.
DeadDrop has the goal of being secure against adversaries that can (and there is precedent for
this) monitor communications of the press and pursue (and punish) whistleblowers. Given that
DeadDrop has already been deployed by at least one prolific media organization, The New
Yorker4, we wanted to understand whether DeadDrop actually provides the security properties
necessary for anonymous communication in the face of such strong adversaries.
We acknowledge that DeadDrop can be used for many purposes, ranging from those that some
might argue as ethical and legal to those that some might argue as unethical or illegal. We
observe that similar statements have been made about other types of security technologies in
the past. For example, in the past people have argued that making email encryption broadly
available was unethical -- despite its clear benefits in many legitimate scenarios -- because
email encryption could be used for illegal purposes. In this document, we take no stance on
the ways in which DeadDrop should be used, but rather focus on the system design,
implementation, and usability in the ways that the system does or does not support anonymous
communication.
Generally speaking, DeadDrop is designed to work as follows: a media organization deploys
DeadDrop on its servers. Individuals (sources) who want to anonymously communicate with
journalists visit the organization’s DeadDrop deployment page and are shown four random
codewords, which the source is supposed to remember. The source is then shown a page that
allows him or her to submit messages and documents. The DeadDrop system is designed to
encrypt all messages and documents in such a way that only the journalists are able to decrypt
the