The popular GitHub Action tj-actions/changed-files was compromised and used to inject malicious code into projects that utilized it. The attacker gained access to the action's repository and added code that exfiltrated environment variables, secrets, and other sensitive information during workflow runs. This action, used by over 23,000 repositories, became a supply chain vulnerability, potentially affecting numerous downstream projects. The maintainers have since regained control and removed the malicious code, but users are urged to review their workflows and rotate any potentially compromised secrets.
The blog post "Tj-actions/changed-files GitHub Action Compromised – used by over 23K repos" by Step Security details a security incident involving a popular GitHub Action, tj-actions/changed-files, which was compromised and used to inject malicious code into the build processes of repositories that depended on it. This action, utilized by over 23,000 repositories, provided a convenient way to identify files changed in a given commit, a common requirement for optimizing workflows.
The attacker gained control of the tj-actions/changed-files repository by compromising the maintainer's account. They then introduced a malicious commit, specifically version 3.6.0, that included a backdoor. This backdoor injected a malicious script, ./setup.sh, disguised as a harmless setup script. When the compromised action was executed, this script would download and execute a second-stage payload from a remote server controlled by the attacker. This second payload was capable of exfiltrating sensitive information, such as environment variables, secrets, and repository contents, from the affected workflows.
The blog post emphasizes the severe security implications of this type of supply chain attack, where a compromised dependency can affect a large number of downstream users. It highlights the importance of verifying the integrity and provenance of third-party actions before incorporating them into CI/CD pipelines.
The post outlines several mitigation strategies for those who may have used the compromised version. These include immediately reviewing workflow logs for suspicious activity, rotating any potentially exposed secrets, and pinning the action to a known safe version (such as 3.5.1 or earlier) or migrating to an alternative solution. The post specifically suggests the dorny/paths-filter action as a secure replacement.
Furthermore, the article discusses broader best practices for securing GitHub Actions workflows. It recommends using OpenID Connect (OIDC) to limit the need for long-lived secrets, enabling branch protection rules to prevent unauthorized modifications to workflows, and adopting least-privilege access for GitHub Actions tokens. It also advocates for the development of mechanisms to detect anomalous behavior in workflows and alert administrators to potential compromises, such as unexpected network connections or the execution of unfamiliar scripts. The incident underlines the critical need for continuous vigilance and proactive security measures in the software supply chain.
Summary of Comments ( 205 )
https://news.ycombinator.com/item?id=43367987
Hacker News users discussed the implications of the
tj-actions/changed-filescompromise, focusing on the surprising longevity of the vulnerability (2 years) and the potential impact on the 23,000+ repositories using it. Several commenters questioned the security practices of relying on third-party GitHub Actions without thorough vetting, emphasizing the need for auditing dependencies and using pinned versions. The ease with which a seemingly innocuous action could be compromised highlighted the broader security risks within the software supply chain. Some users pointed out the irony of a security-focused action being the source of vulnerability, while others discussed the challenges of maintaining open-source projects and the pressure to keep dependencies updated. A few commenters also suggested alternative approaches for achieving similar functionality without relying on third-party actions.The Hacker News post discussing the compromise of the
tj-actions/changed-filesGitHub Action has a substantial number of comments exploring various facets of the incident and its implications.Several commenters discuss the nature of the vulnerability and the attacker's approach. Some point out the seemingly unsophisticated nature of the attack, highlighting the injected code's straightforward execution of a malicious payload without much obfuscation or stealth. Others analyze the specific mechanism of the compromise, noting how the attacker gained access to the maintainer's account and modified the action to include the malicious script. The relative ease with which this popular action was compromised raises concerns about the security of the software supply chain and the potential for similar attacks in the future.
A significant thread of discussion revolves around the responsibilities of open-source maintainers and the challenges they face. Commenters acknowledge the substantial workload often borne by maintainers who volunteer their time and expertise. The incident underscores the difficulty of securing open-source projects, particularly those with a large user base, and the potential consequences of compromised dependencies. Some suggest potential solutions, including increased scrutiny of third-party actions, improved security practices for maintainers, and the development of tools to detect malicious code in actions. The discussion also touches upon the financial aspect of open-source maintenance and the need for better support and resources for maintainers.
Several users express frustration with GitHub's handling of the situation, particularly the perceived lack of communication and transparency. Some commenters criticize the platform's security measures and suggest improvements, such as stricter verification processes for actions and more robust mechanisms for detecting and responding to compromises. Others point out the difficulty of verifying the integrity of third-party code and the need for better tools and practices to address this challenge.
The impact of the compromise on the broader software ecosystem is also a topic of discussion. Commenters speculate on the potential consequences for the thousands of repositories that rely on the affected action, including the possibility of data breaches and other security incidents. The incident highlights the interconnected nature of the software supply chain and the potential for widespread damage from a single compromised component. Some users share their experiences dealing with the fallout from the incident, including the steps they took to mitigate the risk and ensure the security of their projects.
Finally, there's a thread discussing the importance of supply chain security in general and the need for increased vigilance and proactive measures to protect against similar attacks in the future. Commenters suggest various strategies, including code signing, multi-factor authentication, and regular security audits. The incident serves as a wake-up call for the software development community, emphasizing the need for a more robust and secure approach to managing dependencies and protecting the software supply chain.