Live data from Hacker News

Private key of DigiCert Certificate Transparency log compromised

feistyduck.com

11–20 of 40 posts

Re: Private key of DigiCert Certificate Transparency log compromised

#11

Earlier quoted context omitted.

I'm pretty sure the SCT requirement contained the blast radius of this compromise to avoid anyone from actually being affected by it, so your comment doesn't really follow here. Also, DANE relies on DNSSEC [1], which is bad. https://sockpuppet.org/blog/2015/01/15/against-dnssec

Ah hello 2015, my old friend. DNSSEC is a Government-Controlled PKI -> Not if the root of trust is secured by a proof-of-work blockchain DNSSEC is Cryptographically Weak -> Not if zone operators upgrade to ECDSA as defined for DNSSEC in https://tools.ietf.org/html/rfc6605 DNSSEC is Unsafe -> NSEC3 is mentioned by the article itself DNSSEC is Expensive To Deploy -> We can make tools for this, so much has gotten easier…

> Not if the root of trust is secured by a proof-of-work blockchain

https://tonyarcieri.com/on-the-dangers-of-a-blockchain-monoc...

https://paragonie.com/blog/2017/07/chronicle-will-make-you-q...

> Not if zone operators upgrade to ECDSA as defined for DNSSEC in https://tools.ietf.org/html/rfc6605

First: That's a big "if". Lots of RSA legacy support.

Furthermore, ECDSA is so bad that Ed25519 and Ed448 are even coming to FIPS 186-5 later this year.

Citing ECDSA adoption in DNSSEC doesn't make as strong of a case as you might think.

Re: Private key of DigiCert Certificate Transparency log compromised

#12
post #6

As I understand it, this is not a big deal: there are multiple CT servers, and auditors verifying their entries, the design of the system assumes the possibility of compromised log operators.

Well the political consequences are kind of bad. CA system is built around trust. Not being able to secure their servers, even non critical ones, degrades trust.

Re: Private key of DigiCert Certificate Transparency log compromised

#13
post #12
post #6

As I understand it, this is not a big deal: there are multiple CT servers, and auditors verifying their entries, the design of the system assumes the possibility of compromised log operators.

Well the political consequences are kind of bad. CA system is built around trust. Not being able to secure their servers, even non critical ones, degrades trust.

The CT system is built around controlled suspicion, not trust.

Re: Private key of DigiCert Certificate Transparency log compromised

#14

This was reported first at the begining of May. They got into the server via that Salt vuln and just ran crypto miners on the server, they didn't (as far as anyone knows) use the keys to do anything bad. From the original email reporting the problem: (the attacker doesn't seem to realize that they gained access to the keys and were running other services on the instracture)

Cryptocurrency continues to improve security by polluting attackers with short-sighted incentives that prevent real damage from occurring.

I don't think cryptocurrency has changed much in that regard. Before CC mining the default use for an owned box was warez servers, IRC or jump hosts.

Re: Private key of DigiCert Certificate Transparency log compromised

#15

This was reported first at the begining of May. They got into the server via that Salt vuln and just ran crypto miners on the server, they didn't (as far as anyone knows) use the keys to do anything bad. From the original email reporting the problem: (the attacker doesn't seem to realize that they gained access to the keys and were running other services on the instracture)

Cryptocurrency continues to improve security by polluting attackers with short-sighted incentives that prevent real damage from occurring.

3 max-expensive "analytics" servers were how my company discovered a breach. "Why is our cost projected to go up so significantly?"

They were of course mining on GPUs.

Re: Private key of DigiCert Certificate Transparency log compromised

#16
post #14

Earlier quoted context omitted.

Cryptocurrency continues to improve security by polluting attackers with short-sighted incentives that prevent real damage from occurring.

I don't think cryptocurrency has changed much in that regard. Before CC mining the default use for an owned box was warez servers, IRC or jump hosts.

Those are much harder to detect, especially the latter two.

Re: Private key of DigiCert Certificate Transparency log compromised

#19
The problem with Transparent Logs / Certificate Transparency is that they don't have the best story with regarding to recovering from compromise. We wrote an article comparing The Update Framework (TUF) to CT/TL:

https://ssl.engineering.nyu.edu/blog/2020-02-03-transparent-...

Re: Private key of DigiCert Certificate Transparency log compromised

#20

This was reported first at the begining of May. They got into the server via that Salt vuln and just ran crypto miners on the server, they didn't (as far as anyone knows) use the keys to do anything bad. From the original email reporting the problem: (the attacker doesn't seem to realize that they gained access to the keys and were running other services on the instracture)

Nobody knows for sure what they were doing since the script dropped via the salt vulnerability downloaded new scripts and executed them every 60 seconds. Just because all they found were crypto miners doesn't mean it was the only thing it was doing. And also there were multiple groups exploiting this vulnerability at the same time as was evidenced in one of the scripts trying to detect and eliminate competing scripts dropped by someone else
Post reply on HN