By now, you’ve likely seen the LinkedIn posts, the media stories, and even some formerly-known-as “Tweets”: The latest exploit to hit front pages is the malicious use of polyfill.io, a popular library used to power a large number of web browsers. As per usual, there’s a ton of speculation about what’s happening. Is this the next Magecart? Who’s behind the attack, the company that bought polyfill.io earlier this year? Someone trying to make a statement against the company or others like it? A threat actor just having fun, trying to promote betting and pornography?

The recent polyfill.io supply chain attack highlights a critical issue with current-day web development: the trust placed in third-party libraries and organizations’ inability to track the longtail of the software supply chain. According to an article by The Hacker News, the original creator of the polyfill.io library has said Website owners should immediately remove polyfil.io and cautioned that, “no website today requires any of the polyfills in the polyfill[.]io library” and that “most features added to the web platform are quickly adopted by all major browsers, with some exceptions that generally can’t be polyfilled anyway, like Web Serial and Web Bluetooth.”

Updated incident overview

The attack was first reported widely on Tuesday, June 25, 2024. After media outlets started reporting on the issue, a Tweet, allegedly from the owners of polyfill.io, claimed the service had been “defamed.”

Despite the service’s claim, and assertions of no existing supply chain risks, the credibility of these statements has been severely undermined by consistent findings from security researchers. Notably, cloud security experts from Cloudflare highlighted unauthorized use of their name and logo by polyfill.io, adding to the mistrust. 

In a startling development, the attackers behind the exploit relaunched the JavaScript CDN service on a new domain after their original site was shut down by the DNS registrar, Namecheap, due to its involvement in distributing malicious code to an estimated 110,000+ websites. All of this comes on the tail of an acquisition of polyfill.io by a Chinese company named “Funnull. 

Do I still need to care?

• What happened: On June 26, 2024, media outlets started reporting that more than 110,000 websites were estimated to be compromised, exposing a significant portion of the internet to potential redirection attacks. 
• Impacts: The injected code reportedly redirected users to unwanted websites, potentially leading to follow-on attack tactics by the threat actors in an attempt to cause even more widespread damage. At this time, no additional attacks originating with polyfill.io have been reported publicly. 
• Current state: As of June 27, 2024, the domain hosting company, Namecheap, removed the impacted domain, theoretically removing any risk of further compromise. However, rumblings on X (formerly Twitter) claim that new domains using polyfill.io have been recently registered. By whom? Funull? Attackers not associated with Funnull? Is the threat still looming? Is this a nation-state threat campaign?

What you should do:

• Stay informed: AppSec teams need to stay updated on the latest security threats and vulnerabilities impacting third-party libraries. This can involve subscribing to security advisories, following reputable security researchers, and attending industry conferences.
• Proactive defense: Implement robust AppSec practices throughout the development lifecycle. This includes secure coding practices, code reviews, and vulnerability scanning to identify and address security issues within your codebase before deployment.
• Mitigate the attack: For websites affected by the polyfill.io attack, immediate action is required. Google has taken steps to block ads for e-commerce sites that use the polyfill.io service, and it is recommended that any organization using pollyfill.io remove the compromised library and replace it with a secure alternative. 
• Layer additional security controls: Implement further security measures to help prevent malicious redirects and protect user data.

AppSec lessons learned:

Even though the threat appears to be removed from the equation, presumably preventing propagation of attacks, the incident highlights concerning trends in AppSec. In the case of polyfill.io, not a lot of damage was (as of yet) done. And, let’s be honest — redirecting users to unsavory sites is more of a nuisance than anything. But, just for a moment, let’s suppose that, instead of sending users to sites where they don’t want to be, those sites had additional malware that could scrape users’ data, infect their hardware, or install keyloggers. Remember Magecart, the infamous payment card skimming campaign that affected countless websites (and is believed by some to be dormant, not dead)? Polyfill.io has that kind of potential.

This type of attack could be the launch pad for other malicious actions, and thus companies must always pay keen attention to:

• Third-Party library risks: This attack reinforces the importance of understanding all components — including third-party libraries — used within and throughout the software supply chain. AppSec teams should:
  • Implement a process and tools that provide full visibility into all software deployed and used in your organization’s ecosystem. Importantly, “What I have” is only the first step; to adequately manage cybersecurity and business risk, AppSec teams must have visibility into the security state of software and applications.
  • Generate a Software Bill of Materials (SBOM). Doing so will provide an accurate inventory of all components used in an application, making it easier for security and development teams to target high-priority vulnerabilities.
  • Regularly assess the security posture of third-party libraries, including their vulnerability management practices, reputation, and transitive dependencies.
• Continuous monitoring: Monitor for new vulnerabilities and establish strong triage capabilities, using automation (where possible) to remediate imminent threats. Consider integrating findings from multiple AppSec tools to get a single point of view of your software security supply chain and application attack surface.
• Prioritization: Not all vulnerabilities can be the highest priority — AppSec teams are too overloaded to deal with the volume of vulnerabilities in their supply chain already. AppSec teams must have reliable mechanisms that help prioritize the most potentially impactful software and threats in their ecosystem. This is why understanding the context of the threat as well as the business context is crucial to the prioritization process. 

The polyfill.io supply chain attack serves as a stark reminder of the evolving application attack surface. Despite the seemingly short-lived nature of this particular exploit, the lesson learned (or reinforced) is that supply chains are an easy way for threat actors to commit wide-scale damage. 

It’s therefore imperative for organizations to understand how and why these types of attacks can evolve, and put measures in place to continuously find the weak spots. By implementing a strong AppSec program that includes visibility into the organization’s entire software estate, continuous testing and monitoring, and an automated triage process, AppSec teams can significantly reduce their risk of compromise.

Want to learn more about this or other software supply chain attacks, request a demo and we will connect you with one of our experts.

The post Third-Party Trust Issues: AppSec Learns from Polyfill appeared first on OX Security.

*** This is a Security Bloggers Network syndicated blog from OX Security authored by Katie Teitler-Santullo. Read the original post at: https://www.ox.security/appsec-learns-from-polyfill/