Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Tj-actions/changed-files GitHub Action Compromised – used by over 23K repos

stepsecurity.io

Post reply on HN
Print view View original

291–300 of 317 posts

Re: Tj-actions/changed-files GitHub Action Compromised – used by over 23K repos

#291

Post by 12_throw_away »

harrisi wrote: post #41

It's always been shocking to me that the way people run CI/CD is just listing a random repository on GitHub. I know they're auditable and you pin versions, but it's crazy to me that the recommended way to ssh to a server is to just give a random package from a random GitHub user your ssh keys, for example. This is especially problematic with the rise of LLMs, I think. It's the kind of common task which is annoying en…

> It's always been shocking to me that the way people run CI/CD is just listing a random repository on GitHub.

Right? My mental model of CI has always been "an automated sequence of commands in a well-defined environment". More or less an orchestrated series of bash scripts with extra sugar for reproducibility and parallelism.

Turning these into a web of vendor-locked, black-box "Actions" that someone else controls ... I dunno, it feels like a very pale imitation of the actual value of CI

Re: Tj-actions/changed-files GitHub Action Compromised – used by over 23K repos

#292

Post by klysm »

srvaroa wrote: post #247
rarkins wrote: post #177

Hi, Renovate author/maintainer here. The affected repo has now been taken down, so I am writing this partly from memory, but I believe the scenario is: 1. An attacker had write access to the tj-actions/changed-files repo 2. The attacker chose to spoof a Renovate commit, in fact they spoofed the most recent commit in the same repo, which came from Renovate 3. Important: this spoofing of commits wasn't done to "trick"…

>7. This incident has reminded that many people mistakenly assume that git tags are immutable, especially if they are in semver format. Although it's rare for such tags to be changed, they are not immutable by design IME, this will be more "learned" than "reminded". Many many people set up pipelines to build artefacts based on tags (e.g. a common practise being "on tag with some pattern, then build artefact:$tag") an…

How else should we do it?

Re: Tj-actions/changed-files GitHub Action Compromised – used by over 23K repos

#293

Post by klysm »

varunsharma07 wrote: post #289

I’m Varun, CEO & Co-Founder of StepSecurity. StepSecurity detected and reported the tj-actions/changed-files compromise and has been actively helping the community recover from this incident. To support you in understanding what happened and recovering swiftly, we’re hosting an Office Hour: Date: March 17, 2025 Time: 10:00 AM Pacific Time (PT) Add to your calendar: https://www.addevent.com/event/Tf25207322

You can rename office hour to sales pitch

Re: Tj-actions/changed-files GitHub Action Compromised – used by over 23K repos

#294

Post by klysm »

mgiladi wrote: post #285

We've recently released open-source tools that would have easily prevented this: 1. The maintainers could have used PRevent to immediately alert and block any PR containing malicious code, or easily configured it for detection in case of a direct push: https://github.com/apiiro/PRevent 2. Users could have used our malicious code detection ruleset to immediately detect and block it when scanning updates in all relevan…

Malicious code detection is a fools errand. The attacker would’ve known that was installed and obfuscated it to avoid detection. It’s trivial to do so because they know what the detection is.

There is no way this would’ve prevented anything.

Re: Tj-actions/changed-files GitHub Action Compromised – used by over 23K repos

#295

Post by DavyJone »

ebfe1 wrote: post #211
ebfe1 wrote: post #157

Doing a bit of investigation with github_events in clickhouse, it is quite clear that the accounts used to perform the attack was "2ft2dKo28UazTZ", "mmvojwip" also seems suspicious: https://play.clickhouse.com/play?user=play#c2VsZWN0ICogZnJvb... Actions taken by the threat actor at the time can be seen here: https://play.clickhouse.com/play?user=play#c2VsZWN0ICogZnJvb...

It seems i forgot to cater for the quota applied to free "play" user in ClickHouse in my previous query... In fact, the threat actor did a lot more... this should give a better list of actions that was performed - Clearly showed he was testing his payload: https://play.clickhouse.com/play?user=play#c2VsZWN0ICogZnJvb...

