• In July 2023, we detected suspicious commits in hundreds of GitHub repositories, appearing as if contributed by Dependabot but carrying malicious code.
• These commit messages were fabricated by threat actors to disguise their malicious activity.
• Upon investigation, we confirmed that the attackers stole victims’ GitHub personal access tokens to make these malicious contributions.
• The malicious code exfiltrates secrets to a C2 server and injects web-form password-stealing malware into JavaScript files, affecting end-users.
• Private GitHub organization repositories were also impacted due to compromised tokens.
• The method of token theft remains unclear, possibly linked to a malicious open-source package.
• This blog will provide details on the malicious payload and highlight the current challenge of detecting such token-based attacks on GitHub.

About Dependabot

Dependabot is GitHub’s free automated dependency management tool for software projects. It continuously monitors a project’s dependencies (like libraries and packages) for security vulnerabilities and outdated versions. When it detects issues, it automatically generates pull requests with updates, helping developers keep their software secure and up to date.

The Fake Dependabot Commits

Between July 8–11, a threat actor started compromising hundreds of GitHub repositories, both public and private. Most victims are Indonesian user accounts. The attackers used a technique to fake commit messages (read more about how it’s done here) to trick developers into thinking this was contributed by the real dependabot and to ignore this activity.

The attackers created a commit message “fix” which appears to be contributed by the official user account dependabot[bot]

Malicious Code

In the various repositories we analyzed (the full list remains internal but it was hundreds of repositories) we saw two groups of repeated code changes, most likely done with an automated script.

A New GitHub Action to Steal Secrets

A new GitHub Action file named “hook.yml” was added as a new workflow file, triggers a code push event. It sends GitHub secrets and variables to URL hxxps://send[.]wagateway.pro/webhook. This action is triggered on every push event.

Patching *.js Files to Steal Passwords

In addition to the added GitHub Action, the attackers modified every existing project file having the “*.js“ extension and appended an obfuscated line at the end of the file.

This new line is designed to create a new script tag as the code is executed on a browser environment and loads an additional script from this URL: hxxps://send[.]wagateway.pro/client.js?cache=ignore.

The code loaded from hxxps://send[.]wagateway.pro/client.js?cache=ignore is attempting to intercept any web-based password form and send the user-credentials to the same exfiltration endpoint as before; URL hxxps://send[.]wagateway.pro/webhook

How Was It Done?

At first, it was unclear to us how the attackers got access to those accounts, especially earlier this year when GitHub raised the bar for mandatory 2FA.

To get a better understanding of how this happened, we approached some of the victims by sending an email notifying them of the breach and asking for help understanding the full picture.

Luckily, some victims agreed to share information with us, and surprisingly when inspecting the accounts activity we realized that the attackers accessed the accounts using compromised PATs (Personal Access Token) — most likely exfiltrated silently from the victim’s development environment.

Step 1 — Workspace Initialization

The victim must set up their development environment with a personal access token (or SSH/GPG key) identifying their account whenever they make git operations. This token is stored locally on the developer’s machine and can be extracted easily.

Such access tokens do not require 2FA and can be used to access the account by any computer with internet access.

Step 2 — Stealing the Developer’s Credentials

We can only guess how the attackers got the developers credentials but seeing many cases of malicious packages aiming to perform that task suggest that it is one potential way that the attackers could have gotten their hands on those precious GitHub tokens.

We believe the most likely scenario is that the victims were infected with such a malicious package, which exfiltrated the token to the attacker’s C2 server.

Step 3 — Poisoning the Victim’s Code Projects

In this step the attackers used the stolen victim’s personal access tokens to authenticate to GitHub and make the malicious code changes described above.

Analysis of the scale of the attack reveals that it appears to be automated.

Conclusion

This whole situation teaches us to be careful about where we get our code, even from trusted places like GitHub. It shows that even big platforms can have problems, so we need to always watch out and protect ourselves online.

This is the first incident we witnessed a threat actor using fake git commits to disguise activity, knowing that many developers do not check the actual changes of dependabot when they see it.

To make things safer, consider switching to GitHub’s fine-grained personal access tokens . These tokens allow you to reduce the risk of compromised tokens. So, if someone bad gets one of these keys, they can’t do a lot of damage.

Sadly, the GitHub personal access token’s access log activity is only visible for enterprise accounts. If your token got compromised, you can’t know for sure because this information is not visible for non-enterprise users in the audit log section.

The attacker’s Tactics, Techniques, and Procedures (TTPs) involve the use of fake commits, stealing user credentials, and impersonating Dependabot to avoid detection show us supply chain attacks are getting more sophisticated as attackers realize it doesn’t take much to move silently

IOCs:

wagateway[.]pro
hxxps://send[.]wagateway[.]pro/webhook
hxxps://send[.]wagateway[.]pro/client.js

Timeline

