When Hackers Take Advantage of Your Trusted Vendors

As JavaScript-based client-side attacks continue to evolve, we see how attackers are getting more sophisticated and employing more advanced techniques. Unfortunately, it has been proven many times that any website partner can be exploited to carry out an attack. Recently one of the most popular and trusted vendors was used as a credit card data exfiltration vector: Google Analytics.

Given the trends, we on the Akamai Client-Side Protection & Compliance team believe that the right approach to mitigate such threats is to treat all scripts in the page equally, not trusting a script based on its vendor. This is part of our philosophy from the beginning, when we analyzed the threat landscape.

Exploiting Google Analytics

One of the samples found in the wild lately, and first published by Kaspersky, shows how a Magecart group managed to use a rather simple -- but potentially business-lethal -- Content Security Policy (CSP) bypass method. Of course it doesn't bypass the CSP engine itself, but it actually uses a logical exploit that works under certain circumstances. In the latest finding, attackers could generally exfiltrate any data they wanted from any site that allows Google Analytics in its CSP rules.

This attack vector is no surprise to us. In some of our earlier research (which dates back to 2018), we discovered that Google Analytics allows this behavior, and we've created proof-of-concept (PoC) attacks that leverage that capability. Back then, we had not yet seen nor heard about the Google Analytics vector actually being exploited by attackers, but it was clear to us that the solution we build should address this potential scenario.

Exposing a potential exfiltration vector

Since the vast majority of websites use analytics to track and optimize their traffic, and Google Analytics is one of the leaders in this category, most sites that use CSP and analytics will have “google-analytics.com” in their CSP allowlist. This automatically makes Google Analytics a great exfiltration vector.

Effective client-side attacks require several steps:

1. Gaining access to end-user browsers

2. Reaching sensitive end-user data

3. An effective implementation

I am going to focus on the third step and how Google Analytics could be used as an exfiltration vector. Therefore, the information below is only a small part of an attack methodology.

By default, the Google Analytics script sends beacons with analytic information, which are aggregated and displayed in the Google Analytics dashboard. These beacons are naturally sent upon navigation in the website. Further, Google also provides the ability to send custom values and beacons on custom events, triggered by a few simple lines of code.

That said, attackers don't even need to leverage the more advanced capabilities of Google Analytics to send custom values, and can just simulate a simple beacon with modified parameters.

In this blog, I will discuss the simple way. For example, let's take a look at the Google Analytics tracking code:

When embedded in any website, the legitimate beacon request sent by the Google Analytics snippet looks like this:

This beacon includes two important parts that the attacker can simply modify to turn Google Analytics into an exfiltration framework:

1. Source URL | http%3A%2F%2Fmylegitsite.com%2Fga_test.html
   Tells Google Analytics the URL of the page from which the beacon was triggered, similar to the referrer header. Google Analytics displays this in the dashboard.

2. Tracking ID | UA-12331643-1
   The identifier for the specific account that tells Google Analytics which tenant to associate the sent data with.

To demonstrate how this could work, I put on my data-exfiltration hat and modified the outbound beacon to look like this:

See how I changed the:

• Source URL path to include my own values, which an attacker can simply take from the victims' sensitive forms, and echo into the request. Its path is now exfil-(stolenUsername:stolenPassword).

• Tracking ID to route the beacon and stolen information to my own Google Analytics account.

Now let's see the results of this request in action: Google Analytics immediately displays the values from my request, which I can simply parse.

Transforming a PoC into practice

In this section, we will demonstrate how this attack could potentially be carried out. Please note that in this example we already assume that the malicious code successfully infiltrated the site -- not a simple task -- and the challenge is how to exfiltrate the data unsuspected.

The malicious code can be added to a site in several ways, including:

• Hijacking an existing vendor script, and adding the malicious code to it

• Sneaking malicious code to open-source projects used by the compromised site

• Taking advantage of misconfigurations (e.g., leveraging public write-permissions on s3)

• Exploiting common framework vulnerabilities (e.g., Magento RCE vulnerability)

• Domain Name System (DNS) record modification / DNS hijacking

Part 1: The target

To demonstrate the above, we chose a major website login page that makes use of CSP, to demonstrate this attack vector and show that attacks via Google Analytics can happen to any site. I have obscured any identifiable information to protect the website owners.

Here are the CSP headers that show how google-analytics.com is allowlisted:

Part 2: The attack

We wrote a small attack that implements the methodology described in the previous section of this post:

• Holds a configuration with sensitive data selectors

• Gathers the sensitive data based on that configuration

• Upon an unload event, triggers an exfiltration request -- using sendBeacon -- back to Google Analytics

Part 3: the harvested data

After triggering the attack locally (simulating a real attack) on the example site login page, we successfully received the exfiltrated data pageview beacon on the Google Analytics dashboard:

The data was received under the cover of a pageview pathname, with the prefix /exfiltrated-data: followed by the base64-encoded sensitive data.

After decoding the payload, we got the sensitive fields as follows:

Protecting your data

While CSP is a very good practice to use when managed correctly, we found that it is not a strong enough measure to tackle some types of data breaches, including the Google Analytics exfiltration vector, or more generally exfiltrating to trusted destinations.

The good news is that there is a solution, and it's called Akamai Client-Side Protection & Compliance. It doesn't use traditional allowlist/blocklist rules, nor does it trust hostnames or specific scripts.

Instead, Client-Side Protection & Compliance focuses on the script execution behavior. Through unprecedented visibility into the runtime environment, it collects information about the different scripts that run in the web page, each action they take, and their relation to other scripts in the page. Pairing this data with our multilayered detection approach -- leveraging heuristics, risk scoring, AI, and other factors -- allows Client-Side Protection & Compliance to detect different types of client-side attacks, with high focus on data exfiltration and web skimming attacks, including the Google Analytics attack.