Polyfill Supply Chain Attack Highlights Risks of Third-party Code in Modern Web Applications

The recent discovery of a website supply chain attack has left many websites vulnerable to malicious code injection.
supply chain

The recent discovery of a website supply chain attack using the cdn.polyfill[.]io domain has left many websites vulnerable to malicious code injection. Once a trusted resource for adding JavaScript polyfills to websites, the domain has recently become the epicenter of a significant website supply chain attack.

How the Attack Unfolded

Funnull, a Chinese company, acquired the domain Polyfill[.]io. Following the acquisition of the domain, Funnull began inserting malicious code into scripts served to end-users. So far, over 100,000 sites have been impacted. When developers included the cdn.polyfill[.]io scripts in their websites, the code was fetched directly from the site owned by Funnull.

This code dynamically generates payloads based on HTTP headers, specifically targeting mobile devices, evading detection, avoiding admin users, and delaying execution. The malicious scripts often include a fake Google Analytics link, redirecting users to various inappropriate, scam, or phishing websites, which could lead to data theft.

The malicious domains used advanced evasion tactics, including protections against reverse engineering, activating only on specific mobile devices at certain times, and avoiding execution when admin users or web analytics services are detected.

The Polyfill[.[io] incident highlights the risks of third-party code in modern web applications. On average, applications load 209 client-side resources at any time. Retail organizations’ applications load an average of nearly 400 client-side resources – 90% higher than the average across all organizations. Travel organizations have nearly 300 client-side resources loading in their applications, which is 39% more than the average across all organizations.

Most Compromised Web Resources

As a fundamental building block of modern web applications, JavaScript is the most common resource that can become compromised and exploited. These injections can originate from server-side compromise, supply chain attacks, or methods like stored Cross-Site Scripting (XSS).The reason for this is that it is an extremely flexible tool that can easily be manipulated in numerous ways to benefit bad actors, making it an ideal vector for abuse.

Once exploited, the impact can be disastrous. Malicious scripts, such as Magecart or stealer scripts from remote sources, can be introduced, leading to the theft of users’ sensitive data at a large scale. Other consequences include web content manipulation and user browser control leading to unauthorized user session access, redirects to malicious sites, malware distribution, or advertisement replacement.

On average, modern web applications load 23 scripts on end users’ browsers. Of those, an average of 66% are third-party scripts, increasing the risk of a compromise being introduced through the software supply chain. Retail organizations have a higher risk exposure with 36 scripts loaded on average, 76% of which are third-party scripts. Likewise, travel organizations face greater exposure with 27 scripts loaded on average, 75% of which are third-party scripts.

While JavaScript resources are most frequently compromised, the “data” or “data transfer” function in web applications can also be compromised. Data functions facilitate the exchange of information between the user’s browser and a remote server. Malicious actors can exploit this function to exfiltrate data to unauthorized domains, leading to significant data breaches. As such, it’s essential to implement strict security measures and monitor data transfer CSP reports. These reports can alert administrators to suspicious connection attempts, aiding in the early detection and prevention of potential breaches.

On average, retail websites load 40 data or data transfer resources, with 68% of the resources coming from third parties. Travel organizations load 51 data resources, 54% of which come from third parties.

The frame function in web applications involves the use of HTML frames or iframes to display content from external sources within a webpage. While frames are useful for embedding content from different origins, they can be exploited to launch client-side attacks. For example, attackers can create malicious iframes that load content from vulnerable sources, leading to attacks like clickjacking, where users unknowingly interact with hidden elements that perform unintended actions. Moreover, iframes can be manipulated to enable Cross-Site Scripting (XSS) attacks that compromise user data, sessions, or the integrity of the web application.

On average, retail websites load 68 frame resources, 61% of which are from third parties. Travel organizations load 47 frame resources, 70% of which are from third parties. The exposure to third parties in both cases is well above the averages across all industries, putting retail and travel organizations at greater risk of attacks through this vector.

Visibility to Protect Third-Party Services

Avoiding a Polyfill[.]io incident requires continuous monitoring and inventorying of all services on the client-side with alerts when a newly added service is detected.

Additionally, it should provide visibility into scripts brought in through the software supply chain, to help security teams validate if any inherited scripts that have access to their web applications are maliciously skimming data. This level of visibility eliminates any blind spots and helps organizations identify potential vulnerabilities, reducing the risk of third-party services becoming an attack vector.

More Recent Blog Posts