So, what happened with GitHub, Heroku, and those raided private repos?
Who knew what when and what did they do?
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 an internal 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, and that some of its private repos were siphoned on April 9. 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 its user's 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:
GitHub reported that the threat actor was enumerating GitHub customer accounts using OAuth tokens issued to Heroku's OAuth integration dashboard hosted on GitHub.
The compromised tokens could provide the threat actor access to customer GitHub repos, but not customer Heroku accounts. With the access to customer OAuth tokens, the threat actor may have read and write access to customer GitHub repositories connected to Heroku.
Heroku advised those potentially affected by this intrusion 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 tech giant 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 should 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 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 dated 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 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, we're told, detected something was afoot on April 12 when a miscreant gained unauthorized access to npm's production infrastructure using a compromised Amazon Web Services (AWS) API key. An analysis found the attacker obtained the key by downloading a set of private npm-owned GitHub 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 the OAuth applications known to be affected were 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 to this list as the investigation continues.
Git for Windows issues update to fix running-someone-else's-code vulnREAD MORE
GitHub said it 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 explained. "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 has 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 repositories and accounts, 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. ®