Ein Magecart-Angriff, der als Google Tag Manager getarnt ist
Eine neue, sehr raffinierte Magecart-Web-Skimming-Kampagne wurde auf mehreren E-Commerce-Webseiten entdeckt. Magecart-Angriffe gehören einer Art von Cyberkriminalität, die gezielt Online-Einzelhändler ins Visier nimmt. Bei diesen Angriffen wird ein schädlicher JavaScript-Code in die Zahlungsseiten von Webseiten injiziert. Dieser Code erfasst die vertraulichen Informationen der Kunden, sobald sie eingegeben werden, und sendet sie an den Server des Angreifers. Diese Informationen können Kreditkartennummern und persönliche Daten umfassen.
Der jüngste Angriff zielte darauf ab, vertrauliche Informationen von Besuchern auf Kaufabwicklungsseiten und aus Formularen zu stehlen. Die Angreifer haben eine Schwachstelle ausgenutzt und so einen schädlichen Inline-JavaScript-Code in die betroffenen Webseiten injiziert. Der Skimmer verwendete Techniken, wie die Nachahmung eines legitimen Drittanbieters, zum Beispiel Google Tag Manager, und verbarg den schädlichen Code mit einer Base64-Codierung.
Der Angriff dauert auf einigen Webseiten noch immer an und ähnelt dem jüngsten Angriff auf Kanadas größten Spirituosenhändler.
Übersicht über die Angriffe
Vortäuschen des Codes eines bekannten Anbieters
Der Skimmer injiziert einen schädlichen Code als Inline-Skript (Skript, das in HTML eingebettet ist und nicht aus einer externen Datei geladen wird), das einem Code-Snippet von Google Tag Manager ähnelt (Abbildung 1). Dadurch kann der Angreifer den schädlichen Code als legitimes Skript tarnen, indem er ihn hinter einem bekannten Anbieter versteckt. Wir haben bereits mehrere Magecart-Kampagnen erlebt, bei denen diese Ausweichtechnik zum Einsatz kam und das Erkennen des Angriffs erschwert hat.
Darüber hinaus verwendet der Skimmer eine Base64-Codierung, um URLs oder Schlüsselwörter, die den schädlichen Code preisgeben könnten, zu verschleiern. Das verbirgt das Vorhandensein des Skimmers noch zusätzlich.
Abb. 1: Nachahmer eines Google Tag Manager-Snippets
Verwendung von WebSockets und der Funktion eval
In diesem Fall dient das Inline-Snippet nur als Loader und nicht als tatsächlicher Angriffscode. Der Loader enthält eine Bedingung, die den Angriff nur auf Kaufabwicklungsseiten auslöst. Dadurch kann der Skimmer diskret arbeiten und den gesamten schädlichen Code gezielt nur auf sensible Seiten laden, die für den Angriff relevant sind.
Sobald die Base64-Codierung des Loader-Codes entschlüsselt ist, ist der offengelegte JavaScript-Code kurz und simpel. Er führt nur zwei Schritte aus: Er erstellt eine neue WebSocket-Verbindung mit dem CnC-Server (Command and Control) des Angreifers und richtet eine Listener-Funktion ein, die den Code, den sie vom CnC-Server empfängt, mit der Funktion "eval" ausführt (Abbildung 2).
Abb. 2: Der codierte Code, der in dem Google Tag Manager-Snippet verborgen war.
Die Verwendung von WebSockets und der Funktion "eval" bei Magecart-Angriffen wird als fortgeschrittene Technik angesehen, da sie es ermöglicht, den schädlichen Code im Kontext der Seite als eigenes Skript auszuführen, was Forschern, Sicherheitsservices und Scannern, die möglicherweise auf der Zielwebsite betrieben werden, das Erkennen des schädlichen Codes erschwert (Abbildung 3). Mit dieser Methode bleiben die Aktivitäten der Angreifer verborgen und sind schwerer zu erkennen als herkömmliche XHR-Anfragen oder HTML-Tags.
Abb. 3: Eine andere Variante des Loaders vom selben Skimmer bei Verwendung von WebSockets
Durchführen von Codeprüfungen
Durch die Initiierung der Socket-Verbindung können der Browser und der CnC-Server jederzeit Daten austauschen. Die erste Nachricht, die der CnC-Server des Angreifers an die Webseite sendet (Abbildung 4), enthält einen JavaScript-Code, der sofort von einer Listener-Funktion ausgeführt wird, die im Loader-Code enthalten ist.
Der Code führt zwei Prüfungen durch.
- Er prüft, ob eine WebSocket-Verbindung über eine globale Variable hergestellt wurde, die im Loader-Code definiert ist.
- Er bestimmt, ob die Seite eine Kaufabwicklungsseite ist, die eine Schaltfläche zum Absenden enthält.
Wenn diese Prüfungen ein positives Ergebnis haben, sendet der Code des Angreifers eine Nachricht mit der URL der aktuellen Seite an den CnC-Server. Als Antwort sendet der CnC-Server den entsprechenden schädlichen Code, der auf die jeweilige Zielseite zugeschnitten ist, zurück.
Die Tatsache, dass der CnC-Server auf eine Seiten-URL wartet, bevor er den Angriffscode zurücksendet, legt nahe, dass diese Kampagne über ein dynamisches Framework ausgeführt wird, das zahlreiche Webseiten und Seiten gleichzeitig ausführen und unterstützen kann.
Abb. 4: WebSocket-Verbindung mit dem CnC-Server des Skimmers
Verschleierung des Codes
Abbildung 5 zeigt den tatsächlichen Angriffscode, der nach der Validierung der URL vom CnC-Server erhalten wurde. Der Code ist stark verschleiert. Dies macht es schwierig, die ihm zugrunde liegende Logik und den Verlauf des Angriffs zu bestimmen. Magecart-Skimmer setzten oft Verschleierungstechniken ein, um es Sicherheitsexperten zu erschweren, den Angriffscode zu entschlüsseln und den gesamten Ablauf zu verstehen.
Abb. 5: Der verschleierte Angriffscode, den der CnC-Server über die WebSocket-Verbindung sendet
Den Code löschen
Die Verwendung eines Entschleierungs-Tools macht die Situation eindeutiger und zeigt die Absicht hinter dem Angriff. Wie in Abbildung 6 dargestellt, enthält der Code eine große Auswahl an Schlüsselwörtern, die dazu dienen, sensible Felder auf der Zielseite zu identifizieren und ein gefälschtes Zahlungsformular unter der Kontrolle des Angreifers einzurichten.
Das ultimative Ziel des Angreifers ist es, persönliche Informationen von ahnungslosen Besuchern zu stehlen, die mit der infizierten Seite interagieren und das gefälschte Formular, das der Code des Angreifers injiziert hat, ausfüllen.
Abb. 6: Angriffscode nach der Entschleierung
Einfügen gefälschter Formulare für Drittanbieter
Einige Zielgeschäfte lagern ihren Zahlungsprozess an einen Drittanbieter aus. Um personenbezogene Daten anzugeben, werden die Kunden zum Drittanbieter weitergeleitet, geben ihre Kreditkartendaten ein und schließen die Transaktion ab. Der Skimmer kann nicht auf die Webseite des Drittanbieters zugreifen, um dort die Kreditkarteninformationen des Endnutzers zu erhalten.
Stattdessen erzeugt der Skimmer ein gefälschtes Kreditkartenformular auf der Seite, die der Weiterleitung der Kunden an den Drittanbieter vorausgeht (Abbildung 7). Wenn der Nutzer auf eine der gefälschten Schaltflächen "Zur Kasse gehen" oder „Zahlung senden“ klickt, sendet der Skimmer alle erfassten Daten an seinen CnC-Server und lässt den Nutzer den legitimen Zahlungsablauf fortzusetzen, indem er ihn zur tatsächlichen Zahlungsseite des echten Drittanbieters weiterleitet.
Abb. 7: Ein gefälschtes Formular, das der Skimmer erstellt hat
Falls die Zielwebsite die Nutzer nicht an die Zahlungsseite eines Drittanbieter weiterleitet, erstellt der Skimmer kein neues Formular. Stattdessen fügt er allen vertraulichen, persönlichen Nutzereingaben auf der Kaufabwicklungsseite und in den Zahlungsformularen einen JavaScript-Listener hinzu. Sobald der Nutzer die Informationen übermittelt, extrahiert der Skimmer die Daten und sendet sie mithilfe von WebSockets-Nachrichten an seinen CnC-Server.
In beiden Fällen verschlüsselt der Skimmer die extrahierten Daten, um es Forschern und Sicherheitsservices zu erschweren, die von ihm ausgelösten ungewöhnlichen Netzwerkaktivitäten zu erkennen (Abbildung 8).
Abb. 8: Beispiel für die verschlüsselte Nachricht des Skimmers, die über eine WebSocket-Verbindung gesendet wird
Ähnlichkeiten zwischen Angriffen
Während der Untersuchung fanden wir mehrere Webseiten, die diesem Angriff zum Opfer gefallen waren. Wir können nicht bestätigen, dass sie alle mit derselben Kampagne in Zusammenhang stehen, doch es gab Ähnlichkeiten zwischen den Fällen, die auf die Verwendung desselben Magecart-Frameworks hindeuten. In einigen Fällen wurden Indikatoren auf mehreren angegriffenen Websites gefunden. Einer dieser Indikatoren war, dass der Inline-Loader des Angriffs als gefälschter Google Tag Manager getarnt war, dessen codierte Parameter jegliche Anzeichen des Skimmers verdeckten.
Die Domains, die die Angreifer verwendet haben, variierten von Website zu Website, und in den meisten Fällen wurde der eigentliche Angriffscode vom Loader-Code auf relevanten Seiten abgerufen, wodurch der Angriff diskreter und schwieriger zu erkennen war.
Zusammenfassung der Techniken und Kenntnisse der Angreifer
Imitieren eines Code-Snippets eines bekannten Anbieters wie Google Tag Manager
Verwenden der Base64-Codierung, um Indikatoren des Angreifers wie URLs und Domains zu verbergen
Verwenden von WebSockets für die gesamte Kommunikation zwischen dem Browser und dem CnC-Server – Abrufen des Angriffscodes und Exfiltrieren der Daten
Ausführen des Angriffscodes mit „eval“, damit das Skript wie ein organisches eigenes Skript der Zielwebseite aussieht
Verwenden von Verschleierungstechniken, die es Forschern schwer machen, den Code zu verstehen
Einfügen gefälschter Formulare, um Daten zu sammeln, bevor die Nutzer zu legitimen Zahlungsdienstleistungsseiten Dritter weitergeleitet werden
Schützen Sie sich mit dem Akamai Page Integrity Manager
Unser Team nutzte den jüngsten Magecart-Angriff, um den Akamai Page Integrity Manager zu testen. Er hat den Angriff sofort erkannt und abgewehrt und detaillierte Informationen zur Fehlerbehebung bereitgestellt (Abbildung 9).
Der Page Integrity Manager wurde speziell zum Schutz vor Web-Skimming, Formjacking und Magecart Angriffen entwickelt. Er bietet Einblick in das Verhalten der Skriptausführung einer Webseite und erfasst Informationen über die verschiedenen Skripte, die ausgeführt werden, einschließlich ihrer Aktionen und ihrer Beziehungen zu anderen Skripten.
Durch die Kombination dieser Daten mit einem mehrschichtigen Erkennungsverfahren, das Heuristik, Risikobewertung, künstliche Intelligenz und andere Faktoren beinhaltet, kann der Page Integrity Manager clientseitige Bedrohungen schnell erkennen und abwehren.
Abb. 9: Detaillierte Informationen zur Fehlerbehebung vom Akamai Page Integrity Manager
Fazit
Magecart-Skimmer entwickeln sich ständig weiter und werden immer raffinierter. Der Einsatz fortschrittlicher Umgehungs- und Verschleierungsmethoden durch den in diesem Beitrag beschriebenen Skimmer zeigt, welche Schwierigkeiten die Aufdeckung dieser Angriffe erschweren.
Dieses Katz-und-Maus-Spiel – das noch nicht beendet ist – erfordert eine umfassende Sicherheitslösung, um Angriffe zu erkennen und abzuwehren. Wenn eine solche Lösung nicht implementiert wird, kann dies ernsthafte Schäden für die Kunden, deren Privatsphäre kompromittiert werden kann, und eine erhebliche Rufschädigung für das Unternehmen nach sich ziehen. Außerdem können hohe Geldstrafen verhängt werden.
Die neuen Anforderungen des aktuellen Payment Card Industry Data Security Standard (PCI DSS v4,0) machen Sicherheitsfunktionen im Browser zu einem absoluten Muss für jedes Unternehmen, das Zahlungskarten online verarbeitet.
Weitere Informationen
Der Akamai Page Integrity Manager unterstützt Sie dabei, diese neuen Anforderungen zu erfüllen, indem er eine Übersicht sämtlicher Skripte, die auf Ihrer Webseite ausgeführt werden, bereitstellt, Einblick in das Skriptverhalten gewährt und Schutz vor den raffiniertesten skriptbasierten Angriffen bietet.
IoCs
Die folgenden Bedrohungsindikatoren (Indicator of Compromise, IoC) sollen der Community helfen, die im Blog beschriebenen schädlichen Aktivitäten und Skimmer zu erkennen:
yachtbars[.]fun
app-stat[.]com
Magento-cdn[.]net
nebiltech[.]shop
Rithdigit[.]cyou
Antohub[.]shop
Okqtfc1[.]org
jquery-node[.]com
Erfahren Sie mehr über das Erhalten von Einblicken in das Skriptverhalten und den Schutz vor clientseitigen Angriffen mit dem Akamai Page Integrity Manager.
