More Salt in their wounds: DigiCert hit as hackers wriggle through (patched) holes in buggy config tool

Miscreants too busy mining for crypto to notice the gold lying around them?

DigiCert, slinger of SSL/TLS certificates, has warned that it too has suffered at the hands of Salty miscreants as a key used for Signed Certificate Timestamps (SCT) was potentially compromised.

The company joins Ghost.org and LineageOS in being the target of ne'er do wells as attackers exploited a disclosed (and patched) vulnerability in the Salt configuration tool over the weekend, spraying exposed infrastructure with cryptocurrency mining software.

Salt, which as we reported, disclosed the bugs (CVE-2020-11651 and CVE-2020-11652) on Friday, is a system that allows a single host server to manage a cluster of other client servers, such as within a database or, in this case, a distributed log system.

In the case of DigiCert, it appears that attackers using the exploits could have gained access to a Certificate Transparency (CT) server's signing key - had they not been so concerned with getting the mining software running. However, since the DigiCert team could not prove that keys had not been requested, the prudent decision was taken to assume that nefarious activities had occurred and act accordingly.

For clarity, Digicert CT log 2 was deemed unsafe due the vulnerability.

— Jeremy Rowley (@GreatAmus) May 4, 2020

Writing in a forum for Certificate Transparency, DigitCert veep of business development, Jeremy Rowley assured users that "all other DigiCert CT logs are uneffected [sic] as they run on separate infrastructure."

"The attacker," said Rowley, "doesn't seem to realize that they gained access to the keys and were running other services on the [infrastructure]."

He said "any SCTs provided from that log after 7pm Mountain Standard Time yesterday (Saturday, May 2) are suspect."

Rowley added that "Digicert's CT logs are operated in a separate environment than CA operations. In fact, unique CT logs are operated [separately] from other CT logs so the event really is limited to CT2."

Still not great though, eh?

For its part, SaltStack SVP Alex Peay was keen to remind users that: "We must reinforce how critical it is that all Salt users patch their systems and follow the guidance we have provided outlining steps for remediation and best practices for Salt environment security."

The company added: "Clients who have followed fundamental internet security guidelines and best practices are not affected by this vulnerability."

Ouch.

Temporarily halting the Certificate Transparency service

Designed to help admins verify server certificates and spot fakes, the CT system keeps an ongoing log of timestamps for all signed SSL/TLS certs. The idea is that if a new certificate is spotted, someone can look it up and see exactly when it was created. DigiCert maintains several such logs, each on different infrastructures.

DigiCert told The Reg it was deactivating the Certificate Transparency (CT) 2 log server "after determining that the key used to sign SCTs may have been exposed via critical SALT vulnerabilities."

"We do not believe the key was used to sign SCTs outside of the CT log’s normal operation, though as a precaution, CAs that received SCTs from the CT2 log after May 2 at 5 p.m. U.S. Mountain Daylight Time (MDT) should receive an SCT from another trusted log."

Three other DigiCert CT logs - CT1, Yeti and Nessie - run on different infrastructures and were not affected, the company said.

"DigiCert has been planning for some time to shut down CT2, in order to move the industry toward our newer and more robust CT logs, Yeti and Nessie. We notified the industry of our intention to terminate signing operations of CT2 on May 1 but pushed back the date based on industry feedback. This timeline has now been moved up, with the CT2 log in read-only mode effective May 3," the company added.

Fortunately, due to the redundancy from the other lists, admins will still have plenty of options to check certs, and at least thus far it seems that there was nothing malicious done with the lifted keys. It should also be noted that no other part of DigiCert's business (such as the CA) was affected by this attack. ®