GitHub Releases Final Report on Source Code Intrusions in the Supply Chain – Naked Security


In early April 2022, news broke that various users of Microsoft’s GitHub platform had experienced unauthorized access to their private source code.

GitHib has now updated its crash report to say that it is “sending expected final notifications to GitHub.com customers who had Heroku or Travis-CI OAuth app integrations allowed in their GitHub accounts.”

The good news is that GitHub itself hasn’t been hacked, so it’s not a general cause for concern for all GitHub users.

The bad news is that indirect intrusions of this type are difficult to predict.

GitHub, if you’ve never used it, is a cloud-based source control system best known for hosting the public repositories of many open source software projects.

Source code control systems not only ensure that the latest version of your software is available for download, but also keep a continuous history of all recent changes and why they were made (and, if necessary, why they were subsequently made). been rejected).

Source control systems usually also provide official release history lists, tools to support and maintain different release versions side-by-side, and online forums to report bugs and suggest changes.

You’ve probably heard the jargon term pull request, which refers to a change proposal for which a contributor provides a possible code update, along with a justification. To suggest it, of course, this is essentially a push request, aimed at injecting new code into the system; if approved by the project team, the code gets drawnor merged, into the codebase and becomes an official part of the project.

Source code control gives software projects a formal record of changes, which makes it much easier to find new bugs because each change can be reviewed and retested individually.

It also makes it easier for developers scattered around the world to cooperate without inadvertently trampling on each other’s suggested updates.

Examples of popular open-source projects hosted on GitHub include the OpenSSL cryptographic library, Microsoft PowerShell’s own scripting language, and privacy-focused alternative browser Brave.

But not all GitHub projects are public, open-source code repositories.

Many organizations use cloud-based tools like GitHub to host proprietary, closed projects that they don’t want made public.

Startups, for example, don’t want potential competitors to know they’re working on project X, or even experimenting in domain Y.

Established software vendors may have existing products that include algorithms and other intellectual property that they don’t want competitors to be able to easily clone.

What went wrong?

Early investigations revealed that the hacked organizations had two things in common: they used either Heroku or Travis CIexamples of so-called Continuous integration (IC).

Many software development teams these days have adopted what is often referred to as a agile or one devops approach.

Coders don’t just get together once in a while to combine their collective updates into a full test build.

Instead, they use an automated system that regularly and frequently retrieves all recent changes, then rebuilds and retests the system automatically, perhaps several times a day.

The idea is that the sooner each proposed change is tested, the sooner easily detectable flaws will be found.

This, in turn, means that newly introduced bugs can be investigated quickly, before other parts of the project get tangled up with this new code, so fewer changes need to be considered when trying to figure it out. which didn’t work.

Best of all, code changes that break the build process itself are immediately exposed, so the project rarely bogs down to the point that it can’t be rebuilt at all, let alone retested.

As you can imagine, automated CI systems don’t have an actual developer on hand to put in a password and enter a 2FA code every time they want to log into the source code control system to clone. the latest version of the project…

… so they must be supplied with a so-called authentication token that they can inject into their network traffic to prove their access rights.

These authentication tokens usually act as a sort of medium-term “sub-password” that allows automated software tools to perform a pre-determined set of actions, such as granting download access to all code, and allowing bug reports to be uploaded, but not allowing code changes to be approved.

In fact, even if you’re not a programmer, you’ll have used a system like this yourself if you’ve ever allowed a third-party toolkit to interact with your social media accounts.

If you’re a Hootsuite user, for example, you’ve probably used your own passwords and 2FA codes to generate access tokens to allow the Hootsuite system to search your social media accounts on your behalf.

You may have given the app, or a similar app, the right to peek into everything happening on your social media accounts, and even tweet or post. on Facebook on your behalf.

So, if a cybercriminal had access to stored secrets used by one of your pre-approved applications, or was able to plant malware on your computer or network to spy on your network traffic and detect authentication tokens in transit…

…these tokens could be used by attackers to interfere with your online account, or resold to other scammers for equally nefarious purposes.

According to GitHub, that’s what happened in this source code theft incident, where the attackers:

  • Acquired GitHub auth tokens uploaded to Heroku or Travis-CI for account X. (How this happened is undisclosed, likely because GitHub can’t be sure what happened elsewhere before the intrusions began.)
  • Listed all sub-accounts with accessible projects by tokens issued by X.
  • Choose interesting projects in these lists.
  • Interesting listed code repositories within these projects.
  • Cloned (i.e. stole) the codethereby causing a potentially damaging data breach.

In other words, even if the victims’ GitHub accounts weren’t directly compromised, these accounts were indirectly compromised due to the exposure of what might be called “sub-passwords” that victims had delegated to automated Heroku or Travis-CI tools.

It’s a bit like an intruder gaining access to your office building not by hacking into the system that generates ID cards and creating their own pass, but by stealing an active access card already issued to a authorized employee.

What to do?

Indirect data breaches like this are a form of supply chain intrusion, where you are not attacked directly, but rather through a part of your business process that you have outsourced to someone. other.

Here are some tips to protect yourself against this type of accident or to react quickly if you are caught off guard:

  • Regularly check all third-party access authentications you have performed, for all applications associated with all online services you use. You might have more than you think, including cloud services such as webmail, conferencing, web hosting, source code control, social media, DNS, content management and the CRM. Social media sites like Twitter and Facebook include dashboard pages where you can list any third-party apps you’ve approved. Don’t assume that just because you uninstalled an app with access to your account doesn’t mean its access rights were revoked at the same time.
  • Make sure you know how to revoke third-party authentication tokens for each service you use. OAuth, the authentication service involved in this incident, has guidance on how to revoke access. The social media dashboard pages mentioned in Tip 1, where you can list who has access, usually include a button that will instantly revoke that access.
  • Prepare for the worst. Know what to do if a cyberattack occurs and who to contact, especially if your local laws require you to disclose data breaches.

Remember that preparing for a cyberattack is not an admission that you expect to fail.

Indeed, a regular and targeted cybersecurity practice can help you improve your resilience by exposing gaps in your policies and procedures and revealing access permissions you intended to revoke but did not. never done.


If you don’t have the experience or time to manage ongoing threat response yourself, consider partnering with a service such as Sophos Managed Threat Response. We help you take care of the activities you struggle to keep up with because of all the other day-to-day demands that IT dumps on your plate.

Not enough time or staff? Learn more about Sophos Managed Threat Response:
Sophos MTR – Expert-led response
Search, detect and respond to threats 24/7


Previous Minneapolis City Council blocks chamber consultation giveaway to improve efficiency of Mayor Frey's office
Next Body of 93-year-old woman found in large garage freezer