Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Security The Internet China Java

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.

This discussion has been archived. No new comments can be posted.

384,000 Sites Pull Code From Sketchy Code Library Recently Bought By Chinese Firm

Comments Filter:
  • by RitchCraft ( 6454710 ) on Friday July 05, 2024 @02:30PM (#64603667)

    Always trying to make the lives of others feel worse than their own.

    • Glorious Leader Xi make shiny happy people shiny happy! Tibet Xinjiang happy China! America over! Hail Putin!
      • 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?)

    • by jonadab ( 583620 ) on Friday July 05, 2024 @03:50PM (#64603877) Homepage Journal
      Although the Chinese government is terrible in general, I do not suspect them of being involved in this specific instance. It was probably just a shady private company exploiting the situation. Probably.

      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.
      • by jonadab ( 583620 )
        When I say "private company", in this context, I of course mean a Chinese company, which means that in principle they will do absolutely anything the Chinese government says, hand over any data without a warrant and without notice, etc., the usual caveats.

        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
      • by tlhIngan ( 30335 ) <slashdot@worf . n et> on Friday July 05, 2024 @07:42PM (#64604197)

        Although the Chinese government is terrible in general, I do not suspect them of being involved in this specific instance. It was probably just a shady private company exploiting the situation. Probably.

        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.

        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.

        • 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.

  • by Retired Chemist ( 5039029 ) on Friday July 05, 2024 @02:32PM (#64603671)
    How did this Chinese company acquire the site and domain? The article does not address that question. No open-source operation is safe to use, if some outside party can take simply take it over.
    • by Seven Spirals ( 4924941 ) on Friday July 05, 2024 @02:44PM (#64603713)
      Well, given what we saw recently with the attempted backdoor in libxz, it isn't too hard. This person or "entity" that pulled off this rather sophisticated hack just joined a (seemingly unrelated to OpenSSH or System==D) open source project (XZ compression) and very nearly got away with backdooring everyone running OpenSSH. With something like System===D, there is so much linkage and so many tangential libraries and projects it uses or touches that I'd think it'd be pretty much impossible to police them all. If you think AI code auditing would help, take a look at the details of the XZ hack. The backdoor was actually deep in a binary regression testing file. I haven't seen yet if anyone has fully decoded WTF it did or where it came from. The only reason it was caught was because of someone who noticed the performance of the Secure Shell daemon had become much worse all the sudden and ran down why before the hack was mass distributed.

      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.
  • by XanC ( 644172 ) on Friday July 05, 2024 @02:34PM (#64603683)

    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.

  • by Fly Swatter ( 30498 ) on Friday July 05, 2024 @02:53PM (#64603733) Homepage
    Should not be an Intertwined spaghetti mess, but here we are and we kind of deserve what we get.

    Third party scripting shouldn't even be a thing allowed in the browser. .
    • 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..

  • Just remember that our url system is highly fragile, and given enough money any domain can be bought or hijacked. It's only a matter of time before cybercrooks starting hacking the dns root servers directly and start mass replacing site requests. And any crypto used to try and stop it will be threatened by nation state actors with undisclosed CVEs.
  • by xack ( 5304745 ) on Friday July 05, 2024 @03:38PM (#64603849)
    With more and more developers relying on snap and flatpak, it becomes a juicy target to hijack. Another vector is the Chrome update servers, it will only take one rogue Google employee to backdoor billions of users. Fake browser updates are already a thing, putting an attack in the real updater will be too big a target to ignore. With a lot of people who hate Google's monopoly, someone will try and attack it soon.
  • by manu0601 ( 2221348 ) on Friday July 05, 2024 @05:37PM (#64604045)

    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.

    • Hosting yourself doesn't prevent. It's then on you to audit what you're hosting.
      • by Entrope ( 68843 )

        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).

    • ... let third-parties track your visitors, or even attack them.

      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

    • 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

Wherever you go...There you are. - Buckaroo Banzai

Working...