GitHub.com Rotates Its Exposed Private SSH Key (bleepingcomputer.com) 20
GitHub has rotated its private SSH key for GitHub.com after the secret was was accidentally published in a public GitHub repository. BleepingComputer reports: The software development and version control service says, the private RSA key was only "briefly" exposed, but that it took action out of "an abundance of caution." In a succinct blog post published today, GitHub acknowledged discovering this week that the RSA SSH private key for GitHub.com had been ephemerally exposed in a public GitHub repository.
"We immediately acted to contain the exposure and began investigating to understand the root cause and impact," writes Mike Hanley, GitHub's Chief Security Officer and SVP of Engineering. "We have now completed the key replacement, and users will see the change propagate over the next thirty minutes. Some users may have noticed that the new key was briefly present beginning around 02:30 UTC during preparations for this change." As some may notice, only GitHub.com's RSA SSH key has been impacted and replaced. No change is required for ECDSA or Ed25519 users.
"We immediately acted to contain the exposure and began investigating to understand the root cause and impact," writes Mike Hanley, GitHub's Chief Security Officer and SVP of Engineering. "We have now completed the key replacement, and users will see the change propagate over the next thirty minutes. Some users may have noticed that the new key was briefly present beginning around 02:30 UTC during preparations for this change." As some may notice, only GitHub.com's RSA SSH key has been impacted and replaced. No change is required for ECDSA or Ed25519 users.
Crytography (Score:2)
Does this mean that any previously sniffed packets can be decrypted now, or do the encryption protocols not work that way?
Re: (Score:2)
Couldn't one set up a fake github that delivers trojaned source when cloned from using ssh? The https clone uses a different authentication system (TLS) so it should be ok, but I don't think the ssh clone will look at the x509 cert.
Of course one would still need to dns hijack or something to get anyone to use the fake site. And the git hashes would be wrong, but most people don't clone a github repo and then check that they have cloned the right sha1 via some side-channel.
Re: (Score:2)
Most SSH clients cache the key after the first connection, so they will only flag an error if it changes.
When accepting a new key for the first time, very few users will actually use another method to verify the key (they should, but they don't).
The changed key *may* break some automated scripts.
Most modern SSH clients will default to ED25519 keys, which have not changed so it's likely most users won't notice any problem unless they're using a very old client.
Re: Crytography (Score:2)
In a circle no less I'm sure
Re: (Score:2)
Re: (Score:3)
SSH has perfect forward secrecy, because the protocol is well-designed. This means a future break of the long-term secrets does in no way compromise past communication.
Always with the lying... (Score:5, Insightful)
1. It does not matter how long the key was exposed. Exposed is exposed.
2. Changing it is not "abundance of caution", it is minimal (!) due caution.
3. Where is the explanation of how this was possible in the first place? And how are they making sure it does not happen again?
Re: (Score:2)
Points 1 and 2 are right on. Point 3 is not a mystery at all:
Where is the explanation of how this was possible in the first place? And how are they making sure it does not happen again?
I'd bet it would be hard to find ANY major project that doesn't have a private key lying around somewhere in a source code repository. Very few programmers understand just how dangerous this is, they get sloppy and leave it lying around in the folder with their source code, and eventually it gets checked in.
My company has gone through two rounds of sweeps for keys and passwords lying around in code. It's not easy to get rid of them, they keep popp
Re: (Score:3)
My company has gone through two rounds of sweeps for keys and passwords lying around in code. It's not easy to get rid of them, they keep popping up like whackamole!
I wonder if git should be updated to refuse to commit files that are obviously private keys? (Or at least, to require a blood oath and signing over of one's firstborn before agreeing to do so)
Re: (Score:2)
You cannot reliably identify private keys. One problem is that they often look exactly the same as public keys.
Re: (Score:2)
So abysmal incompetence? Makes sense to me.
Re: (Score:2)
Maybe.
I had a retired teacher friend who made this statement: "When one student fails a test, it's the student's fault. When everyone in the class fails the test, it's the teacher's fault."
Basically every programming shop fails this test. I'm not sure it's fair to blame developers.
Re: (Score:1)
Re. 2, of course they know that but it's free reduced-damage to their reputation in the eyes of those which believe this at the cost of increased damage to their reputation in the eyes of those who see the attempt to spin bad into good.
The monkeys really are running the zoo (Score:2)
Rotate a key? (Score:1)
Re: (Score:2)
https://csrc.nist.gov/glossary... [nist.gov]