Penetration Test Report (LeastAuthority): LeastAuthority Cryptocat audit report

Report of Security Audit of Cryptocat
(cid:127) Principal Investigators:
(cid:127) Nathan Wilcox <nathan@LeastAuthority.com>
(cid:127) Zooko Wilcox-O'Hearn <zooko@LeastAuthority.com>
(cid:127) Daira Hopwood <daira@LeastAuthority.com>
(cid:127) Darius Bacon <darius@LeastAuthority.com>
Contents
Overview 2
Audit Scope 3
Coverage 3
Target Code and Revision 3
Findings 4
Issue A. Disclosure of File Contents Due to Re-use Of Key and IV 4
Issue B. Integrity Key and IV Reuse in File Transfer 6
Mitigation for Issues A and B 7
Remediation for Issues A and B 7
Versioning 7
Generate per-file keys 8
New standard file transfer protocol 8
Issue C. Substitution of File Contents By Hijacking Entry in User Interface 9
Issue D. File Name, Mimetype, and Size Lack Confidentiality 11
Issue E. You Log Out, Attacker Logs in with the same Nickname, Your Friend Thinks 12
The Attacker is You
Issue F. Nicknames Can Be Invisibly Reassigned 14
Issue G. Capture of Sent Messages by Nickname Change 15
Issues Without Known Exploits 17
CTR-mode Overflow 17
Future Work 18
Protocol Analysis, Design, and Implementation 18
Multiparty Chat 18
File Transfer 18
OTR & Cryptographic Libraries 18
JavaScript Cryptography 18
Open Questions & Concerns 18
Recommendations 20
Coding Practices 20
Appendix A: The life cycle of the Cryptocat file transfer 21
Appendix B: Work Log 25
Appendix C: Exploit Code for Issue G 27
Overview
The Least Authority security consultancy performed a security audit of the Cryptocat messaging client, on
behalf of Cryptocat's sponsor Open Technology Fund. Cryptocat provides end-to-end encrypted chat
using a web browser add-on.
This report gives the results of the audit.
Audit Scope
The audit investigated essential security properties such as the confidentiality and integrity protection of
Cryptocat chat sessions and file transfers. The audit techniques included interactive penetration testing,
code and design analysis, and discussion with developers.
For the purposes of this audit, we assume integrity of the Cryptocat add-on installed by the user.
A well-known outstanding attack is the side channel of timing information emitted by the implementation of
cryptographic algorithms computing on secrets. It is an unsolved problem how to prevent that information
leakage with cryptographic algorithms implemented in JavaScript. This issue is outside the scope of this
audit.
Coverage
Our code audit covered all of the primary Cryptocat implementation in src/core/js, including
cryptocat.js, and everything inside etc/ and workers/. We reviewed third party code under lib/
only when relevant to a particular investigation, which by the end of the audit included all or parts of
bigint.js, crypto-js/, elliptic.js, multiParty.js, otr.js, salsa20.js, and strophe/.
In terms of feature sets, we focused primarily on cryptographic key management, the entropy system, the
newly developed file transfer feature, and relevant aspects of the user interface.
Some notable features which we did not deeply investigate are the multiparty chat protocol, the
implementation of the Socialist Millionaire's Protocol, and whether the Off-The-Record chat
implementation (otr.js) is a compatible implementation of the OTR protocol.
For the multiparty chat protocol, we spent some time comparing the specification and implementation.
However, we shifted focus away from this protocol for several reasons: First, we believe this protocol will
be replaced by one with wider support across academia and industry, such as mpOTR. Second, the
multiparty chat protocol specification would benefit from including or excluding more security features,
such as transcript soundness and consensus. Finally, the specification focuses on the "how" of
implementation and would benefit from more specificity of the "why" of security goals. We discuss our
general recommendations for multiparty chat protocol in the Future Work section.
Appendix B: Work Log describes our investigation process in fine detail.
Target Code and Revision
All file references are based on the v2.1.15 git tag of the Cryptocat codebase, which has revision id:
05ddc47d8c1beff4511199a011859ee046687614
All file references use Unix-style paths relative to the working directory root.
Findings
Issue A. Disclosure of File Contents Due to Re-use Of Key and IV
Reported: 2013-11-06
Synopsis: The file transfer feature re-uses a symmetric encryption key and IV in CTR-mode for multiple
file transfers in a single Diffie-Hellman session.
Impact: An eavesdropper can learn some or all of the contents of the transferred files under some
conditions.
Attack Resources: The attacker requires only passive collection of records of the HTTP traffic (or the
BOSH and XMPP protocol traffic embedded in those HTTP requests).
Feasibility: This attack requires only simple and efficient off-line computation once records of vulnerable
ciphertext traffic are known.
This loss of confidentiality occurs when more than one file is transferred through the file transfer feature
during a single Diffie-Hellman session.
There is no loss of confidentiality when only a single file is transferred.
This traffic is present at the XMPP protocol layer, which is embedded in HTTP (via BOSH). The HTTP
traffic of crypto.cat, by default uses TLS to and from the server.
A compromise is feasible through at least several vectors:
(cid:127) A server compromise (including malicious insiders) could allow live traffic sniffing to recover these
ciphertexts.
(cid:127) A server host compromise may grant access to log files containing recorded vulnerable traffic. (In
particular we know that ejabberd logs complete XMPP traffic when the log system is set to verbose.
Being based on Erlang infrastructure, it is feasible to increase log verbosity without any interruption
to the service, assuming appropriate permissions on the server.)
(cid:127) Browser logs or caches may contain recorded vulnerable ciphertexts.
(cid:127) Where TLS is deployed (including the production crypto.cat service), an active TLS attack against
TLS-protected servers could be used to leverage this attack.
(cid:127) Where TLS is not used, this attack is feasible at an unknown number of routers on the Internet.
Verification: We verified this issue by source code inspection, and by reproducing the use of identical
keys for more than one file transfer using debug output from an instrumented copy of Cryptocat. We also
used the debug output to investigate the extent to which key rollover impacts exploitation of the
vulnerability.
Implementation Analysis: AES counter-mode encryption is used to protect the confidentiality of the file
contents. The IV used for encrypting file contents is a fixed constant of 0. For the receiver, see
./src/core/js/etc/fileTransfer.js, line 255, inside Cryptocat.fileHandler. (The sender
and receiver must use the same IV for decryption to succeed. The IV is not transmitted, and instead both
parties rely on this implicitly known value. The sender IV code results in the same values, and we only
refer to the receiver code in this analysis.)
Files are transmitted in chunks of sequential bytes, and each chunk is encrypted separately. The IV
parameter, which begins at 0, is incremented for each chunk, as seen in ./src/core/js/etc/fileTransfer.js,
line 200. The actual IV passed to the encryption library is padded using an OTR convention as seen in
./src/core/js/lib/otr.js, line 298 and related functions, so this chunk index is encoded in the
high 8 bytes. The low 8 bytes are initialized to 0 and the low 4 bytes incremented by the AES
implementation for each block. This means that the same block index within the same chunk index is
encrypted with the same counter value (which is correct behavior for CTR mode).
The secret key used for file transfers is derived during Diffie-Hellman session initialization in
src/core/js/lib/otr.js, line 2163. A new DHSession is initialized whenever there is a "round trip"
of OTR data packets — client A sends a data packet to clie