8 ms·

NPM revoked all tokens. How is that irresponsible? https://status.npmjs.org/incidents/dn7c1fgrr7ng https://status.npmjs.org/incidents/dn7c1fgrr7ng

Benjammer 8y ago
A malicious change could have already been published somewhere else, couldn't it have? And we just haven't found it yet?
- Prefinem 8y ago
  Just saying they didn't do nothing. Maybe they didn't do as well as they could have, but they did do something.
  - mirashii 8y ago
    Calling it resolved is worse than doing nothing. If they had done nothing, at least people would know that "If I run npm install now, that's bad". Now they've claimed it is resolved, which tells their users "It's okay to start installing things again" when it isn't safe until an audit has been completed.
mirashii 8y ago
For one, they've marked the issue as resolved before they've completed any forensic analysis to discover if additional compromised packages were uploaded with stolen credentials during the window in which they weren't revoked. This gives the false sense that its safe to install packages again.
- throwaway5752 8y ago
  And the fact they don't get this is incredibly disconcerting.
  - mirashii 8y ago
    There's also no systemic fix for this issue. Next week, the same thing could happen again. It's time to enforce two-factor authentication for publishing packages. It's time to publish a roadmap towards package signing and verification. It's time to talk about sandboxing the install scripts to prevent token theft. We're done for the day is so far from sufficient.
    - deleted 8y ago
      [deleted]
    - nanodeath 8y ago
      > package signing and verification You're the first person I've seen mention this, which seems like it should be the first and most obvious line of defense against bad stuff like this. +1
      - smt88 8y ago
        People mention most of these steps every time npm fucks up (which is often). Package management is a mostly solved problem, but npm refuses to learn from the 30+ years of experience that Linux and other communities have had.
        eropple 8y ago
        I used to be one of the biggest HN proponents of dunking on Node. I would give it a thrashing second only to the windmill dunks I would line up on Go. These days, with ES6, TypeScript, and React...it's actually all pretty nice. But NPM is still and forever a mess that just plain didn't learn from its predecessors--and my only guess as to the cavalier treatment of security issues is that the NPM crew's a bunch of premillenial dispensationalists banking on getting raptured (or bought, I guess, but that's way less fun) before the chickens come home to roost, 'cause just about anything else seems implausible. I am thinking about getting in on Deno only and strictly because maybe that can have a package management solution that is not held captive by an irresponsible venture-backed entity. It's not like anyone's breaking NPM's grip anytime soon. (Even if you tried, their API is so awful as to be functionally incompatible unless you literally just copy their internal structure, so...yeah. Great. Hooray.)
thenewwazoo 8y ago
* eslint gets compromised, and 3.7.2 is published * eslint user FooCorp also gets compromised, and a similarly-malicious version of foolib-js gets published that includes the _same code_ to steal tokens * npm invalidates all tokens * you decide to use foolib-js, and your newly-minted token is now compromised npm are fucking this up, and royally.
- thephyber 8y ago
  While this is possible, I'm willing to give the NPM team at least a little benefit of the doubt that they actually researched the access logs before they state this: > We determined that access tokens for approximately 4,500 accounts could have been obtained before we acted to close this vulnerability. However, we have not found evidence that any tokens were actually obtained or used to access any npmjs.com account during this window.[1] I get that it's possible that other modules could already be infected, but it's also true that other modules could have been similarly infected long before this one. [1] https://blog.npmjs.org/post/175824896885/incident-report-npm-inc-operations-incident-of https://blog.npmjs.org/post/175824896885/incident-report-npm...
  - thenewwazoo 8y ago
    Your quote wonderfully illustrates that npm are either being obfuscatory or entirely missing the point. How did they determine tokens for 4,500 accounts could have been obtained, and what is that even supposed to mean? The problem here is that any user of these packages could have had their .npmjs file read and exfiltrated, not just some upstream package maintainer. Were there only 4,500 valid npm tokens or something? I cannot imagine that is the case. So either they looked at 4,500 packages uploaded during the compromise window and they're not explaining how they undertook to do that, or they don't understand the vector and are minimizing the severity of the issue.
    - w0rd-driven 8y ago
      I would assume their logs would possibly tell them which tokens were associated with the users that downloaded v3.7.2. npm probably doesn't need credentials to download a package so the number of downloads is likely higher. Determining other packages affected are another matter entirely and no one can say this attack vector is only bound by this specific date window. This could've been way more widespread unless they're unpacking payloads and grepping for key pieces of this specific attack. I think it would be helpful if they could expose some of those logs but considering the meat of what matters would be the IP addresses to verify if your machine was compromised (or your CI server) that GPDR effectively wiped that possibility off the table. It would almost behoove them to setup a kind of haveibeenpwned service where you can check against stuff like this in the future. It's not like this can't happen again as the hole hasn't been closed completely, only this one set of compromised packages appears clean for now.

