Vladimir Gerasimov - stock.adobe

Warum Skimming die IT-Security-Teams weiterhin beschäftigt

Eine Betrachtung der aktuellen Magecart-Aktivitäten veranschaulicht Angriffswege, wie sensible Anmeldeinformationen, Bankdaten oder personalisierte Details gestohlen werden.

Im Frühjahr und Sommer 2019 beobachteten die Sicherheitsforscher des Zscaler-ThreatlabZ-Teams ansteigende Aktivitäten von Magecart. Unter dem Begriff Magecart werden verschiedene Hackergruppen zusammengefasst, die Kredit- oder Debit-Karten-Informationen ausbeuten, indem sie JavaScript-Code in E-Commerce-Seiten einfügen.

Unlängst sind vor allem Amazon-S3-Buckets ins Visier geraten, und eine Sicherheitsfirma berichtete von insgesamt 17.000 befallenen Domains. In früheren Kampagnen infizierten die Hacker bereits 962 Online-Shops und setzen dabei auf automatisierte Tools für ihre Angriffe, um an Zahlungsinformationen zu gelangen.

Angesichts der gehäuften Aktivitäten analysierte das ThreatLabZ-Team die Vorgehensweise von Magecart in deren aktueller Kampagne und stellten dabei eine Veränderung in den Angriffsketten fest.

Die Kriminellen verwenden derzeit entweder ein stark verschleiertes JavaScript mit verschlüsselten Daten, das dynamisch injiziert wird. In einigen anderen Fällen wird der bösartige JavaScript-Code direkt in die E-Commerce-Seiten eingebracht.

Diese aktuellen Mechanismen unterscheiden sich von früheren Angriffen, bei denen der Schadcode noch remote eingespeist wurde. Die Vorgehensweise, um die schädlichen Aktivitäten im Verborgenen durchzuführen, wurde in der Analyse detailliert unter die Lupe genommen.

Was ist Skimming?

Skimming ist ein Sammelbegriff für verschiedene Techniken, mit denen Cyberkriminelle unterschiedliche Kreditkarten oder andere Zahlungsinformationen ausspähen, um im Anschluss die Konten der Opfer zu plündern. Die Betroffenen erfahren zumeist erst über den Kontoauszug oder den Abruf des -Kontostands, dass sie Opfer eines Skimming-Angriffs wurden.

Dynamisches Injizieren von verschleiertem JavaScript

Magecart schlägt mit seiner Angriffsmasche zu, wenn das Opfer auf einer E-Commerce-Seite nach dem Laden des Warenkorbs auf den Checkout-Button klickt. In diesem Moment wird der JavaScript-Payload dynamisch geladen, um die Kreditkarteninformationen abzugreifen.

Der Smart Crawler des ThreatLabZ-Teams mit heuristischer Erkennung deckte auf, dass verschiedene JavaScript-Funktionen in der Payload verschleiert ausgeliefert werden. Dieses bösartige Skript sucht nach bestimmten Schlüsselwörtern in der URL und injiziert bei Auffinden der Wörter ein weiteres Skript von hxxps://dnsden[.]biz/a.js.

Das oben eingespeiste, verschleierte Skript hxxps://dnsden[.]biz/a.js enthält verschlüsselte Daten, die vom RC4-Algorithmus in der Runtime entschlüsselt werden. Die verschlüsselten Daten im a.js-Skript sorgt nach der RC4-Entschlüsselung dafür, dass das Hauptskimming-Skript eingespeist wird, so dass die Kreditkartendaten des Opfers extrahiert werden können und an den Angreifer geschickt werden.

Verschlüsselte Daten:

w5rDvcOKwrnCnsKYcWHCgAcaUsOFVcOQXnZpw48KfjZ/CMObMMOiwq7Cm1XDvFDCl8
KBEsKRE8Oyw6krWcK0wo1Xw7J+w6/DknoJasKVScKZOhzCoRI=

Entschlüsselte Daten: <script src="hxxps://dnsden[.]biz/js/universal.js"></script>

Die universal.js ist ebenfalls verschleiert und hat den gleichen Verschlüsselungsalgorithmus wie a.js. Nach der Entschlüsselung ruft es eine Funktion auf einem Formular auf und sammelt alle vom Opfer eingegebenen Zahlungsinformationen ein.

Abbildung 1: Falsches Kreditkartendetailfeld und bösartige JavaScript-Datei kennzeichnen die Angriffe.
Abbildung 1: Falsches Kreditkartendetailfeld und bösartige JavaScript-Datei kennzeichnen die Angriffe.

