Hackers used Google Analytics to steal credit card details via infected e-commerce sites
Google servers and functions of the Google Analytics platform got misused by hackers to steal information submitted by customers.[1] These hackers also managed to bypass the web security. Content Security Policy with the help of Google Analytics API. This issue, in particular, was addressed last week due to ongoing Magecart attacks,[2] that deployed this API for stealing data.
This new method takes advantage of the feature that Google Analytics keeps Google domains as whitelisted in the CSP configuration.[3] This is how attackers managed to stealthily pilfer credit card details from various e-commerce sites that got infected. Threat actors injecting data-stealing code on the website, and combine that with tracking code that Google Analytics generates for their account. Payment information entered by users can get easily exfiltrated this way.[4]
Attackers injected malicious code into sites, which collected all the data entered by users and then sent it via Analytics.
Dozens of sites across Europe, South, and North America infected
This attack abuses the CSP that is a security measure added to Google web analytics services. The method should help to mitigate threats coming from cross-site scripting flaws and other forms of code injection-based cyber attacks. Webmasters can define the list of domains that could have the ability to interact with the web browser thanks to this feature. This function prevents the execution of untrusted code.
Malicious actors went further than other already known Magecart campaigns and ensured that all the components use Google servers. Several dozens of e-commerce sites using Google Analytics got abused, and these targeted sites received the credit card skimmer via open storage platform firebasestorage.googleapis.com.
Such skimmers often run on dodgy servers, so the location can be revealed. However, in this case, it runs entirely on trusted Google servers. Security systems will not flag them as suspicious, so CSP will not work when the site administrator is trusting Google too.
To gather such sensitive information, attackers need to create a piece of JavaScript code and transmit stolen details like payment and credit data through events and parameters used to identify actions performed on the site.
Administrators write *.google-analytics.com into the Content-Security-Policy header (used for listing resources from which third-party code can be downloaded), allowing the service to collect data. What’s more, the attack can be implemented without downloading code from external sources.
Multi-layered obfuscation and attacker-controlled GA account
Attackers use the loader to inject the skimmer that also was many methods that allow the threat to remain undetected. It is used to load a temporary iFrame to create an account for Google Analytics that attackers initially control. The skimmer can monitor the affected site and user input, so any entered information like credit card details can be stolen, encrypted, and automatically delivered to the Google Analytics board of the webmaster. The information that gets stolen can be collected from the dashboard and decrypted using the XOR encryption key.
Hackers can develop a particular feature that is used to spot the network requests and security errors. This is how visitors’ browser is enabled, and the browsing continues if the check is negative. If the customer of the compromised site opens the browser and Developer Tools, the attacker flags them, and the skimmer gets disabled.[5] All these findings show the CSP is flawed and vulnerable for injection-based web app attacks.
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.