• During 2023 - The threat actors attacked multiple victims and harvested personal access tokens (we don’t know how it was done and guessing malicious packages were involved)
• 2023–07–08 - The attackers used the stolen GitHub tokens in an automated attack, poisoning multiple repositories.
• 2023–07–24 - We first noticed this anomaly and began investigating.
• 2023–07–24 - Contacted the GitHub accounts infected by this attack + reported to GitHub.
• 2023–09–20 - We met with one of the victims, and reviewed his access logs which helped us understand the attack flow.

Surprise: When Dependabot Contributes Malicious Code was originally published in Checkmarx Zero on Medium, where people are continuing the conversation by highlighting and responding to this story.

CocoaPods is THE dependency manager for iOS and Mac projects. It helps software developers easily add pre-made pieces of code (called “libraries” or “dependencies”) to their iOS or Mac projects.

These libraries of code can help developers add extra features or functionality to their apps without having to write all of the code themselves. Think of it like adding pre-made Lego pieces to a Lego creation to make it better or more interesting.

Subdomain Hijacking

Subdomain hijacking is a type of cyber-attack where an attacker takes control of a subdomain of a legitimate domain and uses it to host their malicious content or to launch further attacks.

In a subdomain hijacking attack, the attacker can find forgotten settings on free hosting websites such as GitHub Pages which are not mapped anymore and the weak validation grant attackers permission to use those subdomains.

CocoaPods Casino

Guy Nachshon, a brilliant security researcher in my team, found out the subdomain cdn2.cocoapods.org was used years ago and abandoned, but the DNS records still point to GitHub Pages hosting service, and attackers hijacked it to host a fishy casino website.

While we are investigating this, the subdomain got freed on GitHub Pages (probably due to an update/mistake of the attackers)

We jumped on the opportunity and created a simple repository to hold this subdomain and prevent another takeover by those casino attackers.

This works as long as the subdomain is unoccupied by another GitHub Pages project and is super simple to set up — settings, enable GitHub Pages, type the subdomain “cdn2.cocoapods.org”:

Watch this short demo video to see it in action:

Impact

Generally speaking, the impact of hijacking a subdomain of a known website can trick users into thinking the content they are seeing is legitimate and created by the known brand.

Furthermore, organizations usually allow network traffic to such dev-related legitimate resources from sensitive networks to support the engineering process.

We’ve seen last year's cases in which attackers hosted malicious exe file on GitHub and another example where an image hosted on imgur.com contained malicious python code. Hence, it’s quite clear why attackers what’s the potential to hijack a subdomain of a popular and legitimate brand.

Conclusion

I disclosed the findings to CocoaPods in this GitHub issue, and huge respect for the fast response and removing the subdomain record.

It’s ridiculous how easy it is to takeover an abandoned subdomain. This made me wonder — should this be that easy? Should GitHub enforce 2-way validation when linking domain to GitHub Pages project? Like, validating the exact repository URL? IMHO — yes.

See this case as a warning if you have created subdomain records for side-projects that over time became obsolete like cdn2.cocoapods.org. I suggest removing them as someone might hijack your subdomain.

This is How I Hijacked CocoaPods Subdomain Using GitHub Pages was originally published in Checkmarx Zero on Medium, where people are continuing the conversation by highlighting and responding to this story.

During the past year, since the Russia-Ukraine war began, we’ve seen multiple examples of open-source packages with hidden protest messages and even examples of protest packages executing malicious code, all targeted at Russian developers.

The term “Protestware” has been used to describe software that includes features that are meant to raise awareness or protest an issue.

Last year we witnessed the node-ipc incident and learned protesters could take it one step further by also including malicious code aside from their protest messages.

Python Package “asolytics”

Asolytics is an open-source tool that helps with App Store Optimization (ASO) and provides features like calculating the popularity of keywords, tracking the position of an app in search results, monitoring keywords, and analyzing competitors.

This tool features a simple command-line interface and uses Selenium for automated browser functionality that runs in the background.

Initially, this project appeared to be a legitimate and well-made open-source tool. However, we discovered it through our package analysis system, which scans for potential risks and suspicious activity, indicating the potential presence of Protestware within the asolytics PyPi package.

Upon examination, we discovered that the tool’s business logic contain code that replaces “Russia” with “Russian Terrorist State” before presenting its results to the user.

Given the connection of the project’s owner to Ukraine, it is easy to understand the reason for this message. It is important to note that there is no evidence of any malicious code present in this tool.

My Humble Opinion

While the creators of open-source code have the right to express themselves in their own work, it is important to separate politics from open-source development.

Open-source code is a collaborative effort that should remain neutral and apolitical in order to maintain trust and cohesion within the community.

The incorporation of political messages in open-source code can have detrimental effects, including a loss of trust among users and contributors.

I submitted a pull request to the author’s project suggesting the removal of that message, but the likelihood of the author merging it is low.

Mixing Politics and Open Source: Bad Idea was originally published in Checkmarx Zero on Medium, where people are continuing the conversation by highlighting and responding to this story.