33

The ‘platform engineering’ trend proposed by analyst agencies has become interesting not only for companies that are transforming their processes, teams, and tools according to new approaches but also for adversaries who use the capabilities of development platforms to launch attacks.

In this article, I’ve compiled a collection of interesting vulnerabilities and compromise methods against users of a major development platform and an overview of current attack methods identified in 2024. Understanding the current threats allows you to understand better the need to improve security practices. The material will be helpful for both developers and information security professionals in protecting their projects.

Finding secrets in hidden git commits

We know how to hunt for secrets in source code. But there are still some interesting places in Git repositories that you can’t get to using standard methods. We are talking about hidden commits — information about changed files in the repository that has been deleted and does not show up in the project history.

When a developer makes a change (commit) to the repository and then, for some reason, wants to revert the change, they run the commands:

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

The first line reverts the last commit and all recent changes to the files in the target repository, and the second line applies all changes to that repository. That is, these commands remove the most recent changes.

The researchers noticed an important feature: if a commit is not available in the change history, it does not mean that it cannot be restored. All commits that contained secrets and were then deleted by the developer can be recovered, and valuable information can be extracted from them.

Researchers have released a tool for extracting and analyzing hidden commits from a public GitHub repository. This technique also works for GitLab repositories, and a tool is available. Security champions and application security experts are using this approach in their work.

Malware spreads via comments

Researchers have discovered malware that spreads under the guise of game cheats and steals information from an infected station. The malware itself is unremarkable, but the way it spreads is interesting. The malware downloader’s source is an official repository.

Dev platform allows adversary to bypass blocking rules based on blacklists and whitelists. How the malware gets there:

1. The adversary creates a comment on any commit or issue in the Microsoft repository.
2. An attachment containing an arbitrary file is uploaded to the comment.
3. The file is uploaded to the 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.

A malicious actor can attach a malicious file to any repository. At the moment, the only way to protect your project from such use is to disable comments.

Accessing data from remote and private repositories

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

Similar to Insecure Direct Object Reference vulnerabilities, the adversary can use hashes of commits to directly access the data in them, even if the commit is in a remote or private repository. All the adversary has to do is find the hash of the commit. How?

The dev platform allows you to use short SHA-1 hashes, which are easy to brute-force. For example, instead of a long link:

github.com/<user>/<repo>/commit/07f01e8337c1073d2c45bb12d688170fcd44c637

You can use a short link:

github.com/<user>/<repo>/commit/07f01e

where 07f01e is the short hash. It can be grabbed from the interface. After gaining access to commits, the adversary starts looking for secrets.

Fake stars can fool a developer

How do we usually judge the reputation of a repository? Primarily by looking at the number of stars and activity in that repository. For some developers, the number of stars is a direct measure of a repository’s credibility.

In this regard, the number of fake stars on popular dev platforms is growing: more than 3.7 million already exist. These stars give a false impression of popularity to projects that are actually hiding malware or fraudulent content. Bad actors use them to deceive developers by disguising dangerous repositories as successful projects.

We analyze all project activity to protect ourselves from this type of fraud. For example, we study repository discussions and author reputations.

Poisoning the development pipeline

We’ve already examined how an adversary can harm a developer and infect dependencies in the supply chain. But the CI/CD pipeline itself—the conductor of the development pipeline—is worth a closer look.

For example, the largest vendors of dev platforms regularly patch vulnerabilities in their products, which suggests that the bad guys are paying attention to key infrastructure technologies.

OWASP published a CI/CD Top 10 Risks document long ago.

Much of the protection advice given to the developer and repository owner : don’t trust pull requests from third-party contributors, be more careful when writing rules for automatic merging of code branches, don’t run builds of untrusted codeupdates alongside builds of the main branch, and so on.

However, the bad guy is actively exploiting vulnerabilities in the CI/CD platforms to introduce implants, so recommendations requiring developer attention are insufficient.

Many people are familiar with GitHub Actions — it’s a service that allows you to automate the processes of building, testing, deploying your application, and many other routine activities.

You can explore a selection of actual GitHub Actions exploitation techniquesto understand a typical CI environment attack scenario (which has also been seen in the wild):

1. A malicious actor modifies a CI configuration file in a repository they have access to and injects a command into it: “Give me environment variables containing valuable data.”
2. The actor then commits the changes directly to the main repository branch or submits a pull request containing the changes from the branch or fork.
3. If the actor cannot make changes directly to the CI configuration file, they can inject malicious code into the files referenced by the CI configuration.
4. The actor then submits a pull request, which triggers the CI platform to run a build process based on the malicious configuration.
5. Since the build process almost always accesses sensitive data and privileged accounts, the actor executes a “give me environment variables” command on the host running the build.

