Penetration Test Report (Leviathan): SpiderOak Crypton pentest Final report u

CRYPTON SECURITY AUDIT
FINAL REPORT
MARCH 24, 2014
Leviathan Security Group
3220 1st Ave. S., #100
Seattle, WA 98134
Internal Distribution Only 3/24/2014
Table of Contents
Crypton Design and Implementation Evaluation ...................................................................................... 3
Summary ............................................................................................................................................. 3
Secure Remote Password (SRP) ........................................................................................................... 3
Primary Security Issues ........................................................................................................................ 4
Crypton’s Unsolved Problem................................................................................................................ 4
Takeaways ........................................................................................................................................... 4
Observations ........................................................................................................................................... 5
Server-to-Client Attacks ....................................................................................................................... 5
Client-local attacks .............................................................................................................................. 8
Client-to-Server Attacks ..................................................................................................................... 11
Client-to-Client Attacks ...................................................................................................................... 12
SRP .................................................................................................................................................... 12
Appendix A: Vulnerability Classification ................................................................................................. 16
Appendix B: Project Team...................................................................................................................... 17
Page 2 of 17
Internal Distribution Only 3/24/2014
Crypton Design and Implementation Evaluation
Updated 04/14/14: A previous version of this report contained a non-security finding. As the finding had
no bearing on the security of the system, it has since been removed.
Summary
Leviathan recently took a critical look at a technology currently in development by SpiderOak called
Crypton. Crypton, an open-source project hosted on github, aims to be a zero-knowledge,
cryptographically-secure storage framework upon which zero-knowledge cloud applications can be
written. Its primary functional goal is to provide assurance that data stored on the server can only be
read by the client who possesses the key and cannot be read by the server or anyone else.
For the version Leviathan reviewed, Crypton was still in development, and we would characterize its
readiness as “pre-alpha.” As we write this, major components are still being written while others are
being rewritten. With that in mind, we were tasked with reviewing two parts of the Crypton framework:
a feature called “Sharing” and Crypton’s implementation of the Secure Remote Password (SRP) protocol.
Since time allowed, we also reviewed the non-SRP login procedures.
Crypton consists of a server and a client, both of which are written in Javascript. The server code,
running on node-js, accepts requests from the client and stores or retrieves the appropriate information
from a database. The client does most of the heavy lifting; it encrypts, decrypts, signs, and verifies all the
user-supplied data. In its current form the client code is pushed to the browser from the server.
SpiderOak’s true implementation target is for the client code to be in a browser extension or mobile
app. An unusual part of Crypton’s threat model is that server itself is considered untrusted. That is to
say, in all scenarios we anticipated that the server could be acting against the clients. As such, the clients
should not trust anything the server gives them. This attribute of the system strongly shaped our
assessment.
Secure Remote Password (SRP)
SRP, defined by RFC 2945, is an authentication protocol whereby clients do not reveal their password to
the server. SRP is also resistant to replay and man-in-the-middle attacks. We encourage readers to
review the brief RFC to understand the workings of the protocol. Unfortunately, SRP is not designed to
resist modern password cracking attacks – the Verifier1, as defined by the RFC, is merely two rounds of
SHA1 plus a modular exponentiation; we would not describe this as robust against modern cracking
techniques and tools. As a result, when we consider the scenario for Crypton where the server is
malicious, the server itself could execute password cracking attacks against the verifier to gain
decryption keys to a user’s information. While Crypton’s implementation used SHA256 instead of SHA1,
1 The Verifier (v) is defined as:
x = SHA(<salt> | SHA(<username> | ":" | <raw password>))
v = g^x % N
Page 3 of 17
Internal Distribution Only 3/24/2014
we recommended use of bcrypt as the hash function. Bcrypt is well-known for being computationally
intensive, which results in improved password cracking resistance.
Primary Security Issues
With an understanding of what Crypton intends to be and generally how it works, we examined it with a
critical eye and observed places where things could go wrong. Upon successful login, the server sends
the client its encrypted account information. The client then generates its master decryption key and
begins decrypting its account information. Examining this, we observed three key issues:
 First, the account’s public key is stored without verification that it corresponds to the decrypted
private key; this could allow the server to replace it which would result in the user encrypting
messages to themselves that they cannot actually decrypt.
 Second, we saw the same issue with the account’s public signing key; it is not being verified
against the decrypted private signing key.
 Third, the containerNameHmacKey is not verified before decryption which means that the
server could actually replace it with a different one that it knows by encrypting a new symmetric
key to the user’s public key.
Crypton’s Unsolved Problem
Every user-to-user encrypted messaging platform (including OTR, Cryptocat, and TextSecure) has
authentication limitations. Users are not fully sure that they are talking to the intended party. Crypton is
no different – since the server cannot be trusted, a given client cannot be sure the server is sending the
correct public key when they first interact with another user. Each of the aforementioned platforms
handle this problem in its own way, and we look forward to seeing what kind of innovative method
Crypton implements to handle this.
Takeaways
Crypton is an ambitious and novel platform. To our knowledge, no one else has set out to create a
similar framework for building future secure cloud applications. Based on the state of Crypton at the
time of Leviathan's review, the groundwork seemed to be nearly complete, and the development team
stated that it is working on significant improvements to the developer’s experience. In particular, the
team has already figured out how to index encrypted data to allow for searchable diary entries. They are
in the process of creating higher-level libraries to handle complex data structures and algorithms, all
implemented atop the encrypted block storage provided by Crypton.
Throughout the review we had an ongoing conversation with Crypton’s developers about the kinds of
real-world applications one might build using their technology. A particularly interesting example was
that of a zero-knowledge, encrypted cloud calendaring system (wh