Benjammer 8y ago

A malicious change could have already been published somewhere else, couldn't it have? And we just haven't found it yet?

Prefinem 8y ago
Just saying they didn't do nothing. Maybe they didn't do as well as they could have, but they did do something.
- mirashii 8y ago
  Calling it resolved is worse than doing nothing. If they had done nothing, at least people would know that "If I run npm install now, that's bad". Now they've claimed it is resolved, which tells their users "It's okay to start installing things again" when it isn't safe until an audit has been completed.

mirashii 8y ago

For one, they've marked the issue as resolved before they've completed any forensic analysis to discover if additional compromised packages were uploaded with stolen credentials during the window in which they weren't revoked. This gives the false sense that its safe to install packages again.

throwaway5752 8y ago
And the fact they don't get this is incredibly disconcerting.
- mirashii 8y ago
  There's also no systemic fix for this issue. Next week, the same thing could happen again. It's time to enforce two-factor authentication for publishing packages. It's time to publish a roadmap towards package signing and verification. It's time to talk about sandboxing the install scripts to prevent token theft. We're done for the day is so far from sufficient.
  - deleted 8y ago
    [deleted]
  - nanodeath 8y ago
    > package signing and verification You're the first person I've seen mention this, which seems like it should be the first and most obvious line of defense against bad stuff like this. +1
    - smt88 8y ago
      People mention most of these steps every time npm fucks up (which is often). Package management is a mostly solved problem, but npm refuses to learn from the 30+ years of experience that Linux and other communities have had.
      - eropple 8y ago
        I used to be one of the biggest HN proponents of dunking on Node. I would give it a thrashing second only to the windmill dunks I would line up on Go. These days, with ES6, TypeScript, and React...it's actually all pretty nice. But NPM is still and forever a mess that just plain didn't learn from its predecessors--and my only guess as to the cavalier treatment of security issues is that the NPM crew's a bunch of premillenial dispensationalists banking on getting raptured (or bought, I guess, but that's way less fun) before the chickens come home to roost, 'cause just about anything else seems implausible. I am thinking about getting in on Deno only and strictly because maybe that can have a package management solution that is not held captive by an irresponsible venture-backed entity. It's not like anyone's breaking NPM's grip anytime soon. (Even if you tried, their API is so awful as to be functionally incompatible unless you literally just copy their internal structure, so...yeah. Great. Hooray.)

thenewwazoo 8y ago

* eslint gets compromised, and 3.7.2 is published * eslint user FooCorp also gets compromised, and a similarly-malicious version of foolib-js gets published that includes the _same code_ to steal tokens * npm invalidates all tokens * you decide to use foolib-js, and your newly-minted token is now compromised npm are fucking this up, and royally.

thephyber 8y ago
While this is possible, I'm willing to give the NPM team at least a little benefit of the doubt that they actually researched the access logs before they state this: > We determined that access tokens for approximately 4,500 accounts could have been obtained before we acted to close this vulnerability. However, we have not found evidence that any tokens were actually obtained or used to access any npmjs.com account during this window.[1] I get that it's possible that other modules could already be infected, but it's also true that other modules could have been similarly infected long before this one. [1] https://blog.npmjs.org/post/175824896885/incident-report-npm-inc-operations-incident-of https://blog.npmjs.org/post/175824896885/incident-report-npm...
- thenewwazoo 8y ago
  Your quote wonderfully illustrates that npm are either being obfuscatory or entirely missing the point. How did they determine tokens for 4,500 accounts could have been obtained, and what is that even supposed to mean? The problem here is that any user of these packages could have had their .npmjs file read and exfiltrated, not just some upstream package maintainer. Were there only 4,500 valid npm tokens or something? I cannot imagine that is the case. So either they looked at 4,500 packages uploaded during the compromise window and they're not explaining how they undertook to do that, or they don't understand the vector and are minimizing the severity of the issue.
  - w0rd-driven 8y ago
    I would assume their logs would possibly tell them which tokens were associated with the users that downloaded v3.7.2. npm probably doesn't need credentials to download a package so the number of downloads is likely higher. Determining other packages affected are another matter entirely and no one can say this attack vector is only bound by this specific date window. This could've been way more widespread unless they're unpacking payloads and grepping for key pieces of this specific attack. I think it would be helpful if they could expose some of those logs but considering the meat of what matters would be the IP addresses to verify if your machine was compromised (or your CI server) that GPDR effectively wiped that possibility off the table. It would almost behoove them to setup a kind of haveibeenpwned service where you can check against stuff like this in the future. It's not like this can't happen again as the hole hasn't been closed completely, only this one set of compromised packages appears clean for now.