Introducing Dexter

Prioritizing security is not just a part of Coinbase’s culture, it’s necessary to our success. Traditional financial institutions have always required a high level of security to protect their customer’s privacy and prevent fraud, but due to the nature of cryptocurrency Coinbase faces an even higher level of risk.

Possession of a private key is control over the currency secured by that key, which removes a step in the monetization of a theft. Rather than needing to sell stolen data, or perform identity theft to turn a data breach into a profit, theft of a private key leads to an immediate financial reward for the attacker. Once a crypto transaction is confirmed, there’s no recourse, no reversals.

Part of any good security program is good visibility into the environment, which runs counter to the notion that sensitive information, like private keys, should be inaccessible. For incident response purposes, Coinbase needs to be able to collect any information off of even our most sensitive services. We needed a remote, real-time forensics acquisition solution built for security. In order to solve this problem we turned to one of our guiding security principles, consensus, and created a new forensics framework called Dexter .

There are already several great forensics acquisition projects out there for every major operating system, and it doesn’t make sense to invest time re-inventing the wheel. Dexter is designed to wrap other tools, where available, to perform forensics tasks. The place that Dexter advances beyond the capabilities that were already available in other tools is the secure approval process for investigations, and the secure retrieval process for forensic artifacts.

We started by defining our security requirements. The last thing we wanted to build was remote code execution as a service, so we decided that all forensics tasks must be codified in the application and added through our code review process. We also wanted to ensure the artifacts collected by forensics tasks were end-to-end encrypted back to the investigators that had permission to read them, removing any trust in our infrastructure. In order to achieve our goals for consensus, each member of the response team is identified by a public key and an investigation must receive a number of signatures that correspond to the sensitivity of the tasks defined in the investigation.

Dexter runs as a daemon, ready to collect forensics artifacts when an investigation reaches the required consensus threshold. This daemon is designed to work in a variety of environments, from a linux production environment in EC2 to an OSX or windows fleet in the office. Investigators interact with Dexter using the command line, where they can issue investigations and retrieve reports, all backed by S3.

The same binary used to start the daemon is used on the command line. To get an investigation into a Dexter daemon, an investigator will use the command line to generate an investigation, sign it, and upload to S3. When creating an investigation, an investigator will decide what tasks to run, and what facts about a host will be used to scope the investigation. The investigator can also instruct Dexter to kill the running containers on a host, or shut down a host, after the investigation is complete. Finally, the investigator can choose which investigators are allowed to read the results of this investigation.

The investigations that get uploaded are simple JSON documents. In this example we see the random ID for the investigation, the forensics tasks to run, and the facts used to scope the hosts that will run this investigation. Dexter has an ability to obscure arguments to some facts using a hash salted with the investigation ID. In this example, the user is obscured so that other hosts that are not in scope would have a hard time determining which user is under investigation.

As other investigators approve this investigation, they will append their signature to the Approvers key, and upload the updated version to S3. Once the investigation reaches consensus, all the hosts in scope will run the selected tasks and create encrypted reports for the selected investigations. When interacting with investigations and reports on the command line, only a minimal amount of the investigation’s ID must be specified to disambiguate the investigation.

Control over who can read investigations is done with a KEK/DEK model (Key Encryption Key, Data Encryption Key). For each investigator who is approved to read the results, Dexter generates a new random AES key, encrypts the report, then encrypts the key with the investigator’s public key. Each investigator can then access their report with their private key.

You can learn more about using Dexter from the repository . The command line is also fully documented here . Dexter is extended by creating new tasks and facts, based on the example task and example fact files.

We’re building a larger vision of incident response at Coinbase that uses automation to reduce the amount of time it takes to get an investigator in front of relevant data. Dexter provides the mechanism to securely collect data. In the future, Dexter will be operated in part by our internal IDS, and once an incident is detected, a secure analysis environment will be created in EC2 to investigate the Dexter reports. This environment can be rich with tools, and have extra protections in place to make sure sensitive data doesn’t make it back to an employee machine. We still have a way to go before our vision is realized, but we’re building it every day.

Dexter is still in its infancy and just beginning to be rolled out, but it was important to me to share this project as soon as possible in order to get feedback from the broader security community. Earlier this year we released Salus , which brings the best application security scanners under one roof. If you think you’d enjoy working in an environment where security is a top priority, reach out to Coinbase , we’re always looking for talented security professionals in all fields.