Safeguarding Against Supply Chain Attacks: A Customer’s Tale of Defacement and Response. Part 1
The Situation
Picture this: the Radware Emergency Response (ERT) team recently found themselves on high alert when a valued customer using Radware Security Cloud reached out in a panic. This customer, deeply committed to keeping their online retail platform safe, shared the usual concerns of retailers everywhere: safeguarding user accounts, stopping website scraping, and preventing Denial of Inventory headaches. What set them apart was their fascination with L7 (Layer 7) security intricacies and their eagerness to understand every nook and cranny of online defense.
“I think my website might be under attack. I have taken it offline and put up a maintenance page. Can you help? I cannot find any evidence of an attack in my logs or Radware security events,” they told us urgently.
In collaboration with the customer, the Radware Emergency Response Team (ERT) took swift action. An immediate validation process was conducted, revealing that the website is well-protected. The Radware team quickly checked all the usual suspects:
Origin Access: Ensured that only Radware Cloud is permitted to send traffic directly to the origin, with no backdoor that could bypass the comprehensive security measures.
DNS Records: Confirmed that the website URL directs to Radware Cloud Security CNAME, reinforcing the integrity of the domain resolution.
Web Application Firewall: Utilized modules offering the highest protection levels, specifically designed to thwart attackers attempting to replace pages or inject malicious scripts that could deface the website.
Bot Manager: Implemented to block vulnerability scanners and identify malicious activities by preemptively scanning for known vulnerabilities and conducting application discovery before hackers initiate their attacks.
Early Active Attacker Feed: Employed an intelligence feed aimed at preemptively blocking access by active attackers even before the initiation of an attack, ensuring protection from the very first byte.
GEO Blocking: Although not mandatory, a commonly used measure to mitigate risks involves blocking access from geographical locations that are not relevant to the business, reducing the attack surface.
Source Blocking: Implemented a real-time AI module that calculates attack activity per source against the website, allowing for immediate blocking of sources based on predefined tolerance definitions.
Every protection module was activated and configured in Blocking mode, yet there is no apparent evidence of website defacement. Notably, there have been no hacking attempts detected within the last 24 hours that could provide any indication of potential website defacement.
Thwarting the Attack
We requested the customer to briefly make their website accessible, allowing us to capture the infected page while collaboratively activating Client-Side Protection for the first time. The Radware team configured Client-Side Protection in monitor mode. This enabled us to actively monitor, map, and compile a list of JavaScript sources downloaded to the browser, scrutinizing the external domains the browser attempted to access. Notably, among the loaded elements was an image from a well-known website, identified by the following URL:
https://uploads.dailydot.com/9ae/7e/921fe6e8e6257f7d023ebb08b4bce1e8.jpg
The image was embedded through JavaScript utilized by the website from a recognized and trusted third-party provider. This provider typically loads Web Accessibility Plugins into the protected website. This type of Defacement attack is categorized as a “Supply Chain Attack.” The hacker is aware that the targeted website is well-protected. Consequently, hackers identify vulnerabilities in third-party providers and manipulate their content. In some instances, hackers may even extend their attack to the service providers of these third-party providers by manipulating the source, a scenario referred to as a “4th parity supply chain.”
Here is how it played out: (website names and identifying information have been altered):
Step 1: The third-party JavaScript hosted on fecdn.MyTrustedPartner.info was compromised and manipulated by hackers to display political text with an embedded link leading to an image (from uploads.dailydot.com).
Step 2: The targeted website (victim.co.il) fetched the JavaScript named “LoaderMain” from the third-party site (fecdn.MyTrustedPartner.info) for accessibility services.
Step 3: On the client side (Customer Browser), upon receiving this script, it was rendered, presenting the text, and initiating the download of the embedded image.
Here, you can observe the third-party scripts and images that were downloaded to the browser, along with the initiator for each link.
- LoaderMain domain: fecdn.MyTrustedPartner.info
- Image from domain: uploads.dailydot.com, initiated from fecdn.MyTrustedPartner.
Immediate Activation of Client-Side Protection
In response to the threat, Radware ERT and our customer swiftly made the decision to switch Client-Side Protection to Blocking mode directly in the production environment. The protective measures included blocking access to the domains of the third parties involved:
- fecdn.MyTrustedPartner.info
- Uploads.dailydot.com
Additionally, an immediate workaround was implemented to restore the website’s functionality without any defacement visibility. With this setting, the client-side (customer browser) would be unable to render the malicious script until the website developers removed it from the code entirely. The customer also took steps to contact their partner, ensuring the issue was addressed promptly and preventive measures were in place to avoid a recurrence.
Here is how it played out:
After sharing the details and evidence with our customer, we extended our investigation to the third-party service. Our inquiry revealed that the customer’s website, primarily providing JavaScript to the service, lacked proper protection, and there was a deficiency in visibility and control over their in-house code.
The “Trusted Partner” was found to rely on third-party and open-source code to maintain their service. Surprisingly, they were unaware of how their service got infected. This realization showed that serving other websites with JavaScript data alone does not negate the need for Website Application and API Protection (WAAP) on their assets. In fact, it posed a risk to their customers.
But the story does not end here
After sharing the evidence with our customer, we investigated the third-party service further. It turned out their website, which primarily provided JavaScript to the service, lacked proper protection and oversight over their code. This blind trust in third-party providers posed a significant risk to their customers.
Stay tuned for Part 2 of this saga, where we will dive deeper into the aftermath of the incident and explore client-side security measures to prevent such attacks. The journey to fortify defenses and stay ahead in the ever-evolving cyber threat landscape continues.
The second part will focus on “How to stay protected?” and provide recommendations for client-side security measures.
