←back to thread

441 points longcat | 4 comments | | HN request time: 0.001s | 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 #
1. anon7000 ◴[] No.45043533[source]
> You to keep your GitHub tokens/auth in a password manager that requires you to manually authorize unsealing of the token

This is a failure of the GH CLI, IMO. If you log into the GH CLI, it gets access to upload repositories, and doesn’t require frequent re-auth. Unlike AWS CLI, which expires every 18hr or something like that depending on the policy. But in either case (including with AWS CLI), it’s simply too easy to end up with tokens in plaintext in your local env. In fact, it’s practically the default.

replies(1): >>45045921 #
2. madeofpalk ◴[] No.45045921[source]
gh cli is such a ticking time bomb. Anything can just run `gh auth token` and get a token that probably can read + write to all your work code.
replies(1): >>45047449 #
3. awirth ◴[] No.45047449[source]
These tokens never expire, and there is no way for organization administrators to get them to expire (or revoke them, only the user can do that), and they are also excluded from some audit logs. This applies not just to gh cli, but also several other first party apps.

See this page for more details: https://docs.github.com/en/apps/using-github-apps/privileged...

After discussing our concerns about these tokens with our account team, we concluded the only reasonable way to enforce session lengths we're comfortable with on GitHub cloud is to require an IP allowlist with access through a VPN we control that requires SSO.

https://github.com/cli/cli/issues/5924 is a related open feature request

replies(1): >>45048166 #
4. 0xbadcafebee ◴[] No.45048166{3}[source]
That is crazy. See, this is what I'm talking about. It shouldn't even be possible to have services that sensitive with auth tokens that can't expire.