←back to thread

Shai-Hulud malware attack: Tinycolor and over 40 NPM packages compromised

(socket.dev)
1208 points jamesberthoty | 5 comments | 16 Sep 25 11:22 UTC | HN request time: 0.331s | source
Show context
madeofpalk ◴[16 Sep 25 11:49 UTC] No.45260948[source]▶
My main takeaway from all of these is to stop using tokens, and rely on mechanisms like OIDC to reduce the blast radius of a compromise.

How many tokens do you have lying around in your home directory in plain text, able to be read by anything on your computer running as your user?

replies(1): >>45261000 #
diggan ◴[16 Sep 25 11:54 UTC] No.45261000[source]▶
> How many tokens do you have lying around in your home directory in plain text, able to be read by anything on your computer running as your user?

Zero? How many developers have plain-text tokens lying around on disk? Avoiding that been hammered into me from every developer more senior than me since I got involved with professional software development.

replies(5): >>45261018 #>>45261050 #>>45261136 #>>45261146 #>>45261317 #
1. pjc50 ◴[16 Sep 25 12:09 UTC] No.45261146[source]▶
Isn't this quite hard to achieve on local systems, where you don't have a CI vault automation to help?
replies(4): >>45261330 #>>45261623 #>>45262118 #>>45269012 #
2. diggan ◴[16 Sep 25 12:27 UTC] No.45261330[source]▶
I don't think so? I don't even know what a "CI vault automation" is, I store my credentials and secrets in 1Password, and use the CLI to get the secrets for the moments they're needed, I do all my development locally and things seem fine.
3. madeofpalk ◴[16 Sep 25 12:59 UTC] No.45261623[source]▶
It's not that hard if it's something you decide you care about and want to solve. Like diggan mentions, there's many tools, some you already might use, that can be used to inject secrets into applications that's not too onerous to use in your development workflow.
4. xmodem ◴[16 Sep 25 13:39 UTC] No.45262118[source]▶
I'd argue the reverse is true. On your local system, which only need to operate when a named user with a (hopefully) strong password is present, you can encrypt the secrets with the user's login password and the OS can verify that it's handing the secret out to the correct binary before doing so. The binary can also take steps to verify that it is being called directly from a user interaction and not from a build script of some random package.

The extent to which any of this is actually implemented varies wildly between different OSes, ecosystems and tools. On macOS, docker desktop does quite well here. There's also an app called Secretive which does even better for SSH keys - generating a non-exportable key in the CPU's secure enclave. It can even optionally prompt for login password or fingerprint before allowing the key to be used. It's practically almost as secure as using a separate hardware token for SSH but significantly more convenient.

In contrast, most of the time the only thing protecting the keys in your CI vault from being exfiltrated is that the malware needs to know the specific name / API call / whatever to read them. Plenty of CI systems you don't even need that, because the build script that uses the secrets will read them into environment variables before starting the build proper.

5. 0xbadcafebee ◴[16 Sep 25 22:23 UTC] No.45269012[source]▶
Most popular apps today have integrations to allow reading secrets from external programs. If not, they can take them from environment variables. Both those can then be loaded from a password manager, so the secret never lands on disk in plaintext.

Your program (or your shell) opens. It runs a program to ask the password manager for a secret. Your password manager prompts you to authorize unsealing the secret. You accept or deny. The secret is passed to the program that asked for it. Works very well with 1Password and tools like git, ssh, etc, or simply exporting the secret to an environment variable, either in a script or bashrc file.

Other programs also support OIDC, such as with git credential helper plugins, or aws sso auth.