Attacks on GitHub developer in 2024

My name is Denis Makrushin, and together with the SourceCraft team, I create secure development technologies so that cybersecurity becomes a driver for innovation, and developers can effectively use their cognitive abilities. In this article, I have collected a collection of interesting vulnerabilities and attack methods on users of a large development platform, an overview of current attack methods identified in 2024. Understanding current threats helps to better understand the need to improve security practices in such a platform using GitHub as an example. The material will be useful for both developers and information security specialists to protect their projects.

Searching for secrets in hidden git commits

We know how to search for secrets in source code. But there are interesting places left in git repositories that cannot be reached by standard methods. We are talking about hidden commits - information about changed files in the repository that was deleted and is not displayed in the project history.

When a developer makes changes (commit) to the repository, and then for some reason wants to undo these changes, they execute the commands:

git reset --hard HEAD^
git push origin -f

The first line undoes the last commit and all recent changes in the target repository files, and the second line applies all changes in this repository. That is, these commands delete the last changes made.

Here an important feature appears, which researchers noted: if the commit is not available in the change history, this does not mean that it cannot be restored. And then all commits that contained secrets and were subsequently deleted by the developer can be restored and valuable information extracted from them.

Researchers have published a tool for extracting hidden commits from a public GitHub repository and analyzing them. For GitLab repositories, this technique also works, and there is also a ready-made tool. Security champions and application security specialists are adopting this approach.

Spreading malware through GitHub comments

Researchers discovered a trojan that spreads under the guise of game cheats and steals information from the infected station. The malware itself is unlikely to be remarkable, but the method of its distribution is interesting. The source where the trojan loader is published is the official Microsoft GitHub repositories.

GitHub allows attackers to bypass blocking rules based on blacklists and whitelists.

How the trojan gets there:

1. The villain creates a comment on any commit or issue in the Microsoft repository.

2. An attachment with an arbitrary file is uploaded to the comment.

3. The file will be uploaded to the GitHub CDN and linked to the project with a unique link. Link format:

   https://www.github.com/{project_user}/{repo_name}/files/{file_id}/{file_name}

4. The comment may not be published, but the link becomes active.

The attacker can attach a malicious file to any repository. So far, the only way to protect your project from such use is to disable comments.

Access to data from remote and private GitHub repositories

When one branch of a repository allows valuable data to be obtained from another remote or private branch, we are dealing with a new attack vector: Cross Fork Object Reference (CFOR).

By analogy with Insecure Direct Object Reference vulnerabilities, the attacker uses commit hashes to directly access the data in these commits. Even if the commit is contained in a remote or private repository. The attacker only needs to know the commit hash. How?

GitHub allows the use of short SHA-1 hash values, which can simply be brute-forced. For example, instead of a long link:

github.com///commit/07f01e8337c1073d2c45bb12d688170fcd44c637

You can use a short link:

github.com///commit/07f01e

where 07f01e is a short hash. It can be brute-forced through the GitHub user interface. And after gaining access to the commits, the attacker begins searching for secrets.

GitHub is aware of this issue and does not plan to fix it because it is not a bug, but a feature.

GitHub stars can deceive developers

How do we usually assess the reputation of a GitHub repository? Most often based on the number of stars and activity in this repository. For some developers, the number of stars directly determines the level of trust in this repository.

In this regard, the number of fake stars on GitHub is growing: there are already more than 3.7 million of them. These stars create a false impression of the popularity of projects that actually hide malware or some kind of fraudulent content. Villains use them to deceive developers by disguising dangerous repositories as successful projects.

To protect yourself from this type of fraud, we analyze all activity in the project. For example, we study discussions in the repository and the reputation of the authors.

Pipeline Poisoning

We have already studied how an attacker can harm a developer and infect dependencies in the supply chain. But the CI/CD pipeline itself — the conductor of the development conveyor — should be considered further. At the same time, GitLab and GitHub regularly close vulnerabilities in their products, which indicates the attention of villains to key technologies in the infrastructure.

