Polyfill Supply Chain Attack Impacting Millions of Websites

Polyfill - Another day, another supply chain attack

TL;DR

A Chinese company acquired the “polyfill.io” domain and began serving malicious JavaScript. Initial impact was estimated at around 100,000 websites, however later research increased this estimate to potentially 3.4% of all websites as more compromised domains were discovered. If you’re website is using polyfill, you can switch to using the version hosted by Cloudflare which is safe.

FAQ

What is polyfill?

A polyfill is JavaScript code that is mainly used to add modern JavaScript features to older browsers. Since most current browsers are now based on Google’s V8 engine or Apple’s WebKit, there shouldn’t be a need to do it anymore.

How did the supply chain attack happen?

The polyfill.io (initially, a few others were discovered later mentioned below) website is used like a CDN, allowing all visitors to use a common source of truth for their code, as well as offload some of the network traffic. This domain was purchased in February this year by a Chinese company. The domain started serving script altered to deliver malicious code to the clients using it, thus engaging in a supply chain attack.

What does supply chain attack actually do?

The malicious JavaScript is heavily obfuscated so it’s not 100% clear what capabilities it has. In a specific instance observed by a security company (Sansec), the code redirects users to malicious websites (in this case, a fake sports betting website via a fake Google Analytics domain - googie-anaiytics.com).

The polyfill code is generated dynamically based on the content of the HTTP headers. The attack only activates on specific mobile devices at certain hours and avoids running for admin users as well as real analytics so it’s difficult to understand what is does exactly.

What are the domains affected by the polyfill supply chain vulnerability?

According to Google and Sansec, the following domains were used by the actor to serve malware:

• polyfill.io
• bootcss.com
• bootcdn.net
• staticfile.org
• staticfile.net
• unionadjs.com
• xhsbpza.com
• union.macoms.la
• newcrbpc.com
• googie-anaiytics (used as target for a redirect)

How to mitigate the polyfill issue?

• If you were using any of the affected domains to pull code, you should immediately switch to a safe version like the one hosted by Cloudflare.
• Cloudflare automatically rewrites URLs for websites using its free service, thus pointing them to a safe version. Paid customers have to opt-in.
• Google notifies advertisers about the supply chain attack and warns them that their page includes malicious code.

Supply chain attacks are here to stay

This is hands down one of the most intriguing supply chain attack that happened recently, along with the XZ Backdoor attempt and a few other notable ones.

Defamation claims

In an ironic turn of events, the owners of polyfill.io said on X (Twitter) that they were defamed by all the “media messages slandering Polyfill”. Furthermore, they claim that there is no supply chain risk (“all our services are cached in Cloudflare and there is no supply chain risk”).

Despite their claims of being safe for use, findings discovered by security researchers indicate otherwise.

Interestingly the polyfill.io domain wasn’t owned by the polyfill developer before it was acquired by the Chinese company. In fact, he actually warned everyone in a February post (around the time the domain changed owners) on social media that all websites should remove the package immediately (link).

Unauthorized use of Cloudflare’s name

Besides the mitigation aspect, Cloudflare was not happy that the polyfill.io domain was using their name in a bid to gain customer trust using a top side banner saying “Cloudflare Security Protection”. Cloudflare stated they never authorized the use of their name to polyfill and that this is “yet another warning” that polyfill can’t be trusted.

Discovering the extent of the supply chain attack

Initially, the security community was only aware of the polyfill.io domain. But this soon changed after some smart individuals did some good, old-fashioned OSINT work.

Security researchers discovered a GitHub repository called “data.polyfill.com” that contained the back-end source code for the domain. Digging further, it seems that one of the developers uploaded an .env file to the public repo. As you might well know, the .env file contains environment variables and you can usually find lots of juicy stuff in there, including API keys or other secrets. Why use a secure secrets manager when a file is easier? Kidding, you should always use something like AWS KMS or HashiCorp, and this discovery proves why.

Turns out that the file contained a Cloudflare API key among other things. One of the researchers used the token to retrieve a list of active zones associated with the Cloudflare account. While combing through the results, the “cdn.polyfill.io” domain popped up, confirming that this Cloudflare account is used to manage the polyfill.io domain. Further reading showed other domains, including staticfile.net, bootcdn.net and bootcss.com indicating that the actor the single owner of all these domains.

The impact of all these domains might well be in the tens of millions of websites.

When did the attack start?

Another researcher discovered that this code has been circulating since June 2023. The polyfill malicious code contained a function called “check_tiaozhuan”. When cross referencing this with online resources, he discovered on Chinese forums that an older version of the injected code was delivered via BootCSS since the aforementioned date. The developers on those forums were trying to understand what the obfuscated code did.

The future of open-source software

All of these findings indicate a very long and carefully planned campaign by a patient and capable operator. Is the company behind this? Were they compromised by some threat actor? We might never know. Considering the recent XZ backdoor, is there anything we can do to avoid these type of events? Probably not.

So in a world where code reuse and CDNs are the norm, how can we mitigate supply chain attacks? Software Bill of Materials can help with vetting the open source packages we use and making sure malicious code wasn’t introduced.

We can’t renounce open-source software, there aren’t enough developers to handle all these packages and the ones that are doing it, they aren’t compensated enough for their efforts. Lately, some also complain about a recent wave of junior security researchers that submit issues just to get a CVE for the sake of having it on their resume. Issues that might not have any security impact or a lot less than claimed initially. Those are definely not a majority, but it adds work to the open-source maintainer who gives up his free time to help the community.

Can we trust CDN providers? I guess we have to. We can’t host everything ourselves due to cost, speed and who knows what other reasons. At best, we can aim to use some of the more reputable CDN providers like Cloudflare or Fastly.