Asymmetric private keys are among the most often leaked out, so we’re open sourcing a tool that immediately tells you if one is sensitive.

Check it out here: https://github.com/trufflesecurity/driftwood

With this tool we found the private keys for hundreds of TLS certificates, and SSH keys that would have allowed an attacker to compromise millions of endpoints/devices.

Asymmetric private keys have a number of different use cases, but two of the most common use cases are TLS and SSH.

Today the status quo for triaging a private keys at best involves a cursory check of the surrounding context to see if there’s any clues that could help us figure out if it’s a sensitive key.

Running TruffleHog on the Twitter GitHub organization returns about 25 Private Keys, and the Netflix Organization returns about 4811 Private Keys. Not only is this a tremendous amount of code to review, the surrounding context doesn’t always give us the answer. This is the status quo for most organizations, these keys were not unique or exceptional to Twitter and Netflix.

We compiled a database of billions of TLS and SSH public keys that we know pair with sensitive private keys. Driftwood will take a given Private Key, extract its public key component, and then post the public key to our database to see whether it pairs with a known sensitive key.

Of the thousands of keys from Twitter and Netflix, none of them matched TLS and SSH keys that we had in our database.

Driftwood showing a leaked Private Key matches 2 TLS certificates

We obtained these billions of keys from 2 main sources (though we will be adding new sources in the future)

The first source is through Certificate Transparency. Certificate Transparency is a public log containing all TLS certificates created after 2018. TLS Certificates include a public key, allowing us to index every single public key used for TLS today.

We sampled about 50,000 private keys we were able to find on the internet, and found hundreds of certificates that matched with these keys, many of which had not expired and needed to be revoked.

In the example screenshot above a single Private Key was connected to multiple certificates. This means even though in this case one of these certificates was in the surrounding context, the traditional way of triaging this key would not have sufficed in finding all the affected certificates.

It’s worth noting it’s best practice to not re-use Private Keys, but we found this practice to be quite common. Even though Certificates expire, the underlying private key never expires and nothing prevents the key owner from using it again and again in future certificates.

SSH Key from Github

The second main source for keys was GitHub SSH keys. Developers often have a single SSH key they use from their workstation, and they add the public key for this key to the machines they want to SSH into.

Among those is often GitHub, which allows you to authenticate yourself with SSH. Because GitHub lets you query these SSH keys for other users, we are able to use Driftwood to quickly figure out if a private key happens to pair with a GitHub user

Driftwood Finds an SSH key

When this happens, typically the same SSH key can be used to SSH into many other servers that the developer has access to.

We were able to find dozens of GitHub user’s SSH private keys in our 50,000 sample. These dozens of keys had push rights to hundreds of GitHub code repositories, which includes repositories owned by IBM, Arm, and Oracle. These keys likely could SSH into many servers other than GitHub as well.

This presents itself as a cascading supply chain issue, because some of these repositories the keys could push to are quite large which many down stream dependancies and users become impacted to malicious pushes. We estimate the total number of devices that were consuming the hundreds of impacted repositories to be in the millions.

Another way of putting this: these keys could have put malicious code on millions of devices. Fortunately we got them rotated.

What was really interesting to see was in many examples the keys found were in repositories seemingly totally unrelated to the impacted user, and in some cases were in directories marked as “test” or “tutorial”. These keys very likely would have been ignored in a code review. One example was a key in a directory labeled “tools/lab_key” and another in a directory labeled “tests/test_jssign/id_rsa” (paths slightly modified to protect anonymity). In both cases the repositories where not owned by the impacted users.

Cracking Encrypted Private Key

In our 50,000 sample we also found about 2500 Private Keys encrypted with symmetric encryption keys. We were able to almost immediately guess the passwords for over 70% of these keys. For this reason we are also including a very basic word list in Driftwood that can guess the top 250 most common passwords.

Here’s again a link to the repo https://github.com/trufflesecurity/driftwood

Happy hacking!