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

Tinycolor supply chain attack post-mortem

sigh.dev

Post reply on HN
Print view View original

41–50 of 85 posts

Re: Tinycolor supply chain attack post-mortem

#41

Post by jerf »

chatmasta wrote: post #18
cyberax wrote: post #13

> 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.

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-li…

"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.

Re: Tinycolor supply chain attack post-mortem

#42

Post by dflock »

indigodaddy wrote: post #36
retlehs wrote: post #26

Earlier quoted context omitted.

This won’t protect against everything, but it still seems like a good idea to implement: https://github.com/danielroe/provenance-action

Yep I did see that, but I'm not planning on pushing anything, just want a tool to scan for any of the offending packages. Could make my own but feel like somebody must have already made something (and probably better than I can)

- [supply-chain-security · GitHub Topics · GitHub](https://github.com/topics/supply-chain-security)

- [GitHub - safedep/vet: Protect against malicious open source packages](https://github.com/safedep/vet)

- [GitHub - AikidoSec/safe-chain](https://github.com/AikidoSec/safe-chain)

- npm audit

Re: Tinycolor supply chain attack post-mortem

#43

Post by rectang »

KronisLV wrote: post #33
tcoff91 wrote: post #7

Earlier quoted context omitted.

Many packages have only 1 author.

I'm not sure why we never got around to more human in the loop with 2FA when it comes to this sort of stuff: "Oh, you want to publish a new package? Okay, confirm it on this app on your device/phone to make sure." Surely a button press on a pre-approved device wouldn't be too hard, pretty much how every user initiated online banking payment over here goes like. I once heard from a sysadmin that didn't want to automat…

I don’t think the current state of software development is irredeemable.

Ongoing downstream review of all dependency code is practical for only a tiny fraction of projects; for most projects using publisher reputation as a proxy for package safety is reasonable.

What’s not working is the low-standards package managers where inconveniencing authors is never acceptable because the whole enterprise is built on popularity with authors — you can’t trust that what those package managers give you reflects author intent.

Re: Tinycolor supply chain attack post-mortem

#44

Post by mnahkies »

tcoff91 wrote: post #37
mnahkies wrote: post #32

I think the point around incorporating MFA into the automated publishing flow isn't getting enough attention. I've got no problem with doing an MFA prompt to confirm publish by a CI workflow - but last I looked this was a convoluted process of opening a https tunnel out (using a third party solution) such that you could provide the code. I'd love to see either npm or GitHub provide an easy, out the box way, for me to…

Publishing a package involves 2 phases: uploading the package to npmjs, and making it availble to users. Right now these 2 phases are bundled together into 1 operation. I think the right way to approach this is to unbundle uploading the packages & publishing packages so that they're available to end-users. CI systems should be able to build & upload packages in a fully automated manner. Publishing the uploaded packag…

Completely agree tbh, and that would be one of my preferred approaches should npm be the actor to implement a solution.

I also think it makes sense for GitHub to implement the ability to mark a workflow as sensitive and requiring "sudo mode" (MFA prompt) to run. It's not miles away from what they already do around requiring maintainer approval to run workflows on PRs.

Ideally both of these would exist, as not every npm package is published via GitHub actions (or any CI system), and not every GitHub workflow taking a sensitive action is publishing an npm package.

Re: Tinycolor supply chain attack post-mortem

#45

Post by indigodaddy »

dflock wrote: post #42
indigodaddy wrote: post #36

Earlier quoted context omitted.

Yep I did see that, but I'm not planning on pushing anything, just want a tool to scan for any of the offending packages. Could make my own but feel like somebody must have already made something (and probably better than I can)

- [supply-chain-security · GitHub Topics · GitHub]( https://github.com/topics/supply-chain-security ) - [GitHub - safedep/vet: Protect against malicious open source packages]( https://github.com/safedep/vet ) - [GitHub - AikidoSec/safe-chain]( https://github.com/AikidoSec/safe-chain ) - npm audit

vet and safe-chain look good thanks! I'm just dabbling with Node only (no experience really), so haven't used npm audit but will see how that works too. Appreciate the links.

Re: Tinycolor supply chain attack post-mortem

#46

Post by arp242 »

mnahkies wrote: post #32

I think the point around incorporating MFA into the automated publishing flow isn't getting enough attention. I've got no problem with doing an MFA prompt to confirm publish by a CI workflow - but last I looked this was a convoluted process of opening a https tunnel out (using a third party solution) such that you could provide the code. I'd love to see either npm or GitHub provide an easy, out the box way, for me to…

I'm feeling that maybe the entire concept of "publishing packages" is something that's not really needed? Instead, the VCS can be used as a "source of truth", with no extra publishing step required.

This is how Go works: you import by URL, e.g. "example.com/whatever/pkgname", which is presumed to be a VCS repo (git, mercurial, subversion, etc.) Versioning is done by VCS tags and branches. You "publish" by adding a tag.

While VCS repos can and have been compromised, this removes an entire attack surface from the equation. If you read every commit or a diff between two tags, then you've seen it all. No need to also diff the .tar.gz packages. I believe this would have prevented this entire incident, and I believe also the one from a few weeks ago (AFAIK that also only relied on compromised npm accounts, and not VCS?)

The main downside is that moving a repo is a bit harder, since the import path will change from "host1.com/pkgname" to "otherhost.com/pkgname", or "github.com/oneuser/repo" to "github.com/otheruser/repo". Arguably, this is a feature – opinions are divided.

Other than that, I can't really think of any advantages a "publish package"-step adds? Maybe I'm missing something? But to me it seems like a relic from the old "upload tar archive to FTP" days before VCS became ubiquitous (or nigh-ubiquitous anyway).

Re: Tinycolor supply chain attack post-mortem

#47

Post by acdha »

arp242 wrote: post #46
mnahkies wrote: post #32

I think the point around incorporating MFA into the automated publishing flow isn't getting enough attention. I've got no problem with doing an MFA prompt to confirm publish by a CI workflow - but last I looked this was a convoluted process of opening a https tunnel out (using a third party solution) such that you could provide the code. I'd love to see either npm or GitHub provide an easy, out the box way, for me to…

I'm feeling that maybe the entire concept of "publishing packages" is something that's not really needed? Instead, the VCS can be used as a "source of truth", with no extra publishing step required. This is how Go works: you import by URL, e.g. "example.com/whatever/pkgname", which is presumed to be a VCS repo (git, mercurial, subversion, etc.) Versioning is done by VCS tags and branches. You "publish" by adding a ta…

There’s also a cost that installs take much longer, you need the full toolchain installed, and are no longer reproducible due to variations in the local build environment. If everything you do is a first-party CI build of a binary image you deploy, that’s okay but for tools you’re installing outside of that kind of environment it adds friction.

Re: Tinycolor supply chain attack post-mortem

#48

Post by gedy »

acdha wrote: post #47
arp242 wrote: post #46

Earlier quoted context omitted.

I'm feeling that maybe the entire concept of "publishing packages" is something that's not really needed? Instead, the VCS can be used as a "source of truth", with no extra publishing step required. This is how Go works: you import by URL, e.g. "example.com/whatever/pkgname", which is presumed to be a VCS repo (git, mercurial, subversion, etc.) Versioning is done by VCS tags and branches. You "publish" by adding a ta…

There’s also a cost that installs take much longer, you need the full toolchain installed, and are no longer reproducible due to variations in the local build environment. If everything you do is a first-party CI build of a binary image you deploy, that’s okay but for tools you’re installing outside of that kind of environment it adds friction.

Agreed, in the JS world? Hell no. Ironically, doing a local build would itself pull in a bunch of dependencies, whereas now you can at least have one built dependency technically.

Re: Tinycolor supply chain attack post-mortem

#50

Post by [deleted] »

tcoff91 wrote: post #37
mnahkies wrote: post #32

I think the point around incorporating MFA into the automated publishing flow isn't getting enough attention. I've got no problem with doing an MFA prompt to confirm publish by a CI workflow - but last I looked this was a convoluted process of opening a https tunnel out (using a third party solution) such that you could provide the code. I'd love to see either npm or GitHub provide an easy, out the box way, for me to…

Publishing a package involves 2 phases: uploading the package to npmjs, and making it availble to users. Right now these 2 phases are bundled together into 1 operation. I think the right way to approach this is to unbundle uploading the packages & publishing packages so that they're available to end-users. CI systems should be able to build & upload packages in a fully automated manner. Publishing the uploaded packag…

[deleted]
Post reply on HN