Hot Topics

Cloud Security Security Bloggers Network

Home » Cybersecurity » Cloud Security » When Hackers Take Advantage of Your Trusted Vendors

When Hackers Take Advantage of Your Trusted Vendors

by Ziv Eli on September 11, 2020

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. In the past month, we witnessed one of the most popular and trusted vendors being used as a credit card data exfiltration vector — Google Analytics.

Due to such trends, we on the Akamai Page Integrity Manager team believe that the right approach to mitigate such threats is to treat all scripts in the page equally and not to trust a script based on its vendor. This has been part of our philosophy from the get-go, when we analyzed the threat landscape.

Google Analytics as the C2 server

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 — 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 is an amazing finding to us, since 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 being used by attackers in the wild, but it was clear to us that the solution we build should address it.

Bypassing CSP, while playing by the rules

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.

Sponsorships Available

Breaking down the attack

Effective client-side attacks require several steps:

Gaining access to end-user browsers
Getting access to sensitive end-user data
An effective implementation

I am going to focus on #3 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 send 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.

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:

Source URL | http%3A%2F%2Fmylegitsite.com%2Fga_test.html
This 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.
Tracking ID | UA-12331643-1
This is the identifier for the specific account, and tells Google Analytics which tenant to associate the sent data with.

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

See how I changed both 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.

Converting this small PoC into an attack

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)
DNS record modification / DNS hijacking

Part 1: The Target

To demonstrate the above, we wanted to choose 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 config with sensitive data selectors
Gathers the sensitive data based on that configuration
Upon an unload event, triggers an exfil 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:

“Great, now what can I do about it?”

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 Page Integrity Manager. It doesn’t use traditional allowlist/blocklist rules, nor does it trust hostnames or specific scripts.

Instead, Page Integrity Manager 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 Page Integrity Manager to detect different types of client-side attacks, with high focus on data exfiltration and web skimming attacks, including the Google Analytics attack.