The introduction of EMV (Chip & Pin) payment devices in 2003 resulted in a rapid decline in physical credit card cloning in Europe. EMV technology has also led to an increase in attacks on e-commerce systems targeting cardholder data.
Each year, Trustwave SpiderLabs investigates hundreds of incidents of data compromise. I work on some of these investigations and occasionally get to evaluate some rather unusual attack vectors. This blog post details a novel data extraction technique using Google Analytics that I found during a recent investigation. We have evidence of this technique being used in the wild. For the purposes of this article, however, I have replicated the attack in a test environment.
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:
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.
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?”.
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.