7 ms·

SSH keys stolen by stream of malicious PyPI and NPM packages

76 points by fagnerbrack 3y ago

skilled 3y ago
Source, https://blog.sonatype.com/npm-packages-caught-exfiltrating-kubernetes-config-ssh-keys https://blog.sonatype.com/npm-packages-caught-exfiltrating-k...
upon_drumhead 3y ago
At this point, everyone needs to switch to https://github.com/maxgoedjen/secretive https://github.com/maxgoedjen/secretive
- 3abiton 3y ago
  This great find!
- __turbobrew__ 3y ago
  That is really cool. Apple should add support to their ssh implementation to do something similar.
- fbdab103 3y ago
  >Because secrets in the Secure Enclave are not exportable, they are not able to be backed up, and you will not be able to transfer them to a new machine. If you get a new Mac, just create a new set of secrets specific to that Mac. I consider that to be a deal-breaker. Hardware fails/lost/stolen, and I need to know that I have an offline backup somewhere if disaster strikes.
  - Xylakant 3y ago
    You could always register two keys, at least where that is supported, one for your Mac, another a hardware token that resides in a safe. Requires diligence, though, and is hard to verify that it’s been done correctly everywhere.
  - capableweb 3y ago
    Using private keys the way they are supposed to be used is a deal-breaker? You're supposed to have (at least) one keypair per device, so if you lose the device, you can restrict access by revoking the keypair belonging to the lost one. Are you currently sharing one keypair for all your devices?
    - fbdab103 3y ago
      It is about being prepared for disaster. If I use ten services registered with my private key, and the single authenticated hardware device goes poof (dies/lost/stolen) -is there an out of band mechanism for me to regain access on a new device? Maybe for some, but possibly not all. An offsite backup means that if everything goes down Monday, I can be back in business on Tuesday without fear. You could replicate some of this assurance with redundant hardware devices, but that requires perfect diligence in ensuring you have multiple devices approved to each service. AWS only just recently allowed multiple hardware tokens.
      - judofyr 3y ago
        Generate a separate SSH key which is only stored in your offsite backup (and then also encrypted with a password), and not on any of your physical machines.
        fbdab103 3y ago
        I must be missing something. If this novel key only exists inside my backups, it is not registered with any external services, and it cannot be used in the event the primary key is lost. For me to register the backup-only key with other services, it would have to live on my machine, and be simultaneously registered in addition to the primary key. I am not sure what I am gaining vs having a backup of the primary key other than increased operational burden.
        vladvasiliu 3y ago
        You can keep just the public part of the backup key on your current device and always enroll the two keys at a time. But yeah, if the main device is stolen, it can be a pain to go update all the services with the new device’s key. I personally use the gpg app on my youbikey for this, and the secret key comes from a backup I install on a livecd.
- Xylakant 3y ago
  Note that this comes with a set of pretty important caveats, notably no way to backup keys. Which means you absolutely need to have some way to regain access to whatever you secured with this - either via a backup key, by having another person that can grant access or similar.
- 3np 3y ago
  Regardless of how good that project might be: No, we don't. Might be appropriate to store keys in Secure Enclave for some but a dedicated TPM (Yubikey/Nitrokey/Trezor/Ledger/etc) is often preferred. Some might want or need backups. And even then, having multiple implementations widely used is preferred over having everyone relying on the same small group of volunteers or corporate working on any single one.
- bomewish 3y ago
  Superior to using ssh agent of software like bitwarden or keeper etc?
