←back to thread

441 points longcat | 3 comments | | HN request time: 0.738s | source
Show context
0xbadcafebee ◴[] No.45039764[source]
Before anyone puts the blame on Nx, or Anthropic, I would like to remind you all what actually caused this exploit. The exploit was caused by an exploit, shipped in a package, that was uploaded using a stolen "token" (a string of characters used as a sort of "usename+password" to access a programming-language package-manager repository).

But that's just the delivery mechanism of the attack. What caused the attack to be successful were:

  1. The package manager repository did not require signing of artifacts to verify they were generated by an authorized developer.
  2. The package manager repository did not require code signing to verify the code was signed by an authorized developer.
  3. (presumably) The package manager repository did not implement any heuristics to detect and prevent unusual activity (such as uploads coming from a new source IP or country).
  4. (presumably) The package manager repository did not require MFA for the use of the compromised token.
  5. (presumably) The token was not ephemeral.
  6. (presumably) The developer whose token was stolen did not store the token in a password manager that requires the developer to manually authorize unsealing of the token by a new requesting application and session.
Now after all those failures, if you were affected and a GitHub repo was created in your account, this is a failure of:

  1. You to keep your GitHub tokens/auth in a password manager that requires you to manually authorize unsealing of the token by a new requesting application and session.
So what really caused this exploit, is all completely preventable security mechanisms, that could have been easily added years ago by any competent programmer. The fact that they were not in place and mandatory is a fundamental failure of the entire software industry, because 1) this is not a new attack; it has been going on for years, and 2) we are software developers; there is nothing stopping us from fixing it.

This is why I continue to insist there needs to be building codes for software, with inspections and fines for not following through. This attack could have been used on tens of thousands of institutions to bring down finance, power, telecommunications, hospitals, military, etc. And the scope of the attacks and their impact will only increase with AI. Clearly we are not responsible enough to write software safely and securely. So we must have a building code that forces us to do it safely and securely.

replies(8): >>45040360 #>>45040456 #>>45040507 #>>45042587 #>>45043533 #>>45044094 #>>45047267 #>>45049695 #
Hilift ◴[] No.45040507[source]
50% of impacted users the vector was VS Code and only ran on Linux and macOS.

https://www.wiz.io/blog/s1ngularity-supply-chain-attack

"contained a post-installation malware script designed to harvest sensitive developer assets, including cryptocurrency wallets, GitHub and npm tokens, SSH keys, and more. The malware leveraged AI command-line tools (including Claude, Gemini, and Q) to aid in their reconnaissance efforts, and then exfiltrated the stolen data to publicly accessible attacker-created repositories within victims’ GitHub accounts.

"The malware attempted lockout by appending sudo shutdown -h 0 to ~/.bashrc and ~/.zshrc, effectively causing system shutdowns on new terminal sessions.

"Exfiltrated data was double and triple-base64 encoded and uploaded to attacker-controlled victim GitHub repositories named s1ngularity-repository, s1ngularity-repository-0, or s1ngularity-repository-1, thousands of which were observed publicly.

"Among the varied leaked data here, we’ve observed over a thousand valid Github tokens, dozens of valid cloud credentials and NPM tokens, and roughly twenty thousand files leaked. In many cases, the malware appears to have run on developer machines, often via the NX VSCode extension. We’ve also observed cases where the malware ran in build pipelines, such as Github Actions.

"On August 27, 2025 9AM UTC Github disabled all attacker created repositories to prevent this data from being exposed, but the exposure window (which lasted around 8 hours) was sufficient for these repositories to have been downloaded by the original attacker and other malicious actors. Furthermore, base64-encoding is trivially decodable, meaning that this data should be treated as effectively public."

replies(1): >>45045155 #
1. smj-edison ◴[] No.45045155[source]
I'm a little confused about the sudo part, do most people not have sudo behind a password? I thought ~/.bashrc ran with user permissions...
replies(1): >>45045744 #
2. marshray ◴[] No.45045744[source]
My personal belief is that users should not be required type their password into random applications, terminals, and pop-up windows. Of course, login screens can be faked too.

So my main user account does not have sudo permissions at all, I have a separate account for that.

replies(1): >>45048138 #
3. 0xbadcafebee ◴[] No.45048138[source]
I'm lazy, so I have sudo and 1P/op gated by biometric. If for some reason biometric doesn't work (which happens a lot in Ubuntu... sigh...) I have a long alt-password that works instead. Otherwise I never type passwords, I only get them from 1P, because they're all complex and unique so I wouldn't remember them anyway. If I get a prompt I wasn't expecting, I cancel it.