Nice find. Its a bit strange that the PRs listed there, are not present at all in the coinbase repo. Seems like the attack was directed there, but I also did not hear anything from Coinbase on this.

eg. Target their NPM and PYPI tokens, so they can push compromised packages.

Re: Tj-actions/changed-files GitHub Action Compromised – used by over 23K repos

#296

Post by afitnerd »

rarkins wrote: post #177

Hi, Renovate author/maintainer here. The affected repo has now been taken down, so I am writing this partly from memory, but I believe the scenario is: 1. An attacker had write access to the tj-actions/changed-files repo 2. The attacker chose to spoof a Renovate commit, in fact they spoofed the most recent commit in the same repo, which came from Renovate 3. Important: this spoofing of commits wasn't done to "trick"…

Thanks for this writeup! It seems like #1 was the real weakness. Have you identified how the attacker was able to get write access to tj-actions/changed-files? Did this discovery result in any changes to how people can contribute to the project?

Re: Tj-actions/changed-files GitHub Action Compromised – used by over 23K repos

#297

Post by rognjen »

captn3m0 wrote: post #168
rognjen wrote: post #126

Earlier quoted context omitted.

> Update the tags in the parent repository to point to the SHA of the fork I don't think that's possible. Forks are a GitHub UI construct. There would be two .git dirs so for all intents and purposes they're two repos that don't know about each other. Locally you can't refer to a commit that's in a different dir...

You just set two remotes locally, create a tag and push just the tag to upstream. You can definitely do it locally, and I think GitHub doesn’t prevent such pushes either.

Yes, but:

a) you'd need write permissions for the original remote

b) even if you did, that'd push the commit to the original repo with the tags

Re: Tj-actions/changed-files GitHub Action Compromised – used by over 23K repos

#298

Post by sunnybeetroot »

klysm wrote: post #292
srvaroa wrote: post #247

Earlier quoted context omitted.

>7. This incident has reminded that many people mistakenly assume that git tags are immutable, especially if they are in semver format. Although it's rare for such tags to be changed, they are not immutable by design IME, this will be more "learned" than "reminded". Many many people set up pipelines to build artefacts based on tags (e.g. a common practise being "on tag with some pattern, then build artefact:$tag") an…

How else should we do it?

By commit hash

Re: Tj-actions/changed-files GitHub Action Compromised – used by over 23K repos

#299

Post by bboreham »

sunnybeetroot wrote: post #298
klysm wrote: post #292

Earlier quoted context omitted.

How else should we do it?

By commit hash

It seems to me that pinning to a sha was not sufficient; the Renovate bot was updating actions referenced by sha.

Example: https://github.com/chains-project/maven-lockfile/pull/1111/f...

This appears to be governed by the `pinGitHubActionDigests` helper configured in `renovate.json`.

Re: Tj-actions/changed-files GitHub Action Compromised – used by over 23K repos

#300

Post by mgiladi »

klysm wrote: post #294
mgiladi wrote: post #285

We've recently released open-source tools that would have easily prevented this: 1. The maintainers could have used PRevent to immediately alert and block any PR containing malicious code, or easily configured it for detection in case of a direct push: https://github.com/apiiro/PRevent 2. Users could have used our malicious code detection ruleset to immediately detect and block it when scanning updates in all relevan…

Malicious code detection is a fools errand. The attacker would’ve known that was installed and obfuscated it to avoid detection. It’s trivial to do so because they know what the detection is. There is no way this would’ve prevented anything.

They have no way of knowing unless they have admin access, in which case they can do whatever they want anyway. If the tool produces any visible outputs, just configure it to block silently. That's on the maintainer side. On the consumer side, not even that discloses such use. Isn't it so?

Add behavioral detection, and you get a strong layer of defense, even if attackers know about it. You still want defense in depth as always, of course.

Post reply on HN