changed-files

I'm so glad someone dug into this properly after the tj-actions maintainer started locking threads and refusing to look into how the PAT was leaked. https://github.com/tj-actions/changed-files/issues/2464#issu...

The repository is back online, with this explanation from the developer: > This attack appears to have been conducted from a PAT token linked to @tj-actions-bot account to which "GitHub is not able to determine how this PAT was compromised." > Account Security Enhancements > * The password for the tj-actions-bot account has been updated. > * Authentication has been upgraded to use a passkey for enhanced security. > * The tj-actions-bot account role has been updated to ensure it has only the minimum necessary permissions. > * GitHub proactively revoked the compromised Personal Access Token (PAT) and flagged the organization to prevent further exploitation. https://github.com/tj-actions/changed-files/issues/2464#issu...

The GitHub repo and org disappeared while I was poking around. Both https://github.com/tj-actions and https://github.com/tj-actions/changed-files return 404.

User and repo all 404 now. https://github.com/tj-actions https://github.com/tj-actions/changed-files

Yes. It was probably a maintainer's creds being compromised. The [malicious commit is masquerading as a commit from Renovate](https://github.com/tj-actions/changed-files/commit/0e58ed867...)((https://github.com/apps/renovate) but it's not a `verified` commit (and so it's trivial for a bad actor to masquerade as them). https://stackoverflow.com/questions/67609381/why-do-all-my-g...

Sounds about right to me. We can use a few knowns about GitHub IAM to deduce a few things: 1. There are no deleted PRs or Issues on the repo (2461..2463 are all valid refs) 2. A legitimate `Renovate[Bot]` dep bump would have filed a PR. Last such PR was 5 days ago, and is presumably not the source for this. (I haven't gone through every dep change, but doesn't look like it). 3. That leaves us with the 0e58ed867 commit, which has to be a spoofed commit, since it doesn't belong to a branch and we don't have a corresponding PR(1). A complete takeover of the repo can result in a hanging commit (by deleting the renovate bump branch), but there must be a hanging PR-ref around. Since there isn't one: 4. All of the above points to a compromised account that has write access to the repo. There is also the https://github.com/tj-actions-bot account,

> https://github.com/tj-actions/changed-files/pull/2460 This kind of auto dependency bump bots are more trouble than their worth. If your app works today, bumping random deps won’t make it work better in any meaningful sense in 95% of cases. With such a small upside, the downside of introducing larger attack surfaces, subtle breakages (despite semver), major breakages, and in the worst cases, compromises (whether it’s a compromised dep, or fake bot commits that people are trained to ignore) just completely outweighs the upside. You’re on the fast lane to compromises by using this kind of crap. People should really learn from Go’s minimum version selection strategy.

heh, timing is everything https://github.com/chains-project/maven-lockfile/issues/1085... > After some cleanup the changed-files (https://github.com/tj-actions/changed-files) action seems to be more work to remove. It would be awesome if it could be added to the allowlist > Done. Allowed all versions of this action. Should I pin it to one version in the allowlist (won't be convenient if renovate updates this dependency)?

A list of projects claimed to be using it from the GitHub page: https://github.com/tj-actions/changed-files?tab=readme-ov-fi...

> In this specific case, the bad actor changes all of the version tags to point to their malicious commit: https://github.com/tj-actions/changed-files/tags This required compromising the entire repository, yes? It can't be explained as the maintainer being tricked into merging something malicious?

You can pin GitHub Actions to specific versions or specific commits. But note you can change version tags arbitrarily. In this specific case, the bad actor changes all of the version tags to point to their malicious commit: https://github.com/tj-actions/changed-files/tags So to avoid that you'd have to pin your GitHub Action to specific commits as outlined in this SO post: https://stackoverflow.com/a/78905195

Only commit hashes are safe. In this case the bad actor changed all of the version tags to point to their malicious commit. See https://github.com/tj-actions/changed-files/tags All the tags point to commit `^0e58ed8` https://github.com/tj-actions/changed-files/commit/0e58ed867...

Exactly. And that's what happened here -- the bad actor changed all of those version tags to point to their malicious commit. See https://github.com/tj-actions/changed-files/tags All the tags point to commit `^0e58ed8` https://github.com/tj-actions/changed-files/commit/0e58ed867...

Pretty good timing on the attacker. https://github.com/tj-actions/changed-files/tags?after=v35.9... Most folks around the world signed off. B-squad probably left cleaning up remaining tasks or just fucking around with co-workers and pondering the weekend. Most GH actions run on a schedule (ie, backups of db, connecting to blob storage services). Attacker(s) likely to extract plenty of secrets and exfil data before the alarms get triggered (if any) at companies. The next data dumps are going to be wild.