The polyfill.js is a popular open source library to support older browsers. 100K+ sites embed it using the cdn.polyfill.io domain. Notable users are JSTOR, Intuit and World Economic Forum. However, in February this year, a Chinese company bought the domain and the Github account. Since then, this domain was caught injecting malware on mobile devices via any site that embeds cdn.polyfill.io. Any complaints were quickly removed (archive here) from the Github repository.
My favourite part is that the developers that currently own it said:
Someone has maliciously defamed us. We have no supply chain risks because all content is statically cached
https://github.com/polyfillpolyfill/polyfill-service/issues/2890#issuecomment-2191461961
Completely missing the point that they are the supply chain risk, and the fact that malicious code was already detected in their system (to the point where Google started blocking ads for sites that loaded polyfill .io scripts.
We don’t even know who they are - the repo is owned by an anonymous account called “polyfillpolyfill”, and that comment comes from another anonymous account “polyfillcust”.
I’m not into JS stuff, but when I read that google is blocking ads, shit must be flowing in gargantuan amounts…
nah. over 100k sites ignored dependency risks, even after the original owners warned them this exact thing would happen.
the real story is 100k sites not being run appropriately.
The hackers just engaged in a little bit of technical debt collecting ;)
I’m stealing this phrase
That’s not how systemic problems work.
This is probably one of the most security ignorant takes on here.
People will ALWAYS fuck up. The world we craft for ourselves must take the “human factor” into account, otherwise we amplify the consequences of what are predictable outcomes. And ignoring predictable outcomes to take some high ground doesn’t cary far.
The majority of industries that actually have immediate and potentially fatal consequences do exactly this, and have been for more than a generation now.
Damn near everything you interact with on a regular basis has been designed at some point in time with human psychology in mind. Built on the shoulders of decades of research and study results, that have matured to the point of becoming “standard practices”.
Ok, people will always fuck up, so what do you do?
The majority of industries that actually have immediate and potentially fatal consequences do exactly this, and have been for more than a generation now.
All the organizations (including public) getting ransomware and data stolen, it’s because the consequences are not that bad? It is not gross negligence?
I’m not sure if this is just a rhetorical question or a real one?
Because I didn’t claim it isn’t negligence. It is negligent, however, it is not a problem solvable by just pointing fingers. It’s a problem that solvable through more strict regulation and compliance.
Cyber security is almost exactly the same as safety in other industries. It takes the same mindset, it manifests in the same ways under the same conditions, it tends to only be resolved and enforced through regulations…etc
And we all know that safety is not something solvable by pointing fingers, and saying “Well Joe Smo shouldn’t have had his hand in there then”. You develop processes to avoid predictable outcomes.
That’s the key word here, predictable outcomes, these are predictable situations with predictable consequences.
The comment above mine is effectively victim blaming, it’s just dismissing the problem entirely instead of looking at solutions for it. Just like an industry worker being harmed on the job because of the negligence of their job site, there are an incredibly large number of websites compromised due to the negligence of our industry.
Just like the job site worker who doesn’t understand the complex mechanics of the machine they are using to perform their work, the website owner or maintainer does not understand the complex mechanics of the dependency chains their services or sites rely on.
Just like a job site worker may not have a good understanding of risk and risk mitigation, a software engineer does not have a good understanding of cybersecurity risk and risk mitigation.
In a job site this is up to a regulatory body to define, utilizing the expertise of many, and to enforce this in job sites. On job sites workers will go through regular training and exercises that educate them about safety on their site. For software engineers there is no regulatory body that performs enforcement. And for the most part software engineers do not go through regular training that informs them of cybersecurity safety.
One place I worked at recently was still using Node version 8. Running
npm installwould give me a mini heart attack… Like 400+ critical vulnerabilities, it was several thousand vulnerabilities all around.After the first 100, the other 300 kinda don’t matter.
deleted by creator
Whichever editor let them post “100 thousand” should be spanked one 100 times with the severed hand of whatever asshole wrote it in the first place.
Reposting my comment from Github:
A good reminder to be extremely careful loading scripts from a third-party CDN unless you trust the owner 100% (and even then, ownership can change over time, as shown here). You’re essentially giving the maintainer of that CDN full control of your site. Ideally, never do it, as it’s just begging for a supply chain attack. If you need polyfills for older browsers, host the JS yourself. :)
If you really must load scripts from a third-party, use subresource integrity so that the browser refuses to load it if the hash changes. A broken site is better than a hacked one.
And on the value of dynamic polyfills (which is what this service provides):
Often it’s sufficient to just have two variants of your JS bundles, for example “very old browsers” (all the polyfills required by the oldest browser versions your product supports) and “somewhat new browsers” (just polyfills required for browsers released in the last year or so), which you can do with browserslist and caniuse-lite data.
What’s the malware do?
This is why ublock origin is an essential security tool.
What rules can we add that solve this problem? (I’ve tried DDG but didn’t find any results)
This one is already in the default
uBlock filters - Badware risksI also strongly suggest adding https://big.oisd.nl/ as a filter list. It’s a large and well maintained domain blocklist (sourced from combining lots of other blocklists) that usually adds lots of these sorts of domains quickly and has very few false positives.
If you want to take it even further, check out the Pro list and Thread Intelligence Feeds list here https://github.com/hagezi/dns-blocklists
These can all be added to a pihole too if you use one.
That GitHub “archive here” link leads to a page where it hasn’t been archived… (or was the archive removed??).
Looks like someone tried to archive an archived page. You can see
https://web.archive.org/...is listed twice in the url. I just trimmed off the first one then it works: https://web.archive.org/web/20240229113710/https://github.com/polyfillpolyfill/polyfill-service/issues/2834
