5 ms·

NPM forces 2fa, so I’m curious what the scenario was here. Was a committers phone compromised?

by binarymax 3y ago

rdl 3y ago
Github action
- rdl 3y ago
  Actually worse than that, former employee phished for credentials, per Ledger themselves. Underlying cause is utter incompetence by company, 4th strike.
Daviey 3y ago
The Github action leaked the creds, seemingly via a log. Looks like that action has been in use for ~4 months.
- koolba 3y ago
  Automated publishing without a human involved kind of kills the whole point of 2FA anyway. It is kind of funny that the crypto world of multi sigs relies on blind trust of unverified UI components.
  - deleted 3y ago
    [deleted]
  - latchkey 3y ago
    Technically, it is just the frontends. You can always interact with the contracts directly and that can't ever be shut down (if you know what you're doing). Can you do that with your bank? Let's also not forget that every other website on the planet that relies on npm also relies on the blind trust of unverified UI components. This isn't just silo'd to crypto.
    - cxr 3y ago
      > Let's also not forget that every other website on the planet that relies on npm also relies on the blind trust of unverified UI components. It feels like you think you're making a really good point here. In reality, it's just a run-of-the-mill appeal to popularity. The programmers doing this sort of thing on other websites are in the wrong, too.
  - jeroenhd 3y ago
    If properly configured and audited, this approach can be secure. Github is the only way configured to publish to NPM, and NPM pushes can only be initiated by signed commits from trusted accounts with MFA, the entire workflow is can be secure on its own. I don't really see the point for a project that doesn't seem to update their code all that often, though. The risk of misconfiguring something doesn't seem worth the effort saved by having someone with a 2FA key upload a tarball generated on their dev machine.
- hn_throwaway_99 3y ago
  This is exactly why GitHub support OpenID Connect, https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect https://docs.github.com/en/actions/deployment/security-harde..., so that long-lived secrets don't need to be present as part of the build. I'm not sure if NPM supports OIDC, which would be ironic given that both GitHub and NPM are owned by Microsoft.
  - fkyoureadthedoc 3y ago
    Why would that be ironic?
    - hn_throwaway_99 3y ago
      Sorry, my sentence was poorly written, I meant it would be ironic if NPM didn't support OIDC.
- KomoD 3y ago
  Source? Their twitter says "This morning CET, a former Ledger Employee fell victim to a phishing attack that gained access to their NPMJS account." And Github Actions automatically redacts the secret in the log
  - Daviey 3y ago
    You are right, I should have waited for the postmortem.. it appeared the likely way because the secret was in the release pipeline env. However.. something doesn't add up. There is no chance that a malicious actor gained access and in a couple of hours put together this exploit. Or, I can't see someone putting together this exploit, THEN trying to spear-phish in hope of getting lucky and pressing the button.
    - deleted 3y ago
      [deleted]
    - ezekg 3y ago
      > I can't see someone putting together this exploit, THEN trying to spear-phish in hope of getting lucky and pressing the button. How can you not see someone doing that? The effort netted them $600k. Is this not how exploits work? Build the exploit and then try to use it by finding an "in." They don't find an "in" and then build the exploit.
    - deleted 3y ago
      [deleted]
forward1 3y ago
2FA only protects login. Pretty much all account security from that point on is based on portable bearer tokens.
- binarymax 3y ago
  Not sure what you mean. Every time I publish to NPM it prompts me for a one time code.
  - mikeryan 3y ago
    Sounds like they’re publishing to npm with a GitHub action which can be done with an automation token which bypasses 2fa
- frankjr 3y ago
  There is an option to always require 2fa when publishing a package. > To protect your packages, as a package publisher, you can require everyone who has write access to a package to have two-factor authentication (2FA) enabled. This will require that users provide 2FA credentials in addition to their login token when they publish the package. > Require two-factor authentication and disallow tokens: With this option, a maintainer must have two-factor authentication enabled for their account, and they must publish interactively. Maintainers will be required to enter 2FA credentials when they perform the publish. Automation tokens and granular access tokens cannot be used to publish packages. https://docs.npmjs.com/requiring-2fa-for-package-publishing-and-settings-modification https://docs.npmjs.com/requiring-2fa-for-package-publishing-...
mikeryan 3y ago
NPM optionally enforces 2FA. You can create an automation token to bypass it. In that case depending on how branches are protected a push to the right branch can publish a new package. https://github.blog/changelog/2020-10-02-npm-automation-tokens/ https://github.blog/changelog/2020-10-02-npm-automation-toke... Heck if they have an automated deployment and use devs personal GitHub handles all it would take is forgetting to remove an ex employee from the right github access group. Even if you took away all other access when they left.