Direktes Einbringen von Schadcode in die kompromittierte Seite

Bei der zweiten aufgedeckten Angriffsmethode ist der bösartige JavaScript-Code auf der E-Commerce-Seite gehostet und wird über ein Toolkit injiziert, das zuerst nach den beiden Cookie-Namen $s und $sent sucht. Wenn diese Cookies gesetzt sind, werden die Daten nach der Dekodierung in einer Variablen gespeichert. Diese Cookie-Werte werden bei jeder Eingabe von Zahlungskartendetails herangezogen um zu überprüfen, ob neue Daten eingegeben wurden.

Damit die Angreifer die Kreditkartendetails erhalten, werden Daten von allen Tags, wie Eingabe, Auswahl und Textbereich gespeichert und das Skript führt eine Grundlängenprüfung der Kartendetails durch. Nach der Validierung der Zahlungskartendaten wird ein Hash der Kartendaten berechnet und überprüft, ob in den Daten, die zuvor aus dem Cookie $sent abgerufen wurden, derselbe Hash-Wert verfügbar ist. Die Zahlungsdetails werden zum Abgreifen abgelegt, wenn ein Hash-Match gefunden wird.

Jedes Mal, wenn neue Zahlungskartendaten eingegeben werden, werden die Daten an den Angreifer weitergeleitet und der Hash-Wert für diese Daten wird an den Cookie-Wert $sent angehängt; mit diesem Cookie-Wert wird überprüft, ob die eingegebenen Daten neu sind.

Beim Decodieren des oben genannten Base64-codierten Wertes des Cookies $sent konnten die Forscher das MD5-Array der Zahlungskartendetails aufdecken. Durch das Speichern der verschlüsselten Zahlungskartendaten als Cookie hat der Angreifer die Möglichkeit hinzugefügt, doppelte Werte zu löschen. Die Zahlungsdaten werden immer mit dem Cookie-Wert verglichen und nur eindeutige Kartendaten an den Angreifer gesendet. Nachdem abschließend alle oben genannten Prüfungen verschlüsselt wurden, werden die Zahlungskartendaten an die von Angreifern kontrollierte Website gesendet.

Als dritte Methode wurde zuletzt noch das Vorgehen der Magecart-Gruppe mit gefälschten Eingabefeldern untersucht. Mit einem ähnlichen Skimming-Toolkit injizieren Angreifer gefälschte Zahlungskartenfelder in die kompromittierte Website und verstecken die legitimen Felder, sobald das Opfer seine Kreditkarte als Zahlungsmethode auswählt.

Prakhar Shrotriya, Zscaler

„Die Magecart-Kampagne ist seit langem aktiv und entwickelt sich ständig weiter, um mit Hilfe verfeinerter Techniken letztlich die Ausbeute zu erhöhen.“

 Prakhar Shrotriya, Zscaler

Die eingespeisten und legitimen Kreditkartenfelder sehen vergleichbar ähnlich aus, aber die Attribute der HTML-Eingabefelder (ID und Typ) zeigen deutliche Unterschiede. In den injizierten Feldern lautet die Kartennummer ID _ccnumber und der Typ text, während in einer legitimen Kartennummer die ID credit-card-number und der Typ tel.

Fazit

Diese neuen Entwicklungen der laufenden Kampagne veranschaulichen einige der Angriffswege, die zum Diebstahl sensibler Anmeldeinformationen, Bank- oder Zahlungskartendaten sowie personalisierter Details führen können. Die Magecart-Kampagne ist seit langem aktiv und entwickelt sich ständig weiter, um mit Hilfe verfeinerter Techniken letztlich die Ausbeute zu erhöhen.

Über die Autoren:
Prakhar Shrotriya, Dhruval Gandhi und Mohd Sadique sind Sicherheitsforscher bei Zscaler.

Die Autoren sind für den Inhalt und die Richtigkeit ihrer Beiträge selbst verantwortlich. Die dargelegten Meinungen geben die Ansichten der Autoren wieder und entsprechen nicht unbedingt denen von ComputerWeekly.de.

Nächste Schritte

Gratis-eBook: Das Risiko Webanwendungen absichern

Webanwendungen und -Services sicher entwickeln

Smishing: Welche Folgen Cyberangriffe per SMS haben

Erfahren Sie mehr über Bedrohungen

ComputerWeekly.de
Close