Linkedin Tag

Back to blog

The Polyfill attack explained

Wednesday, July 3rd, 2024

Simon Wijckmans's profile picture

Simon Wijckmans

Recently over 490,000 websites were targeted in a web supply chain attack. We were amongst the first to report on this.

NOTE: If a website is referencing the domains polyfill[.]io bootcdn[.]net, bootcss[.]com, staticfile[.]net, staticfile[.]org and unionadjs[.]com today, they are still open to this attack.

What was the Polyfill service project?

Polyfill was originally an open-source project allowing websites to use modern JavaScript features in older browsers like Internet Explorer. This was necessary when the online community gradually moved to more modern browser frameworks.

Despite being largely unnecessary as the amount of Internet Explorer traffic became negligible, thousands of websites still reference this domain.

Created in October 2014, Polyfill received regular updates. In February 2024, contributor Andrew Betts (@triblondon on X) warned the community when the domain polyfill[.]io was acquired by a chinese company from its original owners:

 

How Polyfill[.]io facilitated a web supply chain attack

Domains used to serve popular third-party scripts are a big security concern since they can dynamically change without notifying anyone or anything. This includes serving totally different scripts based on your browser, User-Agent, geo location, IP or any other vector. They have free reign in what they serve to who, on what basis. 

Polyfill[.]io and Polyfill[.]com were purchased by a Chinese company called Funnull.

After this sale and Andrew’s X post, Github contributor “renchap” provides some extra context regarding the transaction:

“Polyfill[.i]o was owned by the Financial Times web team, then moved under community management, and the last maintainer sold the project to a weird Chinese CDN company, and they moved it away from Fastly (the CDN / Edge compute platform running the OSS code for the service) and started to mess with the returned files.”

GitHub contributor “munierujp” mentioned that Jake Champion decided to transfer Polyfill’s ownership to Funnull:

GitHubUserMunierujpScreenshot-cside.dev.webp

The link he references has since gone down. There also isn’t an Internet Archive page available.

Andrew Betts and Jake Champion, both formerly of the Financial Times and original owners of Polyfill, now work at Fastly.

Other community members on this Github thread mention that:

“Funnull is notorious for providing service for the betting and pornography industries”

Which was a preface to what actually happened following the attack.

Previous to all of this Polyfill ran on Fastly’s edge compute platform. Since this is not available on the Chinese cloud, “renchap” on Github noticed that polyfill[.]io now had a CNAME record to polyfill[.]io.bsclink[.]cn.

Following the suspicious change of ownership Fastly set up a mirror of the Polyfill library as an alternative domain to help people continue using the service, polyfill-fastly.io. They provided this mere days after the sale was communicated.

A day after the Fastly announcement, Cloudflare launched an alternative endpoint for Polyfill[.]io on cdnjs to mitigate the risk of an attack.

This is not a 100% perfect solution. The 2021 cndnjs vulnerabilities showed the world that even large reputable JavaScript CDNs can suffer from supply chain risk. This goes to show that one can not just trust sources. Instead, continuous monitoring should be used to detect anomalies. This is part of why c/side was founded.

 

What happened in the Polyfill attack?

A tampered JavaScript file injected by the polyfill[.]io domain redirected a percentage of users to adult and betting websites based on their User-Agent. A Japanese X user “piyokango” was likely the first to report his attack on the 24th of June.

On the 25th of June, “Huli” was able to reproduce this attack and report it in English. He came across a Github post of the day prior, where a user named “alitonium” explains how he discovered it.

After meeting certain conditions, the altered JavaScript file reveals itself. After decoding, it shows a fake Google Analytics link googie-anaiytics[.]com/gtags.js. Notice how this domain is a typosquatting one. An i (India) is used instead of an l (Lima).

This typosquatted domain redirects users to various sports betting and adult websites, seemingly based on their region. This is one of the websites that we were redirected to:

ScreenshotOfASiteWeWereRedirectedTo-cside.dev.webp

While this web supply chain attack at this time only redirected users, a multitude of things could’ve happened. From watering hole attacks to capturing credit card details. A watering hole attack is a type where hackers target a website that a specific group of people often visit. They infect the site with malware so that when the group's members visit the site, their computers get infected.

Because most common security measures rely solely on checking sources, attacks like this are still happening today. As this particular example showed, threat feed vendors did not list the polyfill[.]io domain as malicious until days after the reports. This is operating from an experience first, react later approach which fundamentally allows attacks like this to keep happening.

undefined

C/side was founded specifically to challenge the reliance on thread feeds, as the pace of new creative attack methods is higher than the speed at which threat feeds process them. This became clear recently with the National Vulnerability Database (NVD) crisis, where over 10000 known attacks were waiting in a backlog to be reviewed and processed into Common Vulnerabilities and Exposures (CVEs).

In the example of Polyfill, our engine was able to detect the injected polyfills and stopped it from happening. It safeguarded the user and alerted the website owner of the malicious code.

As “Huli” from the mentioned blog above posted about the change of behaviour, we started to write our own report which went live shortly after. We first reported that about 110,000 websites were affected. We later corrected this to the current estimation which is over 490,000 websites.

Revealing impacted prominent brands like the Disney-owned streaming service Hulu, The Guardian, Intuit, and many more.

We noticed that the Polyfill[.]io website added a ‘Cloudflare Security Protection’ header to their homepage between March 7th and 8th. It struck us, and others in the community, as strange at the time. A day after our report Cloudflare confirmed they didn’t authorize its use.

PolyfillWebsiteOnInternetArchive-cside.dev.webp

We also observed the malicious redirection happening only once for an IP. This was likely designed to circumvent detection as long as possible.

 

The aftermath

The domain Polyfill[.]io was purchased through Namecheap. During the commotion, Namecheap shutdown the domain as reported by MalwareHunterTeam on X:

The site then went up again on Polyfill[.]com, but has since also been shut down.

Google also responded. They stopped serving ads to websites with the scripts on them and put pressure on site owners by taking away their ad revenue in order to remove the scripts. Google also sent out warnings which mentioned a few other domains, as noticed by Michal Špaček on X:

Which brings us back to MalwareHunterTeam who did some more digging. They mentioned that all these domains are managed by the same group. This was confirmed when a Cloudflare API token and ZoneID were leaked on GitHub.

These domains included Polyfill[.]io but also bootcdn[.]net, bootcss[.]com, polyfill[.]io, staticfile[.]net, staticfile[.]org and unionadjs[.]com.

Additionally, they found evidence of malicious code being served through these domains. Affecting hundreds of thousands of websites​.

These domains were also not listed as malicious by threat feed vendors. Even though some of these domains have been serving supply chain attacks since June of 2023. That’s over one year of undetected attacks.

C/side was not around to detect those at the time.

In an attempt to save face, an X account with the name Polyfill started accusing Cloudflare, the media, and others of defamation. The account was created in February 2024, likely around the time the domain sale happened.

On June 30th, the bad actor attempted to put their site live again on polyfill[.]site. It has been taken down since. 

On July 1st, they came out and put up their product again. This time under polyfillcache[.]com. We expect this to be taken down again soon.

 

The learnings

This attack underscores the extended risk of third-party scripts. Once embedded on thousands of websites, they become prime targets for malicious actors. With a few lines of code, these websites and millions of visitors are at risk. This a sensitive area of the web supply chain, yet tools to monitor the attack surface are lagging behind and are scarely used.

C/side was created to stop this from happening. Our script, which loads first, forces all the others through our proxy. There, we check the full code for anything malicious based on over 60 parameters. If our detection engine decides it’s not safe, the script is blocked from loading. We also optimize these scripts to combat any latency created by the proxy, in many cases making them faster rather than slower.

The Polyfill attack serves as a reminder: security measures that don’t check the full code before serving it to users will fail to detect new attacks and rely on detections through the community, putting websites and visitors at risk.

Here the bad actor opted to only redirect users to adult and betting websites, however much worse could have happened. Listening in on keystrokes in a small percentage of sessions based on geolocation and time of the day, injecting malware, mining cryptocurrency or rewriting buttons on sites to redirect to impersonated payment portals. From just a simple redirect to capturing credit card details, client-side JavaScript attacks can do it all. The Polyfill attack could have had much more negative impact, in a way we got lucky. Let this be the reminder, we must monitor our client-side scripts.

You can secure your site in seconds using c/side. Our free tier protects your site against this and similar attacks.