Driftwood: Know if private keys are sensitive

https://trufflesecurity.com/blog/driftwood

by orangepenguin • 5 years ago

78 20 5 years ago

trufflesecurity.com

midasuni• 5 years ago

This was flagged and marked dead at https://news.ycombinator.com/item?id=29152572

Which is a shame, thanks for resubmitting

orangepenguin• 5 years ago

Ah! That's what happened! I read the article and then came back to HN and couldn't find it. I thought I was crazy...

nijave• 5 years ago

Why are there so many private keys in repos? It seems preferable to just generate them when needed instead of risk one being misused

codetrotter• 5 years ago

Committing private keys is definitely the wrong thing to do. But if the system is talking to something, then generating new keys won’t help either. What you need is some kind of system to deploy or retrieve secrets. There are various different solutions that exist for this.

koolba• 5 years ago

And the system for deploying or retrieving secrets itself needs secrets to authenticate with the secrets manager.

Or you generate them on the fly at deployment so that they only exist ephemerally outside the deployment site.

riverdroid3• 5 years ago

Most private keys in Git repositories seem to be test data. But why are those test private keys sometimes used for other things? Probably just people lazily copying from ~/.ssh/idrsa or copying to ~/.ssh/idrsa.

xvector• 5 years ago

Private keys for tests should be generated on demand, lest you induce CI failure due to key expiration some years down the line

nixpulvis• 5 years ago

I'm sorry, what?! All private keys are sensitve.

Please be more spesific.

riverdroid3• 5 years ago

If you search GitHub, you can find ~4M results for PEM private keys: https://github.com/search?q=PRIVATE+KEY-----&type=Code

Many are for tests and don't go to anything. Some go to really important things though, even among the test keys, and this tool tells you that instantly for billions of keys.

xssoauth• 5 years ago

Here's a key I just made, why's it sensitive?

dilyevsky2• 5 years ago

Do you have a hackerone account? i need to collect my bounty

iso1210• 5 years ago

The public key can be derived from the private key

They then check both certificate transparency to see if the public key matches any certificates that have been generated, and to see if it's used by a github user (will this public key let me in to a github repo)

If neither, then it's not sensitive (well it might be, but only like finding a key on the floor in the street is -- won't do you much good without knowing where you can use it)

In the first case, if you have the private key, you can spoof the website

In the second case, if you have the private key, you not only have push access to the repos that user has (which could be quite wide ranging), but also you're likely able to get into many servers via SSH, as developers tend to use the same ssh key for github and for server access

What their latest software does is take your key and check it against these sources,

Now private keys have a further layer of protection - the passphrase. Turns out the majority of passphrases belonging to the leaked private keys are trivial ones.

Many leaked keys will unlikely to be used anywhere, but it turns out many more are.

aetherspawn• 5 years ago

About as sensitive as a lock/key that I buy from the supermarket and sits in a drawer never used, sure.

seanieb• 5 years ago

Oh this is interesting. Often bug bounty’s claim a published private key wasn’t in use or sensitive. This gives researchers the ability to call BS on that.

malchow• 5 years ago

Congrats to Dylan and team on this release; incredibly cool - more companies, especially those for whom software is a functional organization but not the primary one -- need to take key leaks seriously.

tialaramex• 5 years ago

One thing that you'll see happen is, something is supplied with an example or test key and at some point somebody who doesn't understand what's going on need a "Private key". Huh. Where can I get a "Private key"? Oh, here's one, I'll use that. Sometimes it's in the context where it was found, but sometimes far away from that.

For example, back in March 2020, somebody on m.d.s.policy wondered why seemingly unrelated Web PKI certs had the same private key. So I stared at the certs and I came to the following conclusion:

This company Paessler makes a Windows tool called PRTG with a web interface. It is supplied with a demo certificate. So you set up the tool on a Windows server and it basically works, but the certificate isn't trustworthy.

Some people will click "Ignore" and press on. This is horribly insecure but what's new?

However, some people will decide they need to get a Certificate. Getting a certificate requires a Private Key. Fortunately, PRTG is supplied with a Private Key so no need to go learn how to make one yourself.

So, the people who made PRTG didn't screw up here in the sense that they really did make a test or demo key, and from their point of view obviously it isn't sensitive since everybody has the same key.

Unfortunately their users may not realise and come to depend on this key as "their" private key, and so in this sense it is sensitive, just not for the people who made it.

Regardless of who minted the key you have, and whether they understood its importance, in the Web PKI the correct thing to do is always the same and should be pretty easy:

Revoke the certificates for these public keys. Email contacts or Instructions are here: https://ccadb-public.secure.force.com/ccadb/AllProblemReport...

For Let's Encrypt you can actually do this mechanically, their API will accept proof you know the private key as grounds to revoke the certificate even though that's not listed above.

If the CA refuses to revoke a certificate you've genuinely proved you have the key for (follow any instructions carefully) or just goes silent with no action for a prolonged period, report this problem to m.d.s.policy yourself. You should not need to send the private key itself to anybody as "proof" you have it, the whole point of private keys is that you can prove you know this key without revealing it.

riverdroid3• 5 years ago

Thanks for the revocation resources! I was not aware of LE's revocation API. Seems like maybe reporting should get built in as an option.

Driftwood: Know if private keys are sensitive

Related Stories