March 21, 2025 update:
We can now publicly disclose two additional details on this incident.
1) the specific target mentioned in the original post is Coinbase, who have confirmed an unsuccessful attempt to compromise coinbase/agentkit. Wiz has identified GitHub identities related to the attack, indicating the attacker is active in the crypto ecosystem, French and English speaking, and with working hours aligned to Europe or Africa.
The earliest indication of this connection was provided by San Tran on March 15th. We discovered further evidence of this connection, including:
A commit on tj-actions/changed-files from March 13th, with a payload variant that explicitly targets Coinbase repositories
A workflow log in coinbase/agentkit from March 14th, tied to a commit impersonating a Coinbase employee, showing a parallel attempt to compromise the repository's supply chain, by the same actor
The removal of changelog.yml, a workflow that uses tj-actions/changed-files, within an hour of the tj-actions comrpomise and well before public disclosure by StepSecurity
Wiz's full analysis was shared with Coinbase through their responsible disclosure channels. You can review a timeline via the Unit42 public disclosure, which echos Wiz's private report.
2) haya14busa has been able to identify and remediate, with assistance from GitHub, the compromised user that led to the action-setup incident. The implicated account was not maliciously added via the previously discussed Invite workflow, but rather itself compromised. We will continue to share responsibly as information develops.Wiz continues to support the reviewdog maintainer, following our responsible disclosure of the compromise of action-setup. We thank haya14busa and the tj-actions maintainers for their cooperation and rigor in remediating this incident. At this point, we believe they have resolved the incident, and reduced their exposure to future attacks.
March 19, 2025 update: This issue has been assigned CVE-2025-30154.
March 19, 2025 update: A reviewdog maintainer, in response to Wiz's disclosure, has published a detailed breakdown of the incident and their response.
A supply chain attack on the popular GitHub Action tj-actions/changed-files caused many repositories to leak their secrets over the weekend. Wiz Research has discovered an additional supply chain attack on reviewdog/actions-setup@v1, that may have contributed to the compromise of tj-actions/changed-files. At this point we believe this is a chain of supply chain attacks eventually leading to a specific high-value target.
As we previously reported, the widely used GitHub Action tj-actions/changed-files was compromised with a malicious payload that caused affected repositories to leak their secrets in logs. By extension, tj-actions/eslint-changed-files was also compromised at the same time, as it relies ontj-actions/changed-files.
Based on a lead from Adnan Khan, Wiz Research has identified that the v1 tag of the reviewdog/action-setup Github Action was compromised in the lead up to the tj-actions incident. Immediate response is necessary to mitigate the risk of credential theft and CI pipeline compromise.
The maintainers of tj-actions have disclosed that a compromised Github Personal Access Token (PAT) was the root cause that allowed attackers to modify the repository.
We believe that it is likely the compromise of reviewdog/action-setup is the root cause of the compromise of the tj-actions-bot PAT. tj-actions/eslint-changed-files uses reviewdog/action-setup@v1, and the tj-actions/changed-files repository runs this tj-actions/eslint-changed-files Action with a Personal Access Token. The reviewdog Action was compromised during roughly the same time window as the tj-actions PAT compromise.
Because the compromise of reviewdog/action-setup has not previously been disclosed and appears to have been remediated incidentally, there is ongoing risk of reoccurence. This could lead to a repeat compromise of tj-actions/changed-files.
Wiz has disclosed this issue to reviewdog and GitHub.
As we saw with tj-actions, the compromised reviewdog action injected malicious code into any CI workflows using it, dumping the CI runner memory containing the workflow secrets. While this is the same outcome as in the tj-actions case, the payload was distinct and did not use curl to retrieve the payload. Instead, the payload was base64 encoded and directly inserted into the install.sh file used by the workflow.
On public repositories, the secrets would then be visible to everyone as part of the workflow logs, though obfuscated as a double-encoded base64 payload. As of now, no external exfiltration of secrets to an attacker-controlled server were observed; secrets were only observable within the affected repositories themselves.
We believe reviewdog Action’s v1 tag was pointed to a malicious commit on March 11th between 18:42 and 20:31 UTC, before the v1 tag reverted to point at an old commit. The attacker may have force-pushed back to the older commit to cover up the compromise, which implies they achieved a narrow goal and desired to stay stealthy. (edit: an earlier draft of this post attributed this to an automated version bump, and has been edited based on feedback from a reviewdog maintainer)
There is still a risk of actions being cached and secrets that have already been leaked because of this compromise, so action is still required.
As of March 17, 2025, only one tag (v1) of the reviewdog/action-setup Action was found to be affected. Customers who were using a hash-pinned version of reviewdog/action-setup or who were pinned to a different tag would not be impacted.
However, this Action is then used as a component of numerous other actions from reviewdog, including:
reviewdog/action-shellcheck
reviewdog/action-composite-template
reviewdog/action-staticcheck
reviewdog/action-ast-grep
reviewdog/action-typos
Customers who were using other impacted reviewdog/actions could be impacted, regardless of the version of that action.
The investigation is still ongoing. We can tell the attacker gained sufficient access to update the v1 tag to the malicious code they had placed on a fork of the repository. The reviewdog Github Organization has a relatively large contributor base and appears to be actively adding contributors through automated invites. This increases the attack surface for a contributor’s access to have been compromised or contributor access to have been gained maliciously.
We’ll update this blogpost as new information comes to light.
Use this Github query to find references to the affected GitHub Actions in your organization's repositories (replace yourorg with the name of your Github organization).
If any affected repositories are identified, note the impacted workflow job and navigate to the "Actions" tab or click "View Runs". Check for any GitHub Actions that include the affected compromised component and ran during the relevant timeframe.
Navigate to the relevant workflow job, and expand the “Run reviewdog/action-setup@v1” step. If you see a line titled “🐶 Preparing environment ...”, the malicious code was run. Check whether there is a double-encoded base64 string within. If one exists, then that means that the malicious payload was successfully executed, and the impact depends on whether the repo is public or private: If the repo is public, then it means that the secrets in the string were publicly leaked in workflow logs, and we highly recommend rotating them as soon as possible. Otherwise, if the repo is private, then that means the secrets were not leaked publicly, but you should still consider rotating them.
Note that if your repository was impacted but the only secrets exposed were GitHub tokens beginning with the prefix ghs_, these are short-lived tokens that automatically expire within 24 hours or once the workflow job has completed. Consequently, unless a job was interrupted and failed to finish, there is limited long-term risk from the exposure of a ghs_ token alone.
Additionally, if your workflow does not explicitly reference custom secrets (for example, token: ${{ secrets.MYSECRET }}), it is unlikely that sensitive secrets were compromised as a result of this incident. The primary risk lies in the potential exposure of explicitly referenced custom secrets within affected workflows.
Stop using the impacted actions immediately and replace them with a safer alternative if possible.
Remove all references to the actions across all branches of your repositories, not just the main branch, to prevent potential execution in other branches.
Rotate any leaked secrets as soon as possible. Deleting the relevant workflow will also remove all the logs, which can prevent further exposure of the secrets. However, it is also recommended to download workflow logs from the exposure window before deleting anything.
As recommended by GitHub, pin all GitHub Actions to specific commit hashes instead of version tags to mitigate against future supply chain attacks.
Audit past workflow runs for suspicious activity. Check logs for unusual outbound network requests, and prioritize reviewing repositories where CI runner logs are publicly accessible, as secrets may have been exposed in logs.
Use GitHub’s allow-listing feature to block unauthorized GitHub Actions from running and configure GitHub to allow only trusted actions.
Wiz Code customers with GitHub connector can use the created controls on affected code repositories to detect the presence of compromised actions.
Wiz Sensor customers with Sensor deployed on CI workloads can detect malicious activity related to this attack, such as process memory dumping.
Wiz Defend customers with GitHub audit logs enabled are protected against potential secondary malicious activities facilitated by the abuse of any compromised credentials, such as deleting workflow logs or merges by unusual bot use.
Wiz customers can also refer to the Threat Intel Center advisory for this attack, which includes additional capabilities and will be updated as new ones are added.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。