[cyberax]

> exfiltrated a npm token with broad publish rights

I freaking HATE tokens. I hate them.

There should be a better way to do authentication than a glorified static password.

An example of how to do it correctly: Github as a token provider for AWS: https://aws.amazon.com/blogs/security/use-iam-roles-to-conne... But this is an exception, rather than a rule.

[chatmasta]

These machine-to-machine OIDC flows seem secure, and maybe they are when they’re implemented properly, but they’re really difficult to configure. And I can’t shake the feeling that they’re basically just “tokens with more moving parts,” at least for a big chunk of exploitation paths. Without a human in the loop, there’s still some “thing” that gets compromised, whether it’s a token or something that generates time-limited tokens.

In the case of this worm, the OIDC flow wouldn’t even help. The GitHub workflow was compromised. If the workflow was using an OIDC credential like this to publish to npm, the only difference would be the npm publish command wouldn’t use any credential because the GitHub workflow would inject some temporary identity into the environment. But the root problem would remain: an untrusted user shouldn’t be able to execute a workflow with secret parameters. Maybe OIDC would limit the impact to be more fine-grained, but so would changing the token permissions.

[jerf]

"Without a human in the loop, there’s still some “thing” that gets compromised, whether it’s a token or something that generates time-limited tokens."

Speaking knowingly reductionistically and with an indeterminate amount of sarcasm, one of the hardest problems in security is how to know something without knowing something. The first "knowing something" is being able to convince a security system to let you do something, and the second is the kind that an attacker can steal.

We do a lot of work trying to separate those two but it's a really, really hard problem, right down at its very deepest core.

I know I was amused 5-10 years ago as we went through a lot of gymnastics. "We have an SSH password here that we use to log in to this system over there and run this process." "That's not secure, because an attacker can get the password. Move that to an SSH key." "That's not secure, an attacker can get the key. Move the key into this secret manager." "That's not secure, an attacker can get into the secret manager. Move it to this 2FA system." "That's not secure, an attacker can get the 2FA token material, move it to...."

There are improvements you can make; if nothing else a well-done 2FA system means an attacker has to compromise 2 systems to get in, and if they are non-correlated that's a legit step up. But I don't think there's a full solution to "the attacker could" in the end. Just improvements.

[groggler]

A sk- key with no user presence test to use and pin to update is pretty perfect in my book.. Anything less and the authentication can too easily be permanently stolen out of pointless soft protections any more and the decisions are overly complicated hoops for whatever they were supposed to deliver.

[tetha]

Hence you need to start thinking about threat models and levels of compromise, even in your build system.

If I control the issuing and governance of these short-lived secrets, they very much help against many attacks. Go ahead and extract an upload token for one project which lives for 60 seconds, be my guest. Once I lose control how these tokens are created, most of these advantages go away - you can just create a token every minute, for any project this infrastructure might be responsible for.

If I maintain control about my pipeline definition, I can again do a lot of work to limit damage. For example, if I am in control, I can make sure the stages running untrusted codes have as little access to secrets as possible, and possibly isolate them in bubblewrap, VMs, ..., minimize the code with access to publishing rights. Once I lose control about the pipeline structure, all that goes away. Just add a build step to push all information and secrets to mastodon in individual toots, yey.

To me, this has very much raised questions about keeping pipeline definitions and code in one repository. Or at least, to keep a publishing/release process in there. I don't have a simple solution there, especially for OSS software with little infrastructure - it's not an easy topic. But with these supply chain attacks coming hot and fast every 2 weeks, it's something to think about.

[chatmasta]

But the token wasn’t the primary source of compromise here. It was the GitHub workflow which had the token embedded into it. There was no need for the actor to exfiltrate the token from the workflow to somewhere else, because they could simply run arbitrary code within the workflow.

It would have made little difference if the environment variable was NPM_WEBIDENTITY instead of NPM_TOKEN. The workflow was still compromised.

[cyberax]

Universal OIDC tokens would slow down the lateral expansion and make it more difficult.

You won't be able to exfiltrate a token that allows you to publish an NPM package outside of a workflow, the infection has to happen during a build on GH.

[arccy]

it's all the moving parts that allow for fine grained, time limited tokens though.

there are also interesting things you can do in combination with branch protection rulesets and limiting which tags/workflows can generate tokens with specific permissions

[er4hn]

Well the idea behind tokens is that they should be time and authZ limited. In most cases they are not so they degrade to a glorified static password.

Solutions like generating them live with a short lifetime, using solutions like oauth w/ proper scopes, biscuits that limit what they can do in detail, etc, all exist and are rarely used.

[undecidabot]

Trusted publishing is a thing now for many package registries, including npm: https://github.blog/changelog/2025-07-31-npm-trusted-publish...

[skydhash]

As another sibling comment have put it, it probably should be short lived or behind a manual verification (passphrase, 2fa,…)

[pabs3]

mTLS aka TLS client certs seems like the way to go.

[orphea]

How is a client cert not another glorified static password? It would have been stolen from repo secrets the same way.

[pabs3]

You don't store them in repos on disk, but in a HSM so they can't be stolen, and then you protect signing access to them based on service/process information.