
Private key of DigiCert Certificate Transparency log compromised - CiPHPerCoder
https://www.feistyduck.com/bulletproof-tls-newsletter/issue_65_private_key_of_digicert_certificate_transparency_log_compromised
======
blakesterz
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)

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

~~~
nailer
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.

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

~~~
nailer
I'm not sure. Most crackers don't use port knocking or other obfuscation
techniques, so something that shouldn't be listening on a box and a large
amount of bandwidth being used is normally a good indicator.

~~~
gruez
I think there's great overlap between servers that aren't monitored and
servers that are vulnerable to exploits. If you're monitoring your servers for
unknown listening ports, chances are you're keeping your systems up to date.
Same with bandwidth, although if bandwidth is expensive (eg. cloud providers),
your accounting dept might notice.

~~~
nailer
> I think there's great overlap between servers that aren't monitored and
> servers that are vulnerable to exploits.

Agreed. CC mining would be CPU on most servers, and go undetected for the same
reasons. Some servers and gaming rigs would have GPUs, but not many vs CPUs.

------
dang
See also
[https://news.ycombinator.com/item?id=23062904](https://news.ycombinator.com/item?id=23062904)
from a few weeks ago.

------
trishankdatadog
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-...](https://ssl.engineering.nyu.edu/blog/2020-02-03-transparent-
logs)

~~~
tialaramex
Your blog post is about yet another X Transparency, rather than about
Certificate Transparency. Because CT works well people tried to apply the same
approach to lots of other problems, most of them obviously dumb.

CT is a narrow solution to a narrow problem. We had that specific problem, and
so this is a very good solution. You almost certainly don't have that problem,
our solution can't help you, we aren't sorry about that.

~~~
trishankdatadog
Strange comment. I'm not sorry you're not sorry either.

------
cjbprime
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.

~~~
bawolff
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.

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

~~~
bawolff
Sure, but if i can't trust someone to run a CT server, why would i trust them
to run a CA?

~~~
cjbprime
It was a 0day in a popular open source package. They didn't do anything wrong.
Presumably they use stronger defense in depth, as required by the CA
guidelines, to prevent software compromises to the actual CA signing machines.
There's no need to go through that level of paranoia for CT log machines.

------
Simulacra
This is a little bit of old news and sounds worse than it is. There are plenty
of checks and redundancy operators in the CA auth universe.

------
rasengan
This CA system is designed for maximum reduction in security - not defense in
depth. The company with the least security defines the security of the entire
CA system.

It’s time for DANE [1]. We don’t need any more “men in the middle.”

[1] [https://en.wikipedia.org/wiki/DNS-
based_Authentication_of_Na...](https://en.wikipedia.org/wiki/DNS-
based_Authentication_of_Named_Entities)

~~~
some_furry
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](https://sockpuppet.org/blog/2015/01/15/against-dnssec)

~~~
rasengan
> 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.

I think this would be true except my statement wasn't just about SCT but the
CA system in general. Furthermore, browsers like Firefox [1] do not even have
CT checks.

> Also, DANE relies on DNSSEC [1], which is bad.

Handshake completes this system [2].

[1]
[https://bugzilla.mozilla.org/show_bug.cgi?id=1281469](https://bugzilla.mozilla.org/show_bug.cgi?id=1281469)

[1a] [https://developer.mozilla.org/en-
US/docs/Web/Security/Certif...](https://developer.mozilla.org/en-
US/docs/Web/Security/Certificate_Transparency)

[2] [https://github.com/handshake-org/hdns](https://github.com/handshake-
org/hdns)

~~~
Spivak
Despite being supported, relying on browsers checking CT logs was never
something that what going to be deployed at scale because, just like
revocation lists, it adds a performance hurdle to every request.

Auditors and monitors are the real protection you get from CT logs.

You get the same problem with any form of DNS validation because you'll never
get every little caching server to validate records.

