Researchers at Kaspersky Lab reportthat hackers misuse Google Analytics to implement attacks like MageCart (to put it more simply, web skimming). Thus, attackers stealthily extract stolen bank card data from infected online store sites.
The principle of such attacks is quite simple: malicious code is injected into the hacked site, which collects data entered by the user and sends it to a resource controlled by the attacker. In the event of a successful attack, an attacker who infected the site gains access to the payment data of visitors.
Experts say that in order to send data to a third-party resource to make it less visible, scammers often register domains that resemble the names of popular web services, in particular Google Analytics: google-anatytics (.) Com, google-analytcsapi (.) Com, google-analytc (.) com, google-anaiytlcs (.) com, google-analytics (.) top, google-analytics (.) cm, google-analytics (.) to, google-analytics-js (.) com, googlc-analytics (.) com and so on.
And, as the experts managed to establish, the original service can be used in attacks of this kind.
In order to collect data about visitors with the help of Google Analytics, the site owner must configure the tracking parameters in his account on analytics.google.com, get the tracking code (trackingId – line of the form UA-XXXX-Y) and insert the tracking code with it on the resource pages . At the same time, several tracking codes can coexist on one site, sending data about visitors to different “analytics” accounts.
Researchers have identified several cases of misuse of the Google service: the attacker injected malicious code onto the site that collected all the data entered by users, and then sent it using the “analytics” protocol. As a result, the attacker gained access to the stolen data in his Google Analytics account. It was discovered about two dozen infected sites around the world. Among the victims are shops from Europe, North and South America that sell digital equipment, cosmetics, food and spare parts.
What the “infection" looks like can be seen in the screenshot below – malicious code with a tracking code and an attacker’s trackingId:
It is noted that in some cases, such an injection can be obfuscated, and malicious code can be downloaded from a third-party resource.
In fact, the attacker tries to hide malicious activity using the classic anti-debugging technique. In the screenshot below you can see whether the developer mode is enabled in the visitor’s browser. That is, the code in the screenshot above will be executed only if it is passed.
Researchers note that the attacker left a loophole for himself – the ability to observe the script in debug mode. If the local storage of the browser (Local Storage) is set to ‘debug_mode’ == ’11’, the malicious code will also work when the developer’s tools are open and will even write comments to the console in clumsy (with errors) English. In the illustration below, the line with the ‘debug_mode’ check follows the implementation of the RC4 encryption algorithm (which is used to encrypt the collected data before sending it).
If anti-debugging is passed, the script collects everything entered by the user on the site (as well as data about himself, such as IP address, UserAgent, time zone of the user). The collected data is encrypted and sent using the Google Analytics Measurement Protocol.
Researchers warn that the danger is great, because Google Analytics is an extremely popular service (according to BuiltWith, it is used more than on 29 million sites) that users trust: administrators write * .google-analytics.com in the Content-Security-Policy heading (used to list resources from which third-party code can be downloaded), allowing data collection to this service. In addition, the attack can be implemented without downloading the code “from the side”.