GitHub Says Hackers Cloned Code-Signing Certificates in Breached Repository (arstechnica.com) 19
GitHub said unknown intruders gained unauthorized access to some of its code repositories and stole code-signing certificates for two of its desktop applications: Desktop and Atom. From a report: Code-signing certificates place a cryptographic stamp on code to verify it was developed by the listed organization, which in this case is GitHub. If decrypted, the certificates could allow an attacker to sign unofficial versions of the apps that had been maliciously tampered with and pass them off as legitimate updates from GitHub. Current versions of Desktop and Atom are unaffected by the credential theft.
"A set of encrypted code signing certificates were exfiltrated; however, the certificates were password-protected and we have no evidence of malicious use," the company wrote in an advisory. "As a preventative measure, we will revoke the exposed certificates used for the GitHub Desktop and Atom applications." The revocations, which will be effective on Thursday, will cause certain versions of the apps to stop working.
"A set of encrypted code signing certificates were exfiltrated; however, the certificates were password-protected and we have no evidence of malicious use," the company wrote in an advisory. "As a preventative measure, we will revoke the exposed certificates used for the GitHub Desktop and Atom applications." The revocations, which will be effective on Thursday, will cause certain versions of the apps to stop working.
whoops (Score:2)
"A set of encrypted code signing certificates were exfiltrated; however, the certificates were password-protected and we have no evidence of malicious use," the company wrote in an advisory. "As a preventative measure, we will revoke the exposed certificates used for the GitHub Desktop and Atom applications."
Too bad they didn't take the preventive measure of not keeping them on an accessible volume when not being used.
Re: whoops (Score:1)
Applications can duplicate certificates by cloning.
Re: (Score:2)
Indeed. Or on a non network connected computer that is only used to sign code but never gets any other outside input. I guess the people at GitHub are either incompetent or lack the money for that one laptop this would have needed. Or maybe they were using code-signing to simulate security and not as actual security measure...
Re: (Score:2)
"A set of encrypted code signing certificates were exfiltrated; however, the certificates were password-protected and we have no evidence of malicious use," the company wrote in an advisory. "As a preventative measure, we will revoke the exposed certificates used for the GitHub Desktop and Atom applications."
Too bad they didn't take the preventive measure of not keeping them on an accessible volume when not being used.
Yay, Microsoft.
Re: (Score:2)
If they're used for automated signing and in high volumes then you don't have that luxury. When Adobe was breached a while back they reported that they were signing thousands of binaries a week, there is no "not being used" there.
Even if you do take this measure, all the attackers need to do is trigger on them going online and steal them then, so all it does is add a minor extra step to the process.
Later, Microsoft... (Score:3)
Oops, we "lost the key" for newer versions of Atom, too. Guess you'll have to use VS Code now.
Re: (Score:2)
It is indeed sunset, but they haven't revoked the certs that let you run the final version.
Github seems confused (Score:2)
Re: (Score:2)
I don't sign with a certificate. I sign with the private key associated with the certificate. The certificate just says "entity X has these authorizations and here is X's public key". By using X's private key to correctly sign the code you prove that the code was signed by X. The private key should be air gapped away from the internet and only used when you want to create a signed version of the code. If you want to sign code during development to test your development cycle you use a test certificate signed by your own test CA. That way code signed with the test private key only passes authentication on your test systems.
An org the size of github with the financial backing of Microsoft....should be able to afford something like a ~$650 YubiHSM...
Re: (Score:2)
It amazes me that they don't. There are more expensive HSMs, but for code signing, which is relatively infrequent, a YubiHSM is good enough. Heck, you can even use a YubiKey [yubico.com], and with a Cloudflare account, a few YubiKeys can be obtained at no cost.
At the minimum, have the key on an offline PC, with backups that are burned to optical media, and are stashed away somewhere physically secure. The DNSSEC guys do this for their key signing stuff on a live video feed. All you need is 2-3 sites, senior people,
Re: (Score:2)
You need one more thing that GitHub is obviously lacking: Insight into how actual security works.
HSM? (Score:2)
Of all certificates, why are code signing certificates not kept on a HSM? This way, the key material is never able to be exfiltrated, and there is a log of whom told the HSM to sign what, at what time.
HSMs are something that go without saying if one wants any type of security. That, or a 100% offline CA with backups being burned to optical media, but a HSM ensures easy online interoperability without the risk of losing key material.
Yes, HSMs can be compromised, but it means that you go back in the logs an
Re: (Score:3)
I understand hindsight is 20/20. But you're absolutely right and it's not hard for ANY company to have figured this out a long time ago. An HSM USB dongle or PCIe card is cheap these days, I think $500 - $5K. Generally less than the cost of a dedicated system for signing. A company that is serious about releasing software should consider $2k-$10k budget at a minimum to do this right. More money lets you sign more stuff faster.
Lazy way is to keep the machine on a private network as part of your release autom
Re: (Score:2)
For the price we pay for GHE on the enterprise tier where you host your own appliances, they could do exactly what you (the parent poster) mentioned, perhaps add redundant HSMs for both speed and DR capabilities. What would be ideal are HSMs for all the pipelines. Dev's could be automated so if a pull request passes inspection, the artifact can be signed. Test would require some manual intervention. Production or anything out for public consumption would require one, perhaps two senior admins (two key s
x509 certificate attack (Score:2)
Re: x509 certificate attack (Score:1)
I think the weakness has been that X.5xx protocols were designed originally to work between trust authorized domains. Even trust authorized machines. While layer 5 and higher has evolved to not take full advantage of that.
Atom was already deprecated anyway (Score:2)
So everybody should be migrating to something better anyway.