- myaccountonhn 3y ago
  Would this be more secure than using GnuPG (https://incenp.org/notes/2015/gnupg-for-ssh-authentication.html https://incenp.org/notes/2015/gnupg-for-ssh-authentication.h...)?
woodruffw 3y ago
I consider this kind of reporting (and underlying detection by companies capitalizing on supply chain security fears) borderline irresponsible: anybody can upload a package to a public index, by design, and the presence of a blatantly maliciously package doesn’t imply any degree of actual download, use of, or compromise via it. Removing malware from the index is a laudable goal, but the language of threats, attacks, thefts, etc. is essentially unsubstantiated: there’s no evidence that this goes beyond opportunistic, untargeted script kiddy behavior. Edit: FTA, the “rapid evolution” in question is that the malicious packages switched from using base64 for obfuscation to…double base64.
- SethMLarson 3y ago
  I am looking forward to PyPI's "answer" to this class of malicious packages with automated third-party reporting (and hopefully long-term, quarantining or even deletion). Hopefully this project will swing the narrative closer to the /actual/ security threat that these packages represent to their respective package ecosystems. The PyPI Safety and Security Engineer Mike Fiedler is working on this project :)
  - woodruffw 3y ago
    Yes! I think an under-considered aspect here is that this kind of high-volume malicious package activity isn’t particularly dangerous in and of itself, but does represent a operational/sustainability risk w/r/t compromising the index’s abilities to respond to actual urgent issues in a timely manner. More automation (reporting, quarantining) goes a long way towards addressing that. It’s more the language of compromise I resent: I think treating every low-effort malicious spam package as a fundamental risk unnecessarily “spends” the security mindshare budget that engineers keep in reserve. But I think my opinions there are already well-known :-)
- 015a 3y ago
  I... disagree. I feel that the differentiation between "lifting keys" and "maliciously using them" is not a useful one to make. Both actions are very bad. If you want to wait until we have evidence that the compromised keys were used to pull e.g. proprietary code or configuration from Github; why not also wait until that compromised data is sold? Or until a company is formed leveraging it? Ultimately, it's a slippery slope of "nothing will satisfy you", and there's clearly a genesis event here that is reprehensible and should be known about, even if it is, as you say, just opportunistic script kiddies. Speaking of which; I loath that characterization of threat actors. This is not the 90s anymore, and it's time to grow up and recognize that the opponents in this space can be extremely sophisticated and well-funded. This is, genuinely, something that many people in the industry refuse to accept; because it implies that we absolutely need to hold ourselves and our work to a higher standard, treat what we produce with severe gravity, and ultimately this means the pace of innovation will slow down and we'll need to ask the mirror serious questions like "wait, so you just, npm installed critical code that was handling sensitive user data? without even auditing it?" NPM (and, by extension, Github) are extremely blame-worthy here. Reports like this one absolutely happen so Sonatype can sell their product; no doubt on that coming from me whatsoever. But, they also put pressure on key infrastructure providers. > FTA, the “rapid evolution” in question is that the malicious packages switched from using base64 for obfuscation to…double base64. Ok, yeah; describing that as "rapid evolution" is overselling it. But let's play in that playground; it's not a rapid evolution, it's an unsophisticated additional layer of easily-reversible obfuscation, which npm did not catch. Why? Why is sonatype catching this, and not npm?
MilnerRoute 3y ago
This is from September.
- bdcravens 3y ago
  Trusting third-party code on machines run as administrator is problematic no matter when the article was published.
