When we and news outlets reported the Polyfill attack, the reactions were surprisingly mild. This may have been due to the visible result: a simple redirect to obscure websites.
But, as we outlined in our post-mortem, the potential consequences are far more severe:
“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.”
The fact is, much more likely happened.
New insight in the domain transfer
The domain hosting the script was sold to a Chinese company called Funnul. Approximately six weeks later, the redirects began, and the incident was recognized as an attack.
Recently, an undisclosed source revealed that the domain polyfill[.]io—at the center of the attack—was sold for a "life-changing sum of money."
The Polyfill script was originally created by Andrew Betts and Jake Champion. Andrew Betts posted a (now-deleted) tweet acknowledging the sale and admitting he had no influence over it.
Another X user, John Schulz, uncovered a now-removed announcement from Funnul naming Jake Champion as the individual who transferred the domain to them:
Took me a bit to find it, but here's the announcement pic.twitter.com/9sdSboOu7l
— John Schulz (@JFSIII) February 24, 2024
A now-deleted tweet by Jake Champion confirms that he personally transferred the domain to Funnul.
Possible doomsday scenarios
The attack was exposed because users were redirected to adult and betting sites. However, if the domain was sold for a "life-changing sum," it seems unlikely that it was used solely for such a basic exploit.
For weeks, this attack affected half a million websites, including Intuit, The Guardian, Hulu, and The Verge.
Here are some potential doomsday scenarios that could have been executed by taking control of a single third-party JavaScript file.
DDos attack
Attackers can siphon IP addresses from visitors across half a million websites and leverage their machines to send requests to any target, creating one of the largest DDoS attacks ever. This can disrupt major institutions, both private and governmental, for hours.
Workday attack
Attackers can trick employees into sharing their Workday credentials, granting unauthorized access to backend systems or simply exfiltrate their session token. This can result in:
- Payroll manipulation
- Theft of employee records
- Access to sensitive HR data
- … and more
Rewrite any content on a webpage
On infected news sites, attackers can rewrite content to:
- Provoking reactions or panic
- Manipulating public opinion
- Changing narratives on controversial subjects
- … and more
Capturing PII and Credit Card details
Client-side attacks often harvest Personally Identifiable Information (PII) and payment details. With over half a million affected websites, including many with checkout forms, attackers can steal payment data en masse.
Infecting other websites
An infected site can host malicious scripts, allowing the attack to spread. This tactic complicates detection and containment efforts. This technique is commonly used in client-side breaches, as seen in the Schrwaa[.].com (safe link to an article).
Mining crypto in the browser
Cryptojacking—forcing users' browsers to mine cryptocurrency—is a well-documented tactic. If executed on half a million high-traffic websites, attackers can profit immensely from millions of daily visitors. Read up on the BrowseAloud and the Copay event-stream attacks to see recent examples.
An and scenario
It’s crucial to stress that these scenarios are not isolated—they can occur simultaneously. The redirects already happened, but the other scenarios may have been active as well.
Without client-side monitoring, it’s impossible to know.
This uncertainty is why we started c/side. While we can’t see every attack globally, we monitor third-party scripts on your site to detect and prevent attacks like this from harming your users.
Let’s hope the redirect was the worst of it. But the fact that much worse could have happened is reason enough to act. Protect your site in seconds, for free, by signing up for c/side today.