Analysis GitHub says it has identified and alerted developers who have had their private repositories accessed and downloaded via stolen authentication tokens.
In this multifaceted fiasco, Microsoft-owned GitHub insisted its security was not breached. Instead, we’re told, “compromised OAuth user tokens from Heroku and Travis-CI-maintained OAuth applications were stolen and abused to download private repositories belonging to dozens of victim organizations that were using these apps.”
Salesforce-owned Heroku confirmed someone compromised an OAuth token – presumably a staffer’s token – to get into Heroku’s GitHub account and rifle through, and potentially update, users’ GitHub repositories “using OAuth tokens issued to Heroku’s OAuth integration dashboard hosted on GitHub.”
Travis CI said while it was caught up in the kerfuffle to a degree, no customer data or source code repositories were accessed via it. If that’s right, the large-scale private repo raiding was carried out via tokens issued to Heroku, obtained by someone who got into Heroku’s GitHub account.
Curiously, GitHub said it began an investigation into the authentication token misuse on Tuesday, April 12, and disclosed initial details of its probe late Friday, April 15 amid a long Easter weekend in some parts of the world. Heroku said it was told about the problem on April 13 by GitHub, that some of its private repos were siphoned on April 9, and it went public also on April 15.
Here’s what each partner in this saga had to say.
According to Heroku on April 15, “a subset of Heroku’s GitHub private repositories, including some source code, were downloaded by a threat actor on April 9, 2022.” That led to the biz pulling the plug on access to prevent any further damage: “It appears that unauthorized access to Heroku’s GitHub account was the result of a compromised OAuth token. Salesforce immediately disabled the compromised user’s OAuth tokens and disabled the compromised user’s GitHub account.”
That wasn’t the end of it, though, as the miscreant crawled through GitHub customer accounts and private source-code repositories using authentication tokens issued to Heroku:
Heroku advised those potentially affected by this to obtain their organization or personal security logs from GitHub, look for evidence of exfiltration, and email security at salesforce dot-com with any findings to help the biz probe the break-ins.
The Salesforce subsidiary, for good measure, revoked all access tokens from its GitHub integration, which it completed by April 16. That integration is, as far as we can tell, on ice for the time being while Heroku continues to investigate. That means, while applications relying on the tie-up will continue to work, various operations, such as deploying apps, are non-operative.
At 0100 UTC on Wednesday, April 20, Heroku said it was continuing “to make progress on our investigation,” and will update its status page when the integration functionality is restored or anything else comes up.
While GitHub said “compromised OAuth user tokens from … Travis-CI-maintained OAuth applications were stolen and abused to download private repositories,” Travis CI insisted it wasn’t to blame for any data theft or meddling.
“The hacker breached a Heroku service and accessed a private application OAuth key used to integrate the Heroku and Travis CI application,” it said in a statement on Monday, April 18. “This key does not provide access to any Travis CI customer repositories or any Travis CI customer data.
“We thoroughly investigated this issue and found no evidence of intrusion into a private customer repository (i.e. source code) as the OAuth key stolen in the Heroku attack does not provide that type of access. Based on what we have found, we do not believe this is an issue or risk to our customers.”
That said, Travis CI, out of caution, reissued all private customer authentication keys and tokens for integrating Travis CI with GitHub.
Hanley added that it doesn’t appear the authentication tokens were stolen through a compromise of GitHub “because the tokens in question are not stored by GitHub in their original, usable formats.”
GitHub Security said it detected something was afoot on April 12 when an unknown miscreant gained unauthorized access to npm’s production infrastructure using a compromised Amazon Web Services (AWS) API key. An analysis found that the attacker obtained the key when downloading a set of private npm repositories using a stolen OAuth token.
“Upon discovering the broader theft of third-party OAuth tokens not stored by GitHub or npm on the evening of April 13, we immediately took action to protect GitHub and npm by revoking tokens associated with GitHub and npm’s internal use of these compromised applications,” Hanley explained.
He said that the OAuth applications know to be affected are Heroku Dashboard (ID: 145909), Heroku Dashboard (ID: 628778), Heroku Dashboard – Preview (ID: 313468), Heroku Dashboard – Classic (ID: 363831) and Travis CI (ID: 9216). More could be added as the investigation continues.
Git for Windows issues update to fix running-someone-else’s-code vuln
GitHub notified Heroku and Travis CI about the situation between April 13 and 14, and recommended they start their own investigations, revoke OAuth user tokens associated with the affected applications, and notify netizens. GitHub is working with both in those investigations.
The impacts to npm are unauthorized access to – and the downloading of – private repositories of npm and possibly access to the npm packages in AWS S3 storage, according to Hanley. The attacker apparently didn’t modify packages nor get access to user account data or credentials.
“npm uses completely separate infrastructure from GitHub.com,” he wrote. “GitHub was not affected in this original attack. Though [the] investigation continues, we have found no evidence that other GitHub-owned private repos were cloned by the attacker using stolen third-party OAuth tokens.”
Hanley added the bad actor’s behavior suggests they “may be mining the downloaded private repository contents, to which the stolen OAuth token had access, for secrets that could be used to pivot into other infrastructure.”
GitHub is identifying and contacting affected users and organizations, which have received emailed notices with more details and next steps. The company also recommended the users review the OAuth applications authorized to access their organization and get rid of any that are no longer needed.
They also should review audit logs and user account security logs for unexpected or anomalous activity, Hanley wrote.
In an update on Monday, April 18, the CSO added: “Should we identify additional customers who have been affected, we will notify those customers promptly. If you do not receive a notification email from us, that means GitHub has not identified your account as impacted by the current incident.”
The discovery of the OAuth issue came as GitHub is taking proactive steps to improve security. The Microsoft subsidiary earlier this month upgraded its GitHub Advanced Security offering with functionality aimed at preventing the leak of secrets that could threaten organization-owned projects. The new feature offers users an option to scan for secrets before a “git push” is accepted.
“GitHub secret scanning’s new push protection capability embeds secret scanning in the developer workflow,” according to a GitHub announcement. “To make this possible without disrupting development productivity, push protection only supports token types that can be detected accurately.”
Last week GitHub improved its Dependabot tool used to find open-source package dependencies in software projects, giving it the capability to let developers know the relevancy of its security alerts. ®