yellow_lead 3y ago
Always encrypt with a password when prompted by ssh-keygen
- fbdab103 3y ago
  Does ssh-keygen use a good/modern algorithm by default? My unfounded suspicion is that owing to its age and backwards compatibility, the password could be brute-forced on a modern GPU. Would love to hear differently. Edit: To put it differently, would it be irresponsible to commit my private key to a public repo if it were locked behind a 32-character passphrase?
  - upon_drumhead 3y ago
    The key layout is described in https://github.com/openssh/openssh-portable/blob/master/PROTOCOL.key https://github.com/openssh/openssh-portable/blob/master/PROT... and you can view it pretty easily via cat private_key_here | head -n -1 | tail -n +2 | base64 -d | xxd One I created in 2016 is using aes256-cbc with bcrypt for the kdf, which isn't awful at all.
  - enasterosophes 3y ago
    Just because OpenSSH (which includes ssh-keygen) has been around for a long time, doesn't mean it is static and outdated. It is under active development, with the latest release two months ago, and nearly 20 commits in the last month. OpenSSH regularly updates its defaults and removes backwards compatibility. Three months ago, they switched from RSA to ed25519 as the default private key type for `ssh-keygen -t`, and in August they disabled RSA/SHA-1. From the ssh-keygen manual: "It is possible to specify a passphrase when generating the key; that passphrase will be used to encrypt the private part of this file using 128-bit AES." Rather than spreading FUD, you can just decide for yourself whether AES-128 is secure enough for you. Since we don't know your threat model, only you can decide whether you're okay with publishing AES-128 encrypted private data in a public location.
    - fbdab103 3y ago
      No FUD intended, was genuinely asking. I recalled this 2018 article[0] titled, "The default OpenSSH key encryption is worse than plaintext" and was wondering if it is still true. Safe practices are a moving target. One on which I am not qualified to answer, hence my queries. Good to know that OpenSSH is improving, but is the future uniformly distributed? If you are running a Redhat LTS release, are you getting a secure by default private key protection, or do you have to invoke the correct command? I default to Github's keygen recommendations, but I can believe that others will run ssh-keygen without arguments. [0] https://latacora.github.io/blog/2018/08/03/the-default-openssh/ https://latacora.github.io/blog/2018/08/03/the-default-opens...
anotherhue 3y ago
Fun fact: You can protect your private key with your TPM, so even if it is stolen and even if you are keylogged the key is still useless.
- pavel_lishin 3y ago
  Can you say more about how this works?
  - upon_drumhead 3y ago
    https://www.ledger.com/blog/ssh-with-tpm https://www.ledger.com/blog/ssh-with-tpm is a good overview
- 2OEH8eoCRo0 3y ago
  It's funny how many don't know this. Almost as if the TPM wasn't designed to protect users.
  - halJordan 3y ago
    People don't know it for the same reason people don't know they can long press their phone's homescreen icons. We don't need some self-satisfying conspiracy.
- wg0 3y ago
  Pardon my ignorance but is TPM specific to PCs or available on Macs as well?
  - alwillis 3y ago
    For Macs: https://github.com/maxgoedjen/secretive https://github.com/maxgoedjen/secretive
jon-wood 3y ago
Key takeaways from my quick skim of this: 1. It was only uploading RSA private keys, which are pretty antiquated these days. Generate yourself an ed25519 key, which is both more secure, and not a million characters long when passing round the public key. 2. It wasn’t pulling keys from your SSH agent. This seems like yet another reason to use one. 1Password (unaffiliated, I just really like it) includes an agent that will load keys from your password store and ask for authentication the first time a process requests to use it. 3. I am once again struck by just how fragile the software supply chain is.
bhawks 3y ago
ssh-keygen -t ed25519-sk and chill. https://developers.yubico.com/SSH/Securing_SSH_with_FIDO2.html https://developers.yubico.com/SSH/Securing_SSH_with_FIDO2.ht... Can't steal keys that are in a detachable hsm.
- 2OEH8eoCRo0 3y ago
  Spend $650 and chill? https://www.yubico.com/product/yubihsm-2-series/yubihsm-2/ https://www.yubico.com/product/yubihsm-2-series/yubihsm-2/
  - bhawks 3y ago
    The $25 version works fine don't buy features you don't need. https://www.yubico.com/product/security-key-nfc-by-yubico-black/ https://www.yubico.com/product/security-key-nfc-by-yubico-bl...
    - 2OEH8eoCRo0 3y ago
      Oh. That's not an HSM.
      - marcus0x62 3y ago
        Yeah...Because an HSM isn't for storing ssh keys on developer machines...
  - wg0 3y ago
    Why is this so expensive? Like almost the price of an upper middle class GPU or a modern gaming console (PS5 or XBox or latest SteamDeck) so what's so expensive inside it to justify that much of a price? Or it's just enormous profit seeking?
    - marcus0x62 3y ago
      It's "expensive"[0] because the product being linked to is completely different than a hardware security token used to store a credential like an ssh key. Yubikeys that can store an ssh key are like $50. 0 - the Yubi HSM is 1-2 orders of magnitude less expensive than competing HSM products.
