In an attempt to get ahead of fallout from the exposure of its private SSH key in a public repository, the software development platform GitHub proactively rotated its host key last week.
“Out of an abundance of caution, we replaced our RSA SSH host key used to secure Git operations for GitHub.com,” GitHub CSO and SVP of Engineering Mike Hanley wrote in a blog post .
“We did this to protect our users from any chance of an adversary impersonating GitHub or eavesdropping on their Git operations over SSH,” Hanley said, noting that the key doesn’t provide access to the company’s infrastructure or to customer data.
“This change only impacts Git operations over SSH using RSA. Web traffic to GitHub.com and HTTPS Git operations are not affected,” he wrote.
Since only the GitHub.com RSA SSH key was replaced, ECDSA or Ed25519 do not need to take action.
“Fortunately, GitHub responded quickly to rotate the impacted machine identities once it noticed that the private SSH key was accidentally published in a public repository,” said Kevin Bocek, vice president of ecosystem and community at Venafi.
Mike Parkin, senior technical engineer at Vulcan Cyber praised GitHub’s response. “They’re also being very transparent about it. Considering how often major issues can be ignored or at least delayed, it’s refreshing to see this kind of reaction,” he said. “Hopefully, this was caught and corrected before any threat actor was able to make use of the exposure.”
GitHub discovered that the private key was “briefly exposed” in the repository. “We immediately acted to contain the exposure and began investigating to understand the root cause and impact,” Hanley wrote, explaining that GitHub replaced the host key late last week.
“We have now completed the key replacement, and users will see the change propagate over the next thirty minutes,” he said. “Some users may have noticed that the new key was briefly present beginning around 02:30 UTC during preparations for this change.”
Hanley reassured users that the “issue was not the result of a compromise of any GitHub systems or customer information,” but was instead “the result of what we believe to be an inadvertent publishing of private information.”
GitHub has “no reason to believe that the exposed key was abused,” Hanley wrote.
“Luckily, it doesn’t appear that they’ve been abused,” said Bocek. “But if an attacker had seized this opportunity, then it would have given them a very powerful weapon—potentially allowing them to spread across GitHub’s customer networks, eavesdropping on user’s connections and accessing GitHub’s infrastructure too, while appearing completely trustworthy.”
Still, GitHub should “take a closer look at how it manages its SSH keys as an exposure of this kind—no matter how brief—could have serious ramifications given the high level of privilege these machine identities are afforded,” said Bocek.
“These critical machine identities are incredibly powerful and are used everywhere, but they’re also poorly understood and managed, making them a prime target for attackers,” he said. “Unlike other machine identities, like TLS, SSH keys don’t expire. This means that a compromised identity could be abused for a long time–months or even years–without an organization knowing.”
Perhaps it is time to revise thinking on keys . “Often, we have focused on key-based security as an improvement in the overall security posture. While mathematically true, the longer a key exists, the more likely it is to be able to be used by others,” said John Bambenek, principal threat hunter at Netenrich.
“For instance, I have never seen one single customer that has not had several (if not many) service account keys that were in the possession of former employees,” said Bambenek. “Key rotation is critical, not just due to potential leakage events, but also insider threat-related events and really, it should be done automatically and on a routine basis in every organization.”
GitHub’s Hanley outlined a number of actions affected users could take in the aftermath of the key replacement.