Encryption & Key Management , Security Operations

GitHub Replaces Private RSA SSH Key After Public Exposure

'Abundance of Caution' Cited for Move; No System Compromise or Data Breach Detected
GitHub Replaces Private RSA SSH Key After Public Exposure

GitHub says it has replaced its private RSA SSH host key after discovering it was being inadvertently exposed online.

See Also: Preparing Your Incident Response Team for Cyber Resilience

Microsoft-owned GitHub is a widely used hosting service for software development and version control that uses the Git control system for developing and maintaining source code

On Friday, GitHub said that earlier this week, it discovered that the RSA SSH private key that it uses to secure Git operations for GitHub.com had been "briefly exposed in a public GitHub repository."

Attackers could have used that private key to impersonate GitHub or eavesdrop on users' Git operations via SSH.

The company said the exposed key was used only for Git operations and not for its website or internal systems. "This key does not grant access to GitHub's infrastructure or customer data," it said. "Web traffic to GitHub.com and HTTPS Git operations are not affected."

GitHub said it briefly debuted the new key Friday at 02:30 UTC as it was preparing to change over, then committed the change at about 05:00 UTC. Technically this is known as key rotation - retiring one cryptographic key and replacing it with a new one.

As a result, all GitHub users who connect to GitHub.com via SSH will need to update their SSH entries. GitHub has detailed automated and manual processes for doing so.

The company says users of its GitHub Actions continuous integration and continuous delivery platform, used to automate organizations' software build, test and deployment pipeline, will experience failed workflows if their actions are pinned to the SSH key that's been replaced. The company says it's still in the process of updating GitHub Actions to deal with the change and that users will have to update their workflows.

Users of GitHub's Elliptic Curve Digital Signature Algorithm and Ed25519 digital signature system are not impacted, it says, and need take no action.

Challenge: Encryption Infrastructure

GitHub says it has not seen any signs that the exposed key was used maliciously before being replaced.

"Please note that this issue was not the result of a compromise of any GitHub systems or customer information," GitHub said. "Instead, the exposure was the result of what we believe to be an inadvertent publishing of private information. We have no reason to believe that the exposed key was abused and took this action out of an abundance of caution."

GitHub's misstep is a reminder that encryption-based approaches to securing data and communications aren't foolproof.

"The biggest weakness when it comes to encryption is not the encryption algorithms but rather the overall infrastructure for managing encryption," Brian Honan, head of Dublin-based cybersecurity BH Consulting, told Information Security Media Group.

"In the majority of compromises relating to encryption, the root cause has invariably been down to incorrect implementation of the encryption platform or inadvertent human mistakes," he said. "It appears that GitHub fell victim to the latter and that their private key was exposed due to an error."

Repeat Problem

GitHub is not the first organization to have accidentally exposed sensitive information by including it in a public-facing GitHub repository.

A 2014 breach of mobile ride-sharing platform Uber, for example, traced to an employee who accidentally included one of the company's APIs in a publicly accessible GitHub repository. Uber later said in a "John Doe" lawsuit that the API had been inappropriately accessed - just one time - to steal personal identifiable information for 50,000 drivers.

GitHub's private RSA key fumble is a reminder for all organizations that use cryptographic keys to plan ahead in case their own keys get mishandled, said Honan, who founded Ireland's first computer emergency response team, IRISS-CERT.

"Companies deploying encryption should ensure that their implementation is in line with good practices, that all staff involved in managing the keys are properly trained and that there is a plan in place on how to manage an event such as the private key being published," he said.

Secret-Scanning Program

To help GitHub users spot when private keys and other credentials get inadvertently exposed in public-facing repos, GitHub runs a secret scanning partner program, which it says scans repositories for more than 200 different types of credential tokens.

"In 2022, we notified our partners of over 1.7 million potential secrets exposed in public repositories to prevent the misuse of those tokens," GitHub's Mariam Sulakian and Zain Malik wrote in a Dec. 15, 2022, blog post, announcing that the formerly premium feature was being rolled out, for free, for all GitHub repositories, whether paid or free.

GitHub says the feature is available via "code security and analysis" settings, in the security subsection's "vulnerability alerts" listing.

"There, you will see a list of any detected secrets, and you can click on any alert to reveal the compromised secret, its location and suggested action for remediation," Sulakian and Malik said.


About the Author

Mathew J. Schwartz

Mathew J. Schwartz

Executive Editor, DataBreachToday & Europe, ISMG

Schwartz is an award-winning journalist with two decades of experience in magazines, newspapers and electronic media. He has covered the information security and privacy sector throughout his career. Before joining Information Security Media Group in 2014, where he now serves as the executive editor, DataBreachToday and for European news coverage, Schwartz was the information security beat reporter for InformationWeek and a frequent contributor to DarkReading, among other publications. He lives in Scotland.




Around the Network

Our website uses cookies. Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing govinfosecurity.com, you agree to our use of cookies.