feross 3y ago
If you're curious to see what's going inside these malicious PyPI and NPM packages, we host a catalog of all removed packages for research use. Here are links to some examples of the cached malicious source code, along with the signals of malicious intent detected by Socket: https://socket.dev/npm/package/shineouts/files/1.12.16-beta.0/index.js https://socket.dev/npm/package/shineouts/files/1.12.16-beta.... https://socket.dev/npm/package/@dynamic-form-components/shineout/files/1.0.4-alpha.3/index.js https://socket.dev/npm/package/@dynamic-form-components/shin... https://socket.dev/npm/package/eslint-plugin-shein-soc-raw/files/1.1.5/post-install.cjs https://socket.dev/npm/package/eslint-plugin-shein-soc-raw/f... https://socket.dev/npm/package/@spgy/eslint-plugin-spgy-fe/files/1.0.0-rc.2/scripts/index.js https://socket.dev/npm/package/@spgy/eslint-plugin-spgy-fe/f... If you're curious to see more examples of the kind of malicious stuff that is posted regularly to package registries, we have a live updating list here: https://socket.dev/npm/issue/gptSecurity https://socket.dev/npm/issue/gptSecurity [Disclosure: I'm founder of Socket]
therein 3y ago
I was trying to install wscat the other day and did > npm install -g websocat Met with "Permission denied: node" Realizing what I wanted was actually > npm install -g wscat I did that and left me wondering what was going on with websocat's installation routines because websocat is actually a Rust project, so something someone might accidentally try to do what I have done with, a great name to squat. In this case it is innocent at a quick glance. Just uses websocat in Node, for some reason.
bdcravens 3y ago
It's by no means foolproof, but containerizing your apps can reduce blast radius.
pabs3 3y ago
I wonder how Sonatype detected these malicious packages.

76 points by fagnerbrack 3y ago

Source, https://blog.sonatype.com/npm-packages-caught-exfiltrating-kubernetes-config-ssh-keys https://blog.sonatype.com/npm-packages-caught-exfiltrating-k...

upon_drumhead 3y ago

At this point, everyone needs to switch to https://github.com/maxgoedjen/secretive https://github.com/maxgoedjen/secretive

3abiton 3y ago
This great find!
__turbobrew__ 3y ago
That is really cool. Apple should add support to their ssh implementation to do something similar.
fbdab103 3y ago
>Because secrets in the Secure Enclave are not exportable, they are not able to be backed up, and you will not be able to transfer them to a new machine. If you get a new Mac, just create a new set of secrets specific to that Mac. I consider that to be a deal-breaker. Hardware fails/lost/stolen, and I need to know that I have an offline backup somewhere if disaster strikes.
- Xylakant 3y ago
  You could always register two keys, at least where that is supported, one for your Mac, another a hardware token that resides in a safe. Requires diligence, though, and is hard to verify that it’s been done correctly everywhere.
