GitHub website page close up showing OAuth tokens used to breach private repositories

GitHub: Stolen OAuth Tokens Used to Breach Private Repositories, Dozens of Organizations Impacted

OAuth tokens that were issued to two third-party integrators, Heroku and Travis-CI, were stolen by an unknown attacker and used to access “dozens” of private repositories according to GitHub.

GitHub says that the OAuth tokens were not stolen via a breach of its own systems, as it does not store them in a format that would be usable to attackers. There is presently no indication as to who did it or how they did it, but thefts of OAuth tokens generally happen client-side and they are often traded on underground forums.

As Ray Kelly, Fellow at NTT Application Security, explains: “OAuth tokens are a common method for automating cloud services such as code repositories and DevOps pipelines. These tokens are considered secrets for a good reason and are often times “masked” with stars or not shown at all to help protect connected business services.   If a token is compromised, in this case a GitHub token, a malicious actor can steal corporate IP or modify source code to initiate a supply chain attack that could spread malware or steal PII from unsuspecting customers.”

OAuth tokens grant attackers access to sensitive information

The two OAuth integrators that lost hold of tokens, Heroku and Travis-CI, do not have firm public customer numbers available but are estimated to collectively have hundreds of thousands of users. GitHub did not name the victims, but said that the count was in the dozens and that it was directly contacting those that were thought to be impacted.

One organization that it did confirm was impacted was npm, which GitHub acquired in 2020. npm maintains a public Java registry, estimated to have at least hundreds of millions of users of its 1 million+ software packages. GitHub says that it found no evidence that npm packages were altered during the intrusion, nor that customer account credentials were accessed. However, it did say that an investigation into whether the attacker viewed or downloaded private packages continues though there is not yet any evidence that private repositories were cloned with the OAuth tokens.

GitHub’s public alert indicates that the attackers used the stolen OAuth tokens to trawl through the private repositories of victims and steal information. GitHub suggested that the attackers had a focus on exfiltrating information that could be used to gain entry to other infrastructure.

The breach window appears to have begun on April 12. The initial contact was a breach of the npm production infrastructure via a compromised AWS API key, which in turn was traced to the use of one of the stolen OAuth tokens. Further theft of OAuth tokens was verified on April 13. GitHub says that it continues to work with Heroku and Travis-CI to understand the full scope of the attack and total exposure experienced by private repositories.

GitHub concluded the alert by saying that organizations that had not been contacted by email by April 19 were likely not impacted by the breach.

Prakash Linga, Co-Founder and CEO at BluBracket, expanded on the potential scope of the attack on private repositories and what potentially impacted organizations might expect from it: “Attackers are actively trying to find other secrets in private repos to help gain access to other critical resources. In fact, they did find and leverage an active AWS key in npm’s private repo. Exposure here is not limited to GitHub and may extend to every app integrated with Heroku/Travis. Looks like the attack may be limited to companies leveraging Heroku/Travis cloud products … This is one more in a series of threats exploiting the software supply chain. In this case, it’s the internal software supply chain that is compromised. One more example of leveraging source code as an attack surface to gain access to other critical enterprise resources.”

Extent of access to private repositories still not fully known

The present list of applications impacted by the stolen OAuth tokens includes:

  • Heroku Dashboard (ID: 145909)
  • Heroku Dashboard (ID: 628778)
  • Heroku Dashboard – Preview (ID: 313468)
  • Heroku Dashboard – Classic (ID: 363831)
  • Travis CI (ID: 9216)

GitHub has revoked the OAuth tokens that were used in the attack, so it is possible that attacker access has been entirely removed at this point, but organizations that potentially had private repositories breached should stay in contact with the company for better information about the extent of possible damage.

First developed in the mid-2000s, OAuth is likely familiar to the casual internet user as the basic model behind the ability to log into non-Google and non-Facebook sites by using their Google or Facebook credentials. OAuth tokens provide a centrally stored authorization mechanism that can cross multiple sites. But as studies have pointed out, the system has potentially big vulnerabilities if a developer does not implement it entirely correctly. This is why the theft of OAuth tokens generally happens at the client application end, though at this point it remains unclear exactly how the GitHub tokens were acquired.

Once stolen, these tokens are not always used immediately to raid private repositories or other sources of data; there is a brisk trade for them in the criminal underground. Casey Ellis, Founder and CTO at Bugcrowd, elaborates on the specialized brokers that can be found dealing in these goods: “When OAuth keys like the ones used in this attack can’t be stolen from a database or poorly-permissioned repository they are often gleaned from the client-side using malware or browser-based attacks, then collected and aggregated by Initial Access Brokers, and on-sold to those who need to use them for a specific attack. I suspect that is what has happened here, and the important lesson is that this type of layered-threat is a present and active risk for anything.”

The theft of OAuth tokens falls under the general heading of API vulnerabilities, but major events have actually tended to be relatively rare despite the need for developers to implement nearly all of their own security. But when they do happen, they tend to be major incidents and can take substantial time to fix. One of the more recent and big incidents involving access tokens happened at Facebook in 2018, when an estimated 50 to 90 million accounts were exposed due to a bug in the “View As” feature that allowed users to view their own profile from the perspective of another account. The feature ended up being disabled until mid-2019 as Facebook fixed the issue and conducted a security review.