Researchers at the Open Source Security Foundation took this a step further, using a collection of the most common attacks on Actions to look at specific techniques for defending against each problem.

In short, and in “attack: defense” format:

1. Running untrusted code in a privileged workflow: split the workflow into two blocks (privileged and non-privileged).
2. Code injection via untrusted input, untrusted files, and environment files: collect parameters for action strings and limit permissions on the platform token to the minimum required.
3. Malicious actions: limit platform token permissions to the minimum necessary and trust only official actions from the platform’s vendor (the rest should be checked for vulnerabilities and then patched, e.g., Dependabot).
4. Malicious commits: limit platform token permissions to the minimum necessary and check action hashes when updating workflow.
5. Stealing cache tokens to get context from other workflows that use caching: don’t cache valuable information or run untrusted code in the context of the main branch.

Typosquatting in GitHub Actions triggers malicious actions

Typosquatting attacks in software development exploit the human element. The bad guy expects developers to misspell a component name and accidentally insert malicious code into their project. It turns out that this attack technique can also be used to insert malicious Actions.

Many routine tasks can be automated, and suitable automations are available on the market. But there’s a problem: anyone can create any action and publish it under any name.

What if someone creates the trufllesecurity organization then creates an action trufllesecurity/trufflehog and puts code in it that collects all the secrets from CI/CD?

If the developer makes a typo and writesuses: trufllesecurity/trufflehoginstead of uses: trufllesecurity/trufflehog — a malicious action is launched in their pipeline.

While the attackers pick up the pieces, follow these tips to avoid getting caught up in this mess:

• double-check the names of all Actions being used;
• explicitly list specific versions of actions;
• tell your fellow developers about the problem.

Another technique to “phish” developers

The development platform is fighting spam bots that exploit its reputation by sending users messages with malicious links.

This phishing works because a platform user receives an email from the official dev platform’s vendor. The bots add malicious links to comments on existing issues in open-source projects, which are then included in the email as a notification to the project’s users.

Then, everything follows the classic pattern: the malware launches hijacks an account and posts a similar comment with a link in the repositories bookmarked by that account.

The Red Team sees this as an additional distribution channel for the implant. When combined with the technique of uploading malicious files to the CDN, it allows them to bypass spam filters confidently. The Blue Team is now keeping a closer eye on email notifications from vendors of the dev platform.

Recommendations for developers to protect against attacks via development platform

Hidden git commits and secret exposure:

1. Use git filter-repo to fully remove sensitive data from Git history.
2. Avoid storing secrets in code or commits using secret managers or environment variables.
3. Rotate and revoke any accidentally exposed secrets immediately.
4. Monitor repository changes using tools like Trufflehog or pre-commit hooks.

Malware spread via comments:

1. Disable or moderate comments on repositories.
2. Use automated tools to detect and remove suspicious links in pull requests or issues.
3. Educate team members to avoid downloading files from unverified comments.

Accessing data from remote and private repositories (CFOR):

1. Keep repositories and forks private, especially those with sensitive content.
2. Require pull requests for all changes and enforce branch protections.
3. Regularly rotate access keys and secrets.
4. Avoid storing sensitive information in commits.

Fake stars and deceptive repositories:

1. Analyze repository activity beyond star count, including commit history and contributor profiles.
2. Verify author reputation and avoid using suspicious repositories.
3. Scan dependencies with security tools like Grype or Trivy.

Poisoning the development pipeline (CI/CD Attacks)

1. Separate privileged and unprivileged workflows in CI/CD pipelines.
2. Use fine-grained access tokens with minimal permissions.
3. Require reviews for CI configuration changes and validate inputs in workflows.
4. Avoid storing sensitive data in CI cache layers or artifacts.
5. Pin actions to specific versions or SHA commits and verify their integrity.

Typosquatting in Actions:

1. Double-check the names of all actions/runners used in workflows.
2. Pin actions to specific versions or SHA commits to ensure correctness.
3. Educate developers about typosquatting risks and review workflows carefully.

Phishing:

1. Verify links in email notifications from dev platforms before clicking.
2. Use email security tools to filter and verify links in notifications.
3. Enable two-factor authentication (2FA) on your accounts.

Instead of a bottom-line

Bad guys never stop coming up with clever ways to wreak havoc: they poison pipelines, tamper with stars, dig up hidden commits, and hunt for secrets. However, the most effective breach point is still the dependency infection.

This technique allows you to infect a bunch of projects at once, using each infected library as a new springboard for spreading threats.

Knowing all the techniques and sometimes reproducing them in your processes is essential to protecting your projects. So, you need to build strong defenses at all stages of development to keep your pipeline safe on any platform.