5 ms·

Seems like people already forgot about Jia Tan. By the way why doesn't npm have already a system in place to flag sketchy releases where most of the code looks

Seems like people already forgot about Jia Tan. By the way why doesn't npm have already a system in place to flag sketchy releases where most of the code looks normal and there is a newly added obfuscated code with hexadecimal variable names and array lookups for execution...

tom1337 1y ago
It would also be great if a release needs to be approved by the maintainer via a second factor or an E-Mail verification. Once a release has been published to npm, you have an hour to verify it by clicking a link in an email and then enter another 2FA (separate OTP than for login, Passkey, Yubikey whatever). That would also prevent publishing with lost access keys. If you do not verify the release within the first hour it gets deleted and never published.
- naugtur 1y ago
  That's why we never went with using keys in CI for publishing. Local machine publishing requires a 2fa. automated publishing should use something like Pagerduty to signal that a version is being published to a group of maintainers and it requires an approval to go through. And any one of them can veto within 5 minutes. But we don't have that, so gotta be careful and prepare for the worst (use LavaMoat for that)
- Cthulhu_ 1y ago
  Not through e-mail links though, that's what caused this in the first place. E-mail notification, sure, but they should also do a phishing training mail - make it legit, but if people press the link they need to be told that NPM will never send them an email with a link.
dist-epoch 1y ago
> flag sketchy releases Because the malware writers will keep tweaking the code until it passes that check, just like virus writers submit their viruses to VirusTotal until they are undetected.
- galaxy_gas 1y ago
  its Typical that the Virus Writer will use their own service, there is criminal virustotal-clones that run many AV in VM and return the Results, because virustotal will share all binaries, anything upload in Virustotal will be detteceted shortly if it is not.
  - 47282847 1y ago
    Isn’t it still that when signatures are added at some point it turns out that the malware code has been uploaded months before, or did that change?
mystifyingpoi 1y ago
Detecting sketchy-looking hex codes should be pretty straightforward, but then I imagine there are ways to make sketchy code non-sketchy, which would be immediately used. I can imagine a big JS function, that pretends to do legit data manip, but in the process creates the payload.
- nicce 1y ago
  It is just about bringing the classic non-signature based antivirus software to the release cycle. Hard to say how useful it is, but usually it is endless cat-and-mouse play like with everything else.
- hombre_fatal 1y ago
  Yeah, It’s merely a fluke that the malware author used some crappy online obfuscator that created those hex code variables. It would have been less work and less suspicious if they just kept their original semantic variables like “originalFetch”.
- Cthulhu_ 1y ago
  It wouldn't be just one signal, but several - like a mere patch version that adds several kilobytes of code, long lines, etc. Or a release after a long silent period.
- cluckindan 1y ago
  A complexity per line check would have flagged it. Even a max line length check would have flagged it.
  - chatmasta 1y ago
    That would flag a huge percentage of JS packages that ship with minified code.
    - jay_kyburz 1y ago
      How are people verifying their dependencies if they are minified?
AtNightWeCode 1y ago
The problem is that it is even possible to push builds from dev machines.
- madeofpalk 1y ago
  With NPM now supporting OIDC, you can just turn this off now https://docs.npmjs.com/trusted-publishers https://docs.npmjs.com/trusted-publishers
deleted 1y ago
[deleted]
hulitu 1y ago
> By the way why doesn't npm have already a system in place to flag sketchy releases Because nobody gives a fsck. Normally, after npm was filled with malware, people would avoid it. But it seems that nobody (distro maintainers) cares. People get what they asked for (malware).

tom1337 1y ago

It would also be great if a release needs to be approved by the maintainer via a second factor or an E-Mail verification. Once a release has been published to npm, you have an hour to verify it by clicking a link in an email and then enter another 2FA (separate OTP than for login, Passkey, Yubikey whatever). That would also prevent publishing with lost access keys. If you do not verify the release within the first hour it gets deleted and never published.

naugtur 1y ago
That's why we never went with using keys in CI for publishing. Local machine publishing requires a 2fa. automated publishing should use something like Pagerduty to signal that a version is being published to a group of maintainers and it requires an approval to go through. And any one of them can veto within 5 minutes. But we don't have that, so gotta be careful and prepare for the worst (use LavaMoat for that)
Cthulhu_ 1y ago
Not through e-mail links though, that's what caused this in the first place. E-mail notification, sure, but they should also do a phishing training mail - make it legit, but if people press the link they need to be told that NPM will never send them an email with a link.

dist-epoch 1y ago

> flag sketchy releases Because the malware writers will keep tweaking the code until it passes that check, just like virus writers submit their viruses to VirusTotal until they are undetected.

galaxy_gas 1y ago
its Typical that the Virus Writer will use their own service, there is criminal virustotal-clones that run many AV in VM and return the Results, because virustotal will share all binaries, anything upload in Virustotal will be detteceted shortly if it is not.
- 47282847 1y ago
  Isn’t it still that when signatures are added at some point it turns out that the malware code has been uploaded months before, or did that change?

mystifyingpoi 1y ago

Detecting sketchy-looking hex codes should be pretty straightforward, but then I imagine there are ways to make sketchy code non-sketchy, which would be immediately used. I can imagine a big JS function, that pretends to do legit data manip, but in the process creates the payload.

nicce 1y ago
It is just about bringing the classic non-signature based antivirus software to the release cycle. Hard to say how useful it is, but usually it is endless cat-and-mouse play like with everything else.
hombre_fatal 1y ago
Yeah, It’s merely a fluke that the malware author used some crappy online obfuscator that created those hex code variables. It would have been less work and less suspicious if they just kept their original semantic variables like “originalFetch”.
Cthulhu_ 1y ago
It wouldn't be just one signal, but several - like a mere patch version that adds several kilobytes of code, long lines, etc. Or a release after a long silent period.
cluckindan 1y ago
A complexity per line check would have flagged it. Even a max line length check would have flagged it.
- chatmasta 1y ago
  That would flag a huge percentage of JS packages that ship with minified code.
  - jay_kyburz 1y ago
    How are people verifying their dependencies if they are minified?

AtNightWeCode 1y ago

The problem is that it is even possible to push builds from dev machines.

madeofpalk 1y ago
With NPM now supporting OIDC, you can just turn this off now https://docs.npmjs.com/trusted-publishers https://docs.npmjs.com/trusted-publishers

deleted 1y ago

[deleted]

hulitu 1y ago

> By the way why doesn't npm have already a system in place to flag sketchy releases Because nobody gives a fsck. Normally, after npm was filled with malware, people would avoid it. But it seems that nobody (distro maintainers) cares. People get what they asked for (malware).