Entrar
Surprise: When Dependabot Contributes Malicious Code
- 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.
