Red Teaming GitHub: Part 1 Attack Surface

Source code repositories have become the foundation to many organisations as they develop, collaborate and store code used for business critical applications, proprietary algorithms, research ideas and open source development projects. As the use of git has grown so has the capability of source code repositories with GitHub and GitLab providing CI functionality, project management and AI capabilities. There are so many different methods for accessing and working with these source code repositories that it creates opportunities for adversaries to leverage and perform malicious actions. This is the first in a series of posts where I’ll be deep diving into GitHub and the supporting ecosystem with the aim of giving a Red Team view of how these features can be abused.

These posts assume that you have used GitHub before, know what is and how you use it to develop and manage code. If you want to know the basics, I recommend setting up your own repository and playing with it.

High Level View

When considering how to abuse any system there is always the temptation to dig straight into a specific feature, learning about how it works and testing it out. Before I do this, I normally review the attack surface of a system. The following mindmap provides three perspectives, the first is what is remotely accessible, specifically the public or private facing GitHub service. The second is the GitHub organisation which you could consider adjacent systems like email servers or cloud accounts. The final perspective is the local clients which leverage GitHub applications and tools.

GitHub has several different options for accessing the service. Developers use git commands for pushing or pulling code but this is normally via HTTPS but can also be via SSH. The web interface is primarily used for repository configuration and management but there is also Codespaces which is a development environment hosted in the Cloud (essentially a docker container running on a virtual linux host). Lastly the GitHub API provides programmatic access for systems or tools which require it. There are quite a few resources available for abusing GitHub and I’ve collated a list of sites I’ve found useful when performing a security review.

• https://cloud.hacktricks.xyz/pentesting-ci-cd/github-security
• https://github.com/step-security/github-actions-goat
• https://gist.github.com/nil0x42/1f85510883cad48dd0c2d56bbb98edbc
• https://github.com/CycodeLabs/raven
• https://github.com/praetorian-inc/gato

From an organisation perspective, as GitHub is owned by Microsoft you would think it is safe to assume that the business would be hosted on Azure but actually it is primarily using AWS with newer services introduced since the acquisition being run on Azure. Alongside the Cloud based resources, GitHub will have premises with physical assets such as servers, user end devices and networking infrastructure. Whilst this could be an interesting topic to cover, it is not likely this would be in-scope (unless you work for GitHub themself) for Red Team engagement but I thought I would cover it at a high level for completeness.

Upon researching the attack surface of GitHub, I thought I had a good idea of the applications and tools that are available to a developer to access or interact with the service but I was surprised to see a dedicated desktop application and unofficial browser extensions. One client I’ve seen but I’m unaware of how heavily it’s used, is the mobile app. I use it for notifications and viewing repositories but it does support editing files and merging pull requests. The remaining tools form the foundation of the developer user experience, the browser, GitHub CLI and IDE.

Remote Services

As previously discussed, GitHub has evolved to the point of offering several features beyond that of just a source code repository. These are broken down by GitHub in following areas;

Collaborative Coding

• Public Repositories
• Codespaces
• GitHub Copilot
• Protected Branches
• Pull Requests
• Gists

Automation & CI/CD

• Actions
• Packages
• GitHub Pages
• Secrets Management
• GitHub Marketplace
• Webhooks

Security

• Private Repositories
• Two factor Authentication
• Dependabot
• Secret Scanning
• Code Scanning
• GPG commit signing verification
• Audit Log
• Repository Rules

Client Apps

• GitHub Mobile
• GitHub CLI
• GitHub Desktop

Project Management

• Projects
• Issues
• Wikis

Team Administration

• Organizations
• Teams

Threats

This is a sizable attack surface. As a Red Teamer we can draw inspiration from threat actors and previous adversary campaigns. Over the past three years, GitHub has become a bigger target for adversaries who are looking for more ways to access production environments. Below is a list of threats with examples I’ve found whilst researching the area.

Repojacking - An adversary takes ownership of a repository to distribute malware by replacing a legitimate package with a malicious one. GitHub has recently published advice on how to protect yourself from this attack.

Repository Confusion Attacks – An adversary clones a popular repository with the intent of hosting a malicious version of the software, often with a similar name in the hopes of confusing a developer to downloading it.

Hosting Malicious Code - An adversary leverages the SaaS platform to host malicious code. This includes hosting Command and Control (C2) tooling or taking advantage of GitHub being allow-listed on an enterprise proxy to reach malicious code. I’ve seen examples of C2 leveraging Gists, Pages and more recently Issues.

Execute Malicious Code - An adversary leverages GitHub actions to execute malicious code. There are previous attempts to trick developers to deploy Cryptominers on GitHub Actions but given CI/CD allows remote code execution many attack vectors are feasible. An adversary may want to insert a backdoor into software, dump environmental variables or potentially perform a multi-repo coordinated Distributed Denial of Service (DDoS) attack (I’ve not found any examples of this occurring and I would expect GitHub to prevent this).

Steal Sensitive Data - A classic example is stealing sensitive data from the repository which is often focussed on credentials and secrets but can also include proprietary code or the versions of packages and libraries running in production. Interestingly, GitHub provides several services to prevent this occurring but remember that an adversary can use those services against the owners to discover secrets and vulnerabilities.

Destroy Repository Code - A threat that is not covered too often is completely destroying the code in the repository. The primary reason for this is there is a high probability that a developer has a copy of the code base on their local device (e.g. a typical development flow is clone and branch a repository for a new feature). Although potentially ineffective it is important (like any other data) that regular backups are performed to reduce the impact of destruction.

Ransomware Attack - There have been cases of ransomware attacks on GitHub repositories, where an adversary will replace the entire repository with a single file and remove the entire git history. Once again this may not be too successful if a developer has a local copy of the repository, which in my experience is highly likely.

Fundamentals

These threats are excellent examples to draw upon for Red Team exercises but it’s worth covering a few fundamentals. GitHub configuration is split between the organisation which owns the instance and the repositories which reside within it. In either case of an organisation or a repository the goal should be to obtain a user with owner or admin permissions respectively. Obtaining repository admin will allow you to manage user access, modify GitHub Actions and manage branch protection rules but it could be limited depending on the policies applied at the organisation level.

If it is not possible to obtain a privileged account, then it is more than likely you are restricted to a developer workflow. This is the point where code obfuscation becomes important and hoping for insecure repository configuration. For example, if Dismiss stale pull request approvals when new commits are pushed is not configured on the branch you are pushing to, you could commit benign code to the repository and have it approved but not merged. At this point, with the approval in place, you can push additional commits that bypass review and can be merged into the branch (which potentially triggers the deployment process into production).

Local Services

The remote services are usually the focus of Red Team operations but as we’ve seen authentication and authorisation play a critical role to the protection of GitHub. Client software is not a subject I’ve seen discussed a lot for Red Teaming which surprises me as the local environment is normally the initial foothold for adversaries. In fact, I wasn’t able to see any public examples of an adversary using an existing client session to abuse a GitHub service.

Rather than breaking down threats for each local client and how they can be abused, I thought I would explore them in more detail in the next series of posts. Part 2 will focus on the GitHub CLI, whilst Part 3 will look at the IDE, specifically VSCode. Why these in particular? Simply put, they both allow third party extensions!

Thank you

I’ve cited numerous examples of prior work and research performed by organisations and the security community on GitHub. To those who have done this work, thank you. I hope the links I’ve provided back to your original posts is sufficient attribution for all the hard work you have done.