In yet another software supply chain attack, threat actors have compromised the popular GitHub Actions workflow, actions-cool/issues-helperto run malicious code that harvests sensitive credentials and exfiltrates them to an attacker-controlled server.
« Every existing tag in the repository has been moved to point to an imposter commit that does not appear in the action’s normal commit history, » StepSecurity researcher Varun Sharma said. « That commit contains malicious code that exfiltrates credentials from CI/CD pipelines that run the action. »
An imposter commit refers to a deceptive software supply chain attack strategy in which malicious code is injected into a project by referencing a commit or tag that exists only in an adversary-controlled fork, rather than the original trusted repository. As a result, attackers can bypass standard Pull Request (PR) reviews and achieve arbitrary code execution.
The imposter commit, per the cybersecurity company, contains code that, upon being executed within a GitHub Actions runner, performs a series of actions –
- Downloads the Bun JavaScript runtime to the runner.
- Reads memory from the Runner.Worker process to extract credentials.
- Makes an outbound HTTPS call to an attacker-controlled domain (« t.m-kosche(.)com ») to transmit the stolen data.
StepSecurity said 15 tags associated with a second GitHub action, « actions-cool/maintain-one-comment » have also been compromised with the same functionality.
GitHub has since disabled access to the repository due to a « violation of GitHub’s terms of service. » It’s currently not known what led the Microsoft-owned subsidiary to this decision.
Interestingly, the exfiltration domain « t.m-kosche(.)com » has been observed in the latest wave of the Mini Shai-Hulud campaign targeting npm packages from the @antv ecosystem, indicating the two clusters of activity could be related.
« Because every tag now resolves to malicious commits, any workflow that references the action by version pulls the malicious code on its next run, » StepSecurity said. « Only workflows pinned to a known-good full commit SHA are unaffected. »
[ad_2]
Source link