OWASP has long published a document CI/CD Top 10 Risks. A significant part of the recommendations for protection is given to the developer and repository owner: do not trust pull requests from external contributors, carefully prescribe rules for automatic merging of code branches, do not run builds of untrusted code updates next to builds of the main branch, and so on. However, the villain actively exploits vulnerabilities in the CI/CD platforms themselves to implant implants, so recommendations requiring the developer's attention are not enough.

Many are familiar with GitHub Actions — this is a service that allows you to automate the processes of building, testing, deploying your application, and many other routine actions. You can study a selection of current exploitation methods for GitHub Actions to understand a typical attack scenario on a CI environment (which was also noticed in the wild):

1. The attacker modifies the CI configuration file in the repository to which he has access and injects the command: "give me environment variables with valuable data" into this file.

2. Then he makes changes directly to the main branch of the repository or sends a pull request with changes from a branch or fork.

3. If the attacker is unable to make changes directly to the CI configuration file, he can inject malicious code into the files referenced by the CI config.

4. Next, the attacker sends a pull request that causes the CI platform to start the build process based on the malicious config.

5. Since the build process almost always accesses sensitive data and privileged accounts, the attacker ends up executing the "give me environment variables" command on the host where the build is running.

Researchers from the Open Source Security Foundation have gone even further and, using a collection of the most common attacks on GitHub Actions as an example, examined specific protection techniques for each issue.

In short and in the "attack: protection" format

1. Running untrusted code in a privileged workflow: splitting the process into two blocks (privileged and unprivileged).

2. Code injection through untrusted input, untrusted files, and environment files: collecting parameters for Actions strings, limiting GitHub token permissions to the minimum necessary.

3. Malicious Actions: limiting GitHub token permissions to the minimum necessary, trusting only official Actions from GitHub (others - checking for vulnerabilities and then patching, for example, using Dependabot).

4. Malicious commits: limiting GitHub token permissions to the minimum necessary, checking Actions hashes when updating Workflow.

5. Cache token theft to gain context of other workflows using caching: not caching valuable information, not running untrusted code in the context of the main branch.

Typos in GitHub Actions Trigger Malicious Actions

Typosquatting attacks in software development exploit the human factor. The villain expects the developer to make a typo in the component name and mistakenly include malicious code in their project. It turned out that this attack technique can also be used to connect malicious GitHub Actions.

A variety of routine tasks can be automated, and suitable automations can be found in the marketplace. But there is a problem: anyone can create an arbitrary Action and publish it under any name.

What if someone creates an organization trufllesecurity, then creates an Action trufllesecurity/trufflehog and places code in it that collects all secrets from CI/CD? When a developer instead of uses: trufflesecurity/trufflehog makes a typo and writes uses: trufllesecurity/trufflehog — a malicious action will be triggered in their pipeline.

While attackers are collecting bits and pieces from around the world, let's follow the recommendations to avoid getting caught in this tangle:

• double-check the names of all used GitHub Actions;

• explicitly specify specific versions of Actions;

• tell your fellow developers about the problem.

Phishing for GitHub Users

The platform is fighting spam bots that exploit its reputation and send users messages with malicious links.

The peculiarity of this phishing: the platform user receives an email from GitHub. Bots add malicious links in comments to existing issues of open projects. And then these comments land in the mail as a notification to the users of this project. Then everything goes according to the classic scenario: launching the malware, taking over the GitHub account, and publishing a similar comment with a link in the repositories that this account has bookmarked.

Red Team considers this feature as an additional implant delivery channel because, in combination with the technique of uploading malicious files to GitHub CDN, it allows confidently bypassing spam filters. And Blue Team is now more closely monitoring email notifications from GitHub.

Instead of conclusions

The villains do not stop inventing more and more cunning ways to harm: they poison pipelines, inflate stars, dig up hidden commits, and look for secrets there. But the most effective attack remains dependency infection. This technique allows infecting a bunch of projects at once, using each infected library as a new bridgehead for spreading threats.

To protect your projects, it is important to know all the methods. And sometimes even reproduce them in your processes. This means building reliable protection at all stages of development to keep the pipeline safe — whether on GitHub or any other platform.