Hackers use Google Analytics to steal credit cards, bypass CSPFrom: MasterNewsgroups:
alt.privacy, alt.anonymous, rocksolid.shared.news, alt.hackers.malicious, alt.comp.google, alt.google-sucks, comp.internet.services.google, comp.security.misc
alt.privacy, rocksolid.shared.news, comp.security.misc, comp.internet.services.google
Sat, 11 Jul 2020 20:47 UTC
View all headers
Hackers are using Google's servers and the Google Analytics platform to steal credit card information submitted by customers of online stores.
A new method to bypass Content Security Policy (CSP) using the Google Analytics API disclosed last week has already been deployed in ongoing Magecart attacks designed to scrape credit card data from several dozen e-commerce sites.
This new tactic takes advantage of the fact that e-commerce web sites using Google's web analytics service for tracking visitors are whitelisting Google Analytics domains in their CSP configuration (a security standard used to block the execution of untrusted code on web apps).
New research from web security companies Sansec and PerimeterX shows that using CSP to prevent credit card skimming attacks is pointless on sites that also deploy Google Analytics (GA) as threat actors can use it to exfiltrate harvested data to their own accounts.
Bypassing CSP using Google Analytics
On June 17, PerimeterX found and demonstrated "an easy to reproduce vulnerability in the core functionality of CSP when using it for blocking theft of credentials, PII and payment data like credit cards."
Instead of blocking injection-based attacks, allowing Google Analytics scripts benefits attackers as they can utilize them to steal data. This is done through a web skimmer script that is specifically designed to encode stolen data and deliver it to the attacker's GA dashboard in an encrypted form.
The attackers only have to use their own Tag ID owner of the UA-#######-# form as "the CSP policy can’t discriminate based on the Tag ID" for their scripts to be able to abuse GA for sending harvested info such as credentials, credit card data, and more.
"The source of the problem is that the CSP rule system isn’t granular enough," PerimeterX's VP of research and development Amir Shaked explained.
Recognizing and blocking scripts designed to abuse this flaw "requires advanced visibility solutions that can detect the access and exfiltration of sensitive user data (in this case the user’s email address and password)."
While Shaked used GA as an example of attackers using hosts whitelisted in CSP as it is the most commonly whitelisted third-party service in CSP configs, any other whitelisted domain that gets compromised or provides account-based management just as GA can be used as an exfiltration channel.
Out of the top 3 million Internet domains, only 210,000 are using CSP according to statistics from PerimeterX based on an HTTPArchive scan from March 2020. 17,000 of the websites reachable via those domains are whitelisting the google-analytics.com.
Based on stats provided by BuiltWith, over 29 million websites are currently using Google's GA web analytics services, with Baidu Analytics and Yandex Metrika also being used on more than 7 million and 2 million, respectively.
CSP bypassed on dozens of sites by Magecart actors
Sansec's Threat Research Team today disclosed that it was tracking a Magecart campaign since March 17, with the attackers abusing this exact issue to bypass CSP on several dozen e-commerce sites using Google Analytics.
The threat actors behind this campaign went a step further by making sure that all the campaign components are using Google servers, as they delivered the credit card web skimmer to their targets' sites via Google's open storage platform firebasestorage.googleapis.com.
"Typically, a digital skimmer (aka Magecart) runs on dodgy servers in tax havens, and its location reveals its nefarious intent," Sansec explained.
"But when a skimming campaign runs entirely on trusted Google servers, very few security systems will flag it as 'suspicious'. And more importantly, popular countermeasures like Content-Security-Policy (CSP) will not work when a site administrator trusts Google."
The loader the attackers use to inject their web skimmer has multiple layers of obfuscation and it is used to load an attacker-controlled GA account within a temporary iFrame.
Once loaded, the skimmer will monitor the compromised site for user input and it will grab any entered credit card information, encrypt it, and automatically deliver it to its masters' GA dashboard.
The attackers can then collect the stolen credit card data from their free Google Analytics dashboard and decrypt it using an XOR encryption key.
As Sansec also discovered, if the compromised online store's customers would open their browsers' Developer Tools, they'd get flagged and the skimmer would automatically disable.
"Everything is allowed by default. CSP was invented to limit the execution of untrusted code. But since pretty much everybody trusts Google, the model is flawed," Sansec CEO and founder Willem de Groot told BleepingComputer.
Based on these findings, CSP is far from a foolproof against injection-based web app attacks such as Magecart if attackers find a way to take advantage of an already allowed domain/service to exfiltrate information.
"A possible solution would come from adaptive URLs, adding the ID as part of the URL or subdomain to allow admins to set CSP rules that restrict data exfiltration to other accounts," Shaked concluded.
"A more granular future direction for strengthening CSP direction to consider as part of the CSP standard is XHR proxy enforcement. This will essentially create a client-side WAF that can enforce a policy on where specific data field are allowed to be transmitted."
"We were recently notified of this activity and immediately suspended the offending accounts for violating our terms of service," a Google spokesperson told BleepingComputer. "When we find unauthorized use of Google Analytics, we take action."
Update: Added Google's statement.