NPM forces 2fa, so I’m curious what the scenario was here. Was a committers phone compromised?

rdl 3y ago

Github action

rdl 3y ago
Actually worse than that, former employee phished for credentials, per Ledger themselves. Underlying cause is utter incompetence by company, 4th strike.

Daviey 3y ago

The Github action leaked the creds, seemingly via a log. Looks like that action has been in use for ~4 months.

koolba 3y ago
Automated publishing without a human involved kind of kills the whole point of 2FA anyway. It is kind of funny that the crypto world of multi sigs relies on blind trust of unverified UI components.
- deleted 3y ago
  [deleted]
- latchkey 3y ago
  Technically, it is just the frontends. You can always interact with the contracts directly and that can't ever be shut down (if you know what you're doing). Can you do that with your bank? Let's also not forget that every other website on the planet that relies on npm also relies on the blind trust of unverified UI components. This isn't just silo'd to crypto.
  - cxr 3y ago
    > Let's also not forget that every other website on the planet that relies on npm also relies on the blind trust of unverified UI components. It feels like you think you're making a really good point here. In reality, it's just a run-of-the-mill appeal to popularity. The programmers doing this sort of thing on other websites are in the wrong, too.
- jeroenhd 3y ago
  If properly configured and audited, this approach can be secure. Github is the only way configured to publish to NPM, and NPM pushes can only be initiated by signed commits from trusted accounts with MFA, the entire workflow is can be secure on its own. I don't really see the point for a project that doesn't seem to update their code all that often, though. The risk of misconfiguring something doesn't seem worth the effort saved by having someone with a 2FA key upload a tarball generated on their dev machine.
hn_throwaway_99 3y ago
This is exactly why GitHub support OpenID Connect, https://docs.github.com/en/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect https://docs.github.com/en/actions/deployment/security-harde..., so that long-lived secrets don't need to be present as part of the build. I'm not sure if NPM supports OIDC, which would be ironic given that both GitHub and NPM are owned by Microsoft.
- fkyoureadthedoc 3y ago
  Why would that be ironic?
  - hn_throwaway_99 3y ago
    Sorry, my sentence was poorly written, I meant it would be ironic if NPM didn't support OIDC.
KomoD 3y ago
Source? Their twitter says "This morning CET, a former Ledger Employee fell victim to a phishing attack that gained access to their NPMJS account." And Github Actions automatically redacts the secret in the log
- Daviey 3y ago
  You are right, I should have waited for the postmortem.. it appeared the likely way because the secret was in the release pipeline env. However.. something doesn't add up. There is no chance that a malicious actor gained access and in a couple of hours put together this exploit. Or, I can't see someone putting together this exploit, THEN trying to spear-phish in hope of getting lucky and pressing the button.
  - deleted 3y ago
    [deleted]
  - ezekg 3y ago
    > I can't see someone putting together this exploit, THEN trying to spear-phish in hope of getting lucky and pressing the button. How can you not see someone doing that? The effort netted them $600k. Is this not how exploits work? Build the exploit and then try to use it by finding an "in." They don't find an "in" and then build the exploit.
  - deleted 3y ago
    [deleted]

forward1 3y ago

2FA only protects login. Pretty much all account security from that point on is based on portable bearer tokens.

binarymax 3y ago
Not sure what you mean. Every time I publish to NPM it prompts me for a one time code.
- mikeryan 3y ago
  Sounds like they’re publishing to npm with a GitHub action which can be done with an automation token which bypasses 2fa
frankjr 3y ago
There is an option to always require 2fa when publishing a package. > To protect your packages, as a package publisher, you can require everyone who has write access to a package to have two-factor authentication (2FA) enabled. This will require that users provide 2FA credentials in addition to their login token when they publish the package. > Require two-factor authentication and disallow tokens: With this option, a maintainer must have two-factor authentication enabled for their account, and they must publish interactively. Maintainers will be required to enter 2FA credentials when they perform the publish. Automation tokens and granular access tokens cannot be used to publish packages. https://docs.npmjs.com/requiring-2fa-for-package-publishing-and-settings-modification https://docs.npmjs.com/requiring-2fa-for-package-publishing-...

mikeryan 3y ago

NPM optionally enforces 2FA. You can create an automation token to bypass it. In that case depending on how branches are protected a push to the right branch can publish a new package. https://github.blog/changelog/2020-10-02-npm-automation-tokens/ https://github.blog/changelog/2020-10-02-npm-automation-toke... Heck if they have an automated deployment and use devs personal GitHub handles all it would take is forgetting to remove an ex employee from the right github access group. Even if you took away all other access when they left.