- capableweb 3y ago
  Using private keys the way they are supposed to be used is a deal-breaker? You're supposed to have (at least) one keypair per device, so if you lose the device, you can restrict access by revoking the keypair belonging to the lost one. Are you currently sharing one keypair for all your devices?
  - fbdab103 3y ago
    It is about being prepared for disaster. If I use ten services registered with my private key, and the single authenticated hardware device goes poof (dies/lost/stolen) -is there an out of band mechanism for me to regain access on a new device? Maybe for some, but possibly not all. An offsite backup means that if everything goes down Monday, I can be back in business on Tuesday without fear. You could replicate some of this assurance with redundant hardware devices, but that requires perfect diligence in ensuring you have multiple devices approved to each service. AWS only just recently allowed multiple hardware tokens.
    - judofyr 3y ago
      Generate a separate SSH key which is only stored in your offsite backup (and then also encrypted with a password), and not on any of your physical machines.
      - fbdab103 3y ago
        I must be missing something. If this novel key only exists inside my backups, it is not registered with any external services, and it cannot be used in the event the primary key is lost. For me to register the backup-only key with other services, it would have to live on my machine, and be simultaneously registered in addition to the primary key. I am not sure what I am gaining vs having a backup of the primary key other than increased operational burden.
        vladvasiliu 3y ago
        You can keep just the public part of the backup key on your current device and always enroll the two keys at a time. But yeah, if the main device is stolen, it can be a pain to go update all the services with the new device’s key. I personally use the gpg app on my youbikey for this, and the secret key comes from a backup I install on a livecd.
Xylakant 3y ago
Note that this comes with a set of pretty important caveats, notably no way to backup keys. Which means you absolutely need to have some way to regain access to whatever you secured with this - either via a backup key, by having another person that can grant access or similar.
3np 3y ago
Regardless of how good that project might be: No, we don't. Might be appropriate to store keys in Secure Enclave for some but a dedicated TPM (Yubikey/Nitrokey/Trezor/Ledger/etc) is often preferred. Some might want or need backups. And even then, having multiple implementations widely used is preferred over having everyone relying on the same small group of volunteers or corporate working on any single one.
bomewish 3y ago
Superior to using ssh agent of software like bitwarden or keeper etc?
myaccountonhn 3y ago
Would this be more secure than using GnuPG (https://incenp.org/notes/2015/gnupg-for-ssh-authentication.html https://incenp.org/notes/2015/gnupg-for-ssh-authentication.h...)?

woodruffw 3y ago

I consider this kind of reporting (and underlying detection by companies capitalizing on supply chain security fears) borderline irresponsible: anybody can upload a package to a public index, by design, and the presence of a blatantly maliciously package doesn’t imply any degree of actual download, use of, or compromise via it. Removing malware from the index is a laudable goal, but the language of threats, attacks, thefts, etc. is essentially unsubstantiated: there’s no evidence that this goes beyond opportunistic, untargeted script kiddy behavior. Edit: FTA, the “rapid evolution” in question is that the malicious packages switched from using base64 for obfuscation to…double base64.

SethMLarson 3y ago
I am looking forward to PyPI's "answer" to this class of malicious packages with automated third-party reporting (and hopefully long-term, quarantining or even deletion). Hopefully this project will swing the narrative closer to the /actual/ security threat that these packages represent to their respective package ecosystems. The PyPI Safety and Security Engineer Mike Fiedler is working on this project :)
- woodruffw 3y ago
  Yes! I think an under-considered aspect here is that this kind of high-volume malicious package activity isn’t particularly dangerous in and of itself, but does represent a operational/sustainability risk w/r/t compromising the index’s abilities to respond to actual urgent issues in a timely manner. More automation (reporting, quarantining) goes a long way towards addressing that. It’s more the language of compromise I resent: I think treating every low-effort malicious spam package as a fundamental risk unnecessarily “spends” the security mindshare budget that engineers keep in reserve. But I think my opinions there are already well-known :-)
015a 3y ago
I... disagree. I feel that the differentiation between "lifting keys" and "maliciously using them" is not a useful one to make. Both actions are very bad. If you want to wait until we have evidence that the compromised keys were used to pull e.g. proprietary code or configuration from Github; why not also wait until that compromised data is sold? Or until a company is formed leveraging it? Ultimately, it's a slippery slope of "nothing will satisfy you", and there's clearly a genesis event here that is reprehensible and should be known about, even if it is, as you say, just opportunistic script kiddies. Speaking of which; I loath that characterization of threat actors. This is not the 90s anymore, and it's time to grow up and recognize that the opponents in this space can be extremely sophisticated and well-funded. This is, genuinely, something that many people in the industry refuse to accept; because it implies that we absolutely need to hold ourselves and our work to a higher standard, treat what we produce with severe gravity, and ultimately this means the pace of innovation will slow down and we'll need to ask the mirror serious questions like "wait, so you just, npm installed critical code that was handling sensitive user data? without even auditing it?" NPM (and, by extension, Github) are extremely blame-worthy here. Reports like this one absolutely happen so Sonatype can sell their product; no doubt on that coming from me whatsoever. But, they also put pressure on key infrastructure providers. > FTA, the “rapid evolution” in question is that the malicious packages switched from using base64 for obfuscation to…double base64. Ok, yeah; describing that as "rapid evolution" is overselling it. But let's play in that playground; it's not a rapid evolution, it's an unsophisticated additional layer of easily-reversible obfuscation, which npm did not catch. Why? Why is sonatype catching this, and not npm?

MilnerRoute 3y ago

This is from September.

bdcravens 3y ago
Trusting third-party code on machines run as administrator is problematic no matter when the article was published.

yellow_lead 3y ago

Always encrypt with a password when prompted by ssh-keygen

fbdab103 3y ago
Does ssh-keygen use a good/modern algorithm by default? My unfounded suspicion is that owing to its age and backwards compatibility, the password could be brute-forced on a modern GPU. Would love to hear differently. Edit: To put it differently, would it be irresponsible to commit my private key to a public repo if it were locked behind a 32-character passphrase?
- upon_drumhead 3y ago
  The key layout is described in https://github.com/openssh/openssh-portable/blob/master/PROTOCOL.key https://github.com/openssh/openssh-portable/blob/master/PROT... and you can view it pretty easily via cat private_key_here | head -n -1 | tail -n +2 | base64 -d | xxd One I created in 2016 is using aes256-cbc with bcrypt for the kdf, which isn't awful at all.
- enasterosophes 3y ago
  Just because OpenSSH (which includes ssh-keygen) has been around for a long time, doesn't mean it is static and outdated. It is under active development, with the latest release two months ago, and nearly 20 commits in the last month. OpenSSH regularly updates its defaults and removes backwards compatibility. Three months ago, they switched from RSA to ed25519 as the default private key type for `ssh-keygen -t`, and in August they disabled RSA/SHA-1. From the ssh-keygen manual: "It is possible to specify a passphrase when generating the key; that passphrase will be used to encrypt the private part of this file using 128-bit AES." Rather than spreading FUD, you can just decide for yourself whether AES-128 is secure enough for you. Since we don't know your threat model, only you can decide whether you're okay with publishing AES-128 encrypted private data in a public location.
  - fbdab103 3y ago
    No FUD intended, was genuinely asking. I recalled this 2018 article[0] titled, "The default OpenSSH key encryption is worse than plaintext" and was wondering if it is still true. Safe practices are a moving target. One on which I am not qualified to answer, hence my queries. Good to know that OpenSSH is improving, but is the future uniformly distributed? If you are running a Redhat LTS release, are you getting a secure by default private key protection, or do you have to invoke the correct command? I default to Github's keygen recommendations, but I can believe that others will run ssh-keygen without arguments. [0] https://latacora.github.io/blog/2018/08/03/the-default-openssh/ https://latacora.github.io/blog/2018/08/03/the-default-opens...

anotherhue 3y ago

Fun fact: You can protect your private key with your TPM, so even if it is stolen and even if you are keylogged the key is still useless.

pavel_lishin 3y ago
Can you say more about how this works?
- upon_drumhead 3y ago
  https://www.ledger.com/blog/ssh-with-tpm https://www.ledger.com/blog/ssh-with-tpm is a good overview
2OEH8eoCRo0 3y ago
It's funny how many don't know this. Almost as if the TPM wasn't designed to protect users.
- halJordan 3y ago
  People don't know it for the same reason people don't know they can long press their phone's homescreen icons. We don't need some self-satisfying conspiracy.
wg0 3y ago
Pardon my ignorance but is TPM specific to PCs or available on Macs as well?
- alwillis 3y ago
  For Macs: https://github.com/maxgoedjen/secretive https://github.com/maxgoedjen/secretive

jon-wood 3y ago

Key takeaways from my quick skim of this: 1. It was only uploading RSA private keys, which are pretty antiquated these days. Generate yourself an ed25519 key, which is both more secure, and not a million characters long when passing round the public key. 2. It wasn’t pulling keys from your SSH agent. This seems like yet another reason to use one. 1Password (unaffiliated, I just really like it) includes an agent that will load keys from your password store and ask for authentication the first time a process requests to use it. 3. I am once again struck by just how fragile the software supply chain is.

bhawks 3y ago

ssh-keygen -t ed25519-sk and chill. https://developers.yubico.com/SSH/Securing_SSH_with_FIDO2.html https://developers.yubico.com/SSH/Securing_SSH_with_FIDO2.ht... Can't steal keys that are in a detachable hsm.

2OEH8eoCRo0 3y ago
Spend $650 and chill? https://www.yubico.com/product/yubihsm-2-series/yubihsm-2/ https://www.yubico.com/product/yubihsm-2-series/yubihsm-2/
- bhawks 3y ago
  The $25 version works fine don't buy features you don't need. https://www.yubico.com/product/security-key-nfc-by-yubico-black/ https://www.yubico.com/product/security-key-nfc-by-yubico-bl...
  - 2OEH8eoCRo0 3y ago
    Oh. That's not an HSM.
    - marcus0x62 3y ago
      Yeah...Because an HSM isn't for storing ssh keys on developer machines...
- wg0 3y ago
  Why is this so expensive? Like almost the price of an upper middle class GPU or a modern gaming console (PS5 or XBox or latest SteamDeck) so what's so expensive inside it to justify that much of a price? Or it's just enormous profit seeking?
  - marcus0x62 3y ago
    It's "expensive"[0] because the product being linked to is completely different than a hardware security token used to store a credential like an ssh key. Yubikeys that can store an ssh key are like $50. 0 - the Yubi HSM is 1-2 orders of magnitude less expensive than competing HSM products.

feross 3y ago

If you're curious to see what's going inside these malicious PyPI and NPM packages, we host a catalog of all removed packages for research use. Here are links to some examples of the cached malicious source code, along with the signals of malicious intent detected by Socket: https://socket.dev/npm/package/shineouts/files/1.12.16-beta.0/index.js https://socket.dev/npm/package/shineouts/files/1.12.16-beta.... https://socket.dev/npm/package/@dynamic-form-components/shineout/files/1.0.4-alpha.3/index.js https://socket.dev/npm/package/@dynamic-form-components/shin... https://socket.dev/npm/package/eslint-plugin-shein-soc-raw/files/1.1.5/post-install.cjs https://socket.dev/npm/package/eslint-plugin-shein-soc-raw/f... https://socket.dev/npm/package/@spgy/eslint-plugin-spgy-fe/files/1.0.0-rc.2/scripts/index.js https://socket.dev/npm/package/@spgy/eslint-plugin-spgy-fe/f... If you're curious to see more examples of the kind of malicious stuff that is posted regularly to package registries, we have a live updating list here: https://socket.dev/npm/issue/gptSecurity https://socket.dev/npm/issue/gptSecurity [Disclosure: I'm founder of Socket]

therein 3y ago

I was trying to install wscat the other day and did > npm install -g websocat Met with "Permission denied: node" Realizing what I wanted was actually > npm install -g wscat I did that and left me wondering what was going on with websocat's installation routines because websocat is actually a Rust project, so something someone might accidentally try to do what I have done with, a great name to squat. In this case it is innocent at a quick glance. Just uses websocat in Node, for some reason.

bdcravens 3y ago

It's by no means foolproof, but containerizing your apps can reduce blast radius.

pabs3 3y ago

I wonder how Sonatype detected these malicious packages.