384,000 Sites Pull Code From Sketchy Code Library Recently Bought By Chinese Firm (arstechnica.com) 35
An anonymous reader quotes a report from Ars Technica: More than 384,000 websites are linking to a site that was caught last week performing a supply-chain attack that redirected visitors to malicious sites, researchers said. For years, the JavaScript code, hosted at polyfill[.]com, was a legitimate open source project that allowed older browsers to handle advanced functions that weren't natively supported. By linking to cdn.polyfill[.]io, websites could ensure that devices using legacy browsers could render content in newer formats. The free service was popular among websites because all they had to do was embed the link in their sites. The code hosted on the polyfill site did the rest. In February, China-based company Funnull acquired the domain and the GitHub account that hosted the JavaScript code. On June 25, researchers from security firm Sansec reported that code hosted on the polyfill domain had been changed to redirect users to adult- and gambling-themed websites. The code was deliberately designed to mask the redirections by performing them only at certain times of the day and only against visitors who met specific criteria.
The revelation prompted industry-wide calls to take action. Two days after the Sansec report was published, domain registrar Namecheap suspended the domain, a move that effectively prevented the malicious code from running on visitor devices. Even then, content delivery networks such as Cloudflare began automatically replacing pollyfill links with domains leading to safe mirror sites. Google blocked ads for sites embedding the Polyfill[.]io domain. The website blocker uBlock Origin added the domain to its filter list. And Andrew Betts, the original creator of Polyfill.io, urged website owners to remove links to the library immediately. As of Tuesday, exactly one week after malicious behavior came to light, 384,773 sites continued to link to the site, according to researchers from security firm Censys. Some of the sites were associated with mainstream companies including Hulu, Mercedes-Benz, and Warner Bros. and the federal government. The findings underscore the power of supply-chain attacks, which can spread malware to thousands or millions of people simply by infecting a common source they all rely on.
The revelation prompted industry-wide calls to take action. Two days after the Sansec report was published, domain registrar Namecheap suspended the domain, a move that effectively prevented the malicious code from running on visitor devices. Even then, content delivery networks such as Cloudflare began automatically replacing pollyfill links with domains leading to safe mirror sites. Google blocked ads for sites embedding the Polyfill[.]io domain. The website blocker uBlock Origin added the domain to its filter list. And Andrew Betts, the original creator of Polyfill.io, urged website owners to remove links to the library immediately. As of Tuesday, exactly one week after malicious behavior came to light, 384,773 sites continued to link to the site, according to researchers from security firm Censys. Some of the sites were associated with mainstream companies including Hulu, Mercedes-Benz, and Warner Bros. and the federal government. The findings underscore the power of supply-chain attacks, which can spread malware to thousands or millions of people simply by infecting a common source they all rely on.
Silly Chinese and Russians (Score:3)
Always trying to make the lives of others feel worse than their own.
Re: (Score:2)
Re: (Score:2)
Yet you still will go to hell to suffer damnation... ...because you forgot to praise our AI overlords!
(or should we listen to that silly group of people that believe there is only one true AI?)
Re:Silly Chinese and Russians (Score:5, Insightful)
What I don't understand, is why web browsers allow cross-site Javascript links by default. It's a terrible idea just in general. Even if nobody malicious were ever involved, even if malicious people did not *exist* it would still be a terrible idea from a maintainability perspective, because every time a function needs to be updated, tracking down all the callers to see how the changes will impact them is basically impossible.
Re: (Score:2)
But I say "private" because I don't suspect this specific action of being anything said government orchestrated, asked for, or cared about one way or the other. Redirecting users to gambling sites at certain times of day really doesn't feel like something
Re:Silly Chinese and Russians (Score:4, Insightful)
Of course not. It's likely the company behind it saw an opportunity to make a few bucks by having a few of the popular scripts run bitcoin miners and other things in the background so they could recoup their investment. It is a website with a ton of hits, so even being able to make a fraction of a penny per visitor is still millions of dollars per day.
It just needs someone smart enough to be able to do things like insert ads and other things to make money into the scripts.
I'm guessing they got too greedy too fast and people noticed and are quickly shutting them out.
As for why allow third party scripts, well, that ship had long sailed - it's why tools like NoScript were invented to allow site-level blocking of scripts.
But the main reason is of course, advertising. Advertisers would ask webmasters to add a line of code to pages which sourced the ad via a script on the ad server. This provided a lot of flexibility in what kind of ads could be inserted and where they went with minimal overhead on the ad server. I'm sure early versions of adblockers did just that - they simply prevented the loading of third party scripts. Unfortunately, the trend continued with many other things like jquery and such being hosted on their own sites as well.
Re: (Score:2)
In the Web 1.0 days you could remove ads from certain free web hosts (Angelfire) by putting a tag (Was it <noscript>? Some nonstandard tag) around the section of the HTML where the host injected the ads.
How to they get the site (Score:3)
Re:How to they get the site (Score:5, Interesting)
Kinda wondering if, at some point, we'll all wish we'd saved optical media from 20-30 years ago before there was all this motivation to backdoor everything. At some point you could be just as scared to update & patch as you are when you don't upgrade/patch. The risk of upgrading might turn out to be worse than keeping buggy-but-not-backdoored versions. I'm not saying it's that way now, but given a few more XZ-like discoveries, that might be the case.
Third-party Javascript (Score:5, Insightful)
Including Javascript hosted by a third party is handing control of your site, and the privacy of your visitors, over to whoever controls that site.
It is amazing how many sites link to third-party Javascript willy-nilly. If it's done at all it should be done with the utmost care. Really it shouldn't be done at all.
Re:Third-party Javascript (Score:5, Informative)
This has been solved a while ago:
https://www.w3schools.com/tags... [w3schools.com]
Problem is using it and what happens to your site if the script is broken (your site should cleanly work without polyfill, but what about jquery etc.)
Re:Third-party Javascript (Score:4, Informative)
Is it a solution though? Depends on WHY you are linking to a 3rd party site.
And it was "solved" before javascript even existed. You don't need to have your customers get executable code from a 3rd party at all, nor should you.
Re:Third-party Javascript (Score:4, Insightful)
How exactly this would help? It prevents upgrades (thus no security fixes), and if you use that exact version, you could just as well serve that script yourself.
Re: Third-party Javascript (Score:2)
you should always link to a specific version of the script. blind upgrades to latest could break your site.
to upgrade you manually edit the HTML with the new version and digest.
Re: (Score:2)
Psst (Score:2)
Re: (Score:2)
Interconnected Network. (Score:3)
Third party scripting shouldn't even be a thing allowed in the browser. .
Re: (Score:2)
With all the progress made in software tooling to produce non-spaghetti code, as well as educating people about: "spaghetti code == bad", web 2.0/3,0 fully embraced "spaghettifying" script dependencies and leveled it up a notch or two, maybe three..
Not your server not your code (Score:2)
Linux users could be next (Score:5, Interesting)
Re: (Score:2)
Wouldn't that certificate just successfully assert that the Javascript in question had been provided by, well, none other than whoever owns polyfill.io?
Re: (Score:1)
In a hypothetical scenario, the signature check would be to make polyfill.io's cert was also signed with Andrew Betts (or whoever)'s secret key, based on a signature made at the time of certification request. New chinese company wouldn't be able to spoof it.
That of course doesn't stop the new owner of polyfill.io to tell everyone on their new website "I lost my signing key, all developers please update to the new signature verification! -t Andrew Betts (100% true) :-)" ...
Re: (Score:2)
Re: (Score:2)
About that... check /.'s Content-Security-Policy header sometime.
Re: (Score:2)
Idea: The client can check the server for known-good certificates, not merely accepted by the browser's certificate authority, but in the script tag that references an external js file. It could have a "signed-by" signature check for individual files, or a check on who issued the certificate signing request for the TLS connection. But that'll never happen.
It is not like forged certificates hasn't happened yet, right? Ever heard of STUXNET?
Lessons from the incident (Score:5, Interesting)
The findings underscore the power of supply-chain attacks
I would rather say the findings underscore that you should host yourself the various stuff your page uses: CSS, JS, fonts, images...
External resources links let third parties track your visitors, or even attack them.
Re: Lessons from the incident (Score:2)
Re: (Score:3)
In this case, people pointed to a resource on a third party URL that started to sometimes serve up different content than they expected. That wouldn't happen if they hosted the files on their own server (unless their server was compromised more generally, of course).
Re: (Score:2)
This is why I never liked Just-In-Time linking but it's obvious why it is done.
Every large software developer changed their software to automatically and many cases, silently, install updates. It was originally used to ensure security and consistency for big applications. Automatically downloading the latest version became standard practice, even a laptop BIOS does it, nowadays. It was copied by JavaScript developers for obvious reasons: They didn't have to check for updates to 100 files and copy them
Lessons learned: the leaching epoch is over (Score:2)
Self hosting could even make it worse, since abandoned websites would never bother update their code base and would serve this backdoor forever.
There will never be a clean solution for such exploits unless the software community finally stops leeching without ever giving anything back. Overall this polyfill package helped millions of web site operators rake in billions, and still the maker of that software didn't earn enough to make a decent living off that software. So the outfit was sold to the highest bi