Live data from Hacker News

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

stepsecurity.io

301–310 of 317 posts

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

#301
post #270
post #50

Earlier quoted context omitted.

People don't pin versions. Referencing a tag is not pinning a version, those can be updated, and they are even with the official actions from GitHub.

Some people do actually pin versions, like me. For instance: - uses: Swatinem/rust-cache@f0deed1e0edfc6a9be95417288c0e1099b1eeec3 # v2.7.7 or - uses: subosito/flutter-action@f2c4f6686ca8e8d6e6d0f28410eeef506ed66aff # v2.18.0 It's a bit more manual work, but lepiej dmuchać na zimne (lit. it is better to blow on something cold ), as the Polish proverb says.

You would still be exposed if you had renovate or dependabot make a PR where they update the hash for you, though. Here's a PR we got automatically created the other day:

-uses: docker/login-action@9780b0c442fbb1117ed29e0efdff1e18412f7567 # v3 +uses: docker/login-action@74a5d142397b4f367a81961eba4e8cd7edddf772 # v3

and this PR gets run with privileges since it's from a user with write permissions.

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

#302
post #6

In recent years, it's started to feel like you can't trust third-party dependencies and extensions at all anymore. I no longer install npm packages that have more than a few transitive dependencies, and I've started to refrain from installing vscode or chrome extensions altogether. Time and time again, they either get hijacked and malicious code added, or the dev themselves suddenly decides to betray everyone's trust…

I think the conventional approach of checking for vulnerabilities in 3rd party dependencies by querying CVE or some other database has set the current behaviour i.e. if its not vulnerable it must be safe. This implicit trust on vulnerability databases has been exploited in the wild to push malicious code to downstream users.

I think we will see security tools shifting towards "code" as the source of truth when making safety and security decision about 3rd party packages instead of relying only on known vulnerability databases.

Take a look at vet, we are working on active code analysis of OSS packages (+ transitive dependencies) to look for malicious code: https://github.com/safedep/vet

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

#303
post #158
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...

Note that these account seems to be deleted now - 2ft2dKo28UazTZ clearly did more than just changed-files and also seem to target coinbase/agentkit as well (Actually .. they might be targeted by the threat actor)

That is a really very likely scenario.

The attacker was trying to compromise agentkit and found changed-files used in the repo so looked around. Found that it was using a bot with a PAT to release.

Totally possible the bot account had a weak password, and the maintainer said it didn't have 2FA.

They got the release bot PAT so they tried possibly quite an obvious vector that. They didn't need anything sophisticated or to exfil the credentials because agentkit is public.

It just so happened that it was detected before agentkit updated dependencies.

It's possible that with if thye had checked the dependabot config they could've timed it a bit better so that it's picked up in agentkit before being detected.

edit: Although, I don't think PATs are visible after they're generated?

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

#304
post #211

Earlier quoted context omitted.

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.

I wonder if they forked it to "experiment" with the workflow coinbase has and doesn't actually make any pull request toward them, perhaps to validate their hypothesis/attack. with that said, coinbase pulled the workflow that used tj-actions/changed-files immediately around this time so hopefully no harm was done https://github.com/coinbase/agentkit/pull/570/files

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

#305
post #225

Earlier quoted context omitted.

If my library is left-padding a string with spaces, I don’t know how that could possibly introduce a major security vulnerability at all. People write the trusted, secure code, and people retire from that work, and new people need to come in and do the work. Inexperienced people are going to be writing code no matter what. So, you are either saying that no one should write new libraries because a major security vulne…

Well, broaden your horizon a bit from an irrelevant example of a "library" of a few lines to a real one a of few thousand lines, then you might know. Also those same people also write insecure code before they retire. Experienced people write security bugs all the time. What I'm saying is if you imagine a world where there is so much time to be wasted rewriting the same library a thousand times, you could try to imag…

One doesn’t need to rewrite an entire library; they only need the bits that they need, and should only implement those things. That is almost always going to be necessarily much smaller target.

If enough of these supply chain attacks keep happening, I’m going to become more and more of a hardliner about this. If we believe that we’re getting better as developers over time, on average, then surely this won’t be a problem in most cases.

Also, at no point have I been talking about anything like OpenSSL, or oauth libraries or anything that EVERYONE uses and needs. That doesn’t make sense. But a GitHub action that runs “git status”? I have a hard time telling someone to use any library for that, and that’s what the action this post is about does.

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

#306
post #294

Earlier quoted context omitted.

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…

I just went to the readme of PRevent, and looked at it when writing my comment. It puts a comment explaining specifically which code triggered the problem. The attacker can easily see this happening and then test locally with PRevent to make sure their obfuscated code will bypass your detection no?

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

#307
post #48
post #35

Earlier quoted context omitted.

I always use commit hashes for action versions. Dependabot handles it, it’s a no brainer.

> commit hashes There is some latent concern that most git installations use SHA-1 hashes, as opposed to SHA-256. [0] Also the trick of creating a branch that happens to be named the same as a revision, which then takes precedence for certain commands. [0] https://git-scm.com/docs/hash-function-transition

[deleted]

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

#308
post #6

In recent years, it's started to feel like you can't trust third-party dependencies and extensions at all anymore. I no longer install npm packages that have more than a few transitive dependencies, and I've started to refrain from installing vscode or chrome extensions altogether. Time and time again, they either get hijacked and malicious code added, or the dev themselves suddenly decides to betray everyone's trust…

Did you turn off updates on your phone as well? Because 99.999% of people have app auto-updates and every update could include an exploit. I'm not saying you're wrong not to trust package managers and extensions but you're life is likely full of the same thing. The majority of apps are made from 3rd party libraries which are made of 3rd party libraries, etc.... At least on phones they update constantly, and every upd…

I don't trust apps. I trust Apple (enough) that they engineered iOS to have a secure enough sandbox that a random calculator app can't just compromise my phone.

Most developer packages have much higher permission levels because they integrate it with your code without a clear separation of boundaries. This is why attackers now like to attack GitHub Actions because if you get access to secrets you can do a lot of damage.

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

#309
post #50

Earlier quoted context omitted.

People don't pin versions. Referencing a tag is not pinning a version, those can be updated, and they are even with the official actions from GitHub.

I think a big part of the problem is the way one typically "installs" a GH action: by copy-pasting something from README of the action. Let's have a look at a random official GH provided action: https://github.com/actions/checkout It lists the following snippet: `uses: actions/checkout@v4` Almost everyone will just copy paste this snippet and call it a day. Most people don't think twice that v4 is a movable target th…

I mean, I think there's a difference between trusting GitHub and trusting third parties. If I can't trust GitHub, then there's absolutely no point in hosting on GitHub or trusting anything in GitHub Actions to begin with.

But yes I do think using tags is problematic. I think for one, GitHub should ban re-tagging. I can't think of a good reason for a maintainer to re-publish a tag to another commit without malicious intent. Otherwise they should provide a syntax to pin to both a tag and a commit, something like this:

`uses: actions/checkout@v4.5.6@abcdef9876543210`

The action should only work if both conditions are satisfied. This way you can still gain semantics version info (so things like dependabot can work to notify an update) but the commit is still pinned.

---

I do have to say though, these are all just band-aids on top of the actual issue. If you are actually using a dependency that is compromised, someone is going to get screwed. Are you really going to read through the commit and the source code to scan for suspicious stuff? I guess if someone else got screwed before you did they may report it, but it's still fundamentally an issue here. The simple answer is "don't use untrustworthy repositories" but that is hard to guarantee. Only real solution is to use as few dependencies as possible.

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

#310
post #270

Earlier quoted context omitted.

Some people do actually pin versions, like me. For instance: - uses: Swatinem/rust-cache@f0deed1e0edfc6a9be95417288c0e1099b1eeec3 # v2.7.7 or - uses: subosito/flutter-action@f2c4f6686ca8e8d6e6d0f28410eeef506ed66aff # v2.18.0 It's a bit more manual work, but lepiej dmuchać na zimne (lit. it is better to blow on something cold ), as the Polish proverb says.

You would still be exposed if you had renovate or dependabot make a PR where they update the hash for you, though. Here's a PR we got automatically created the other day: -uses: docker/login-action@9780b0c442fbb1117ed29e0efdff1e18412f7567 # v3 +uses: docker/login-action@74a5d142397b4f367a81961eba4e8cd7edddf772 # v3 and this PR gets run with privileges since it's from a user with write permissions.

I don't think you should ever allow dependabot to make direct commits to the repository. The only sane setting (IMO) is that dependabot should just make PRs, and a human needs to verify that and hit merge. My personal opinion is for any serious repositories, allowing a robot to have commit access is often a bad time and ticking time bomb (security-wise).

Now, of course, if there are literally hundreds of dependencies to update every week, then a human isn't really going to go through each and make sure they look good, so that person just becomes a rubber-stamper, which doesn't help the situation. At that point the team should probably seriously evaluate if their tech stack is just utterly broken if they have that many dependencies.

Post reply on HN