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

181–190 of 317 posts

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

#181

Post by greatgib »

Honestly now most people doing "modern software engineering" are retards with no concept of real software engineering concepts.

Shitload of cardboard cto are pushing for "modern practice" to use whatever new version of whatever random dependency downloaded straight from internet.

Some persons asked why I don't like Ruff or UV for Python for example? You start a new job, first thing you have to do after installing a serious and safe Linux distribution like debian:

Curl whateverwebsite.com/ruff/download/latest | bash --blindly-execute --like-an-idiot

-> retrieving-random-dependancy1.tgz

-> executing-random-code...

And I don't speak about the current trend with "pre-commit" where a lot of persons are ok to have automatic downloads and execution on dev machines and ci, at each commit, of hundred of really totally random plugins from random places.

But this is a cto enforced decision to have this pre-commit for software quality...

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

#182

Post by ricardobeat »

Sytten wrote: post #119

I am surprised nobody here mentionned immutable github actions that are coming [1]. Been waiting for them since the issue was open in 2022. This would have significantly reduce impact and hopefully github will get it over the finish line. I always fork my actions or at least use a commit hash. [1] https://github.com/features/preview/immutable-actions

I thought actions were already immutable and published to a registry, not fetched directly from their repo. TIL.

Go also uses tags for module versioning, and while go.mod or package-lock.json stop this attack from reaching existing consumers, allowing remapping of all versions to the compromised one still expands the impact surface a lot. GitHub should offer a “immutable tags” setting for repos like these.

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

#183

Post by [deleted] »

mubou wrote: 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…

[deleted]

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

#184

Post by mlor »

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 taking the time to comment. Not that it wasn't there before this, but this incident highlights a lot to take into consideration with respect to securing one's supply chain going forward.

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

#185

Post by shawabawa3 »

kurmiashish wrote: post #5

Disclaimer: I am a co-founder of StepSecurity. StepSecurity Harden-Runner detected this security incident by continuously monitoring outbound network calls from GitHub Actions workflows and generating a baseline of expected behaviors. When the compromised tj-actions/changed-files Action was executed, Harden-Runner flagged it due to an unexpected endpoint appearing in the network traffic—an anomaly that deviated from…

A simpler method to detect this would be to store GitHub action tag hashes and freeze an action if any tag is changed

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

#186

Post by evntdrvn »

harrisi wrote: post #61
sestep wrote: post #44

Earlier quoted context omitted.

The crazier part is, people typically don't even pin versions! It's possible to list a commit hash, but usually people just use a tag or branch name, and those can easily be changed (and often are, e.g. `v3` being updated from `v3.5.1` to `v3.5.2`).

You and someone else pointed this out. I only use GitHub-org actions, and I just thought that surely there would be a "one version to rule them all" type rule.. how else can you audit things? I've never seen anything recommending specifying a specific commit hash or anything for GitHub actions. It's always just v1, v2, etc.

it is documented as recommended here fwiw: https://docs.github.com/en/actions/security-for-github-actio...

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

#187

Post by imnotjames »

v1sionSec wrote: post #199

As the repo is was taken down is someone able to tell me when was the malicious commit pushed. Trying to get a timeline to see if any workflows using this action were trigger in that timeframe. Thank you

Your secrets will be published to the CI log if you were affected.

I believe it's everything since around 10pm ET last night. I would consider any runs in the past 24 hours to be suspect.

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

#188

Post by varunsharma07 »

mnahkies wrote: post #147
ashishb wrote: post #39

Earlier quoted context omitted.

> Can you really say you trust all of these? We need better capabilities. E.g. when I run `fd`, `rg` or similar such tool, why should it have Internet access? IMHO, just eliminating Internet access for all tools (e.g. in a power mode), might fix this. The second problem is that we have merged CI and CD. The production/release tokens should ideally not be on the same system as the ones doing regular CI. More users nee…

I've found firejail to be a useful tool for this ( https://github.com/netblue30/firejail ), and additionally use opensnitch ( https://github.com/evilsocket/opensnitch ) to monitor for unexpected network requests. For CI/CD using something like ArgoCD let's you avoid giving CI direct access to prod - it still needs write access to a git repo, and ideally some read access to Argo to check if deployment succeeded but it…

Great points! Harden-Runner (https://github.com/step-security/harden-runner) is similar to Firejail and OpenSnitch but purpose-built for CI/CD context. Harden-Runner detected this compromise due to an anomalous outbound network request to gist.githubusercontent.com.

Interestingly, Firejail itself uses Harden-Runner in its GitHub Actions workflows! https://github.com/search?q=repo%3Anetblue30%2Ffirejail%20ha...

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

#189

Post by nozzlegear »

aorloff wrote: post #125
from-nibly wrote: post #108

Earlier quoted context omitted.

This is the death of fun. Like when you had to use SSL for buying things online. Adding SSL was not bad, don't get me wrong. It's good that it's the default now. However. At one point it was sorta risky, and then it became required. Like when your city becomes crime ridden enough that you have to lock your car when you go into the grocery store. Yeah you probably should have been locking it the whole time. what would…

Just you wait. Here in America when your city becomes crime ridden enough you start leaving it unlocked again.

On the other extreme, I can (and do) leave my keys inside my running car while I shop for groceries!

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

#190

Post by carols10cents »

prmph wrote: post #148

To me the only solution is that we need a security in depth approach: - Create a trusted packages program, and mark trusted packages with a prominent badge. Package authors can apply to join the program, which will involve a review of their package and any subsequent updates. Ensure trusted packages can only depend on other trusted packages. - Implement a capabilities model for package managers. I hear Deno is better…

who is going to pay for the review of packages and updates? how do we know we can trust the reviewers?

github actions are name-spaced and that didn't help anything here...

Post reply on HN