Denken Sie daran, Magecart?
Im November vergangenen Jahres, Sicherheit Forscher entdeckt, dass die berüchtigten Malware, zum Ernten von Kreditkartendaten aus der Kasse Formen bekannt, [wplinkpreview url =”https://sensorstechforum.com/sites-magecart-malware-reinfected/”]konnte erneut infizieren auch nach Bereinigungs.
Jetzt, Magecart ist wieder aktiv in notorisch Kampagnen, in denen 277 E-Commerce-Websites wurden in Supply-Chain-Angriffe infiziert. Was bedeutet das?
Neue Magecart Kampagnen erkannt
Sicherheitsforscher von RiskIQ und Trend Micro stießen auf eine neue Untergruppe bekannt als Magecart Gruppe 12 die gezielte Websites infiziert durch Skimming-Code in einem Dritt Einfügen von JavaScript-Bibliothek. Diese Technik lädt den bösartigen Code in alle Webseiten, die die Bibliothek nutzen.
Weitere Forschung in diese Aktivitäten ergab, dass der Skimming-Code nicht direkt in E-Commerce-Website injiziert wurde, aber zu einer Drittanbieter-JavaScript-Bibliothek von Adverline, ein Französisch Online-Werbeunternehmen, die wir umgehend kontaktiert. Adverline hat den Vorfall behandelt und hat unverzüglich die notwendigen Sanierungen in Beziehung mit der La Poste CERT durchgeführt, sagte Trend Micro Forscher in ihrem Bericht.
RiskIQ Forscher haben die Überwachung auch eng an die Magecart Gruppe. Offenbar, Gruppe 12 erstellt seine Infrastruktur im vergangenen Jahr im September, Domänen wurden registriert, SSL-Zertifikate eingerichtet wurden durch LetsEncrypt, und der Skimming-Backend wurde installiert. Der Hacker nutzt, auch einen kleinen Schnipsel mit einer Base64-kodiert URL für die Ressource, die zur Laufzeit und injizierte in der Seite decodierte, RiskIQ Bericht Highlights.
Die Gruppe verwaltet gezielt Websites durch Adverline Kompromiss am Ende 2018.
Es sollte beachtet werden, dass Magecart Gruppe 12 des Skimming-Code ist etwas anders, mit „eine interessante Wendung“- es schützt sich vor deobfuscation und Analyse durch eine Integritätsprüfung auf sich selbst durchführen.
Bei der eigentlichen Injektion Skript, es kommt in zwei Stufen, beide entworfen, um eine Selbst-Integritätsprüfung durchzuführen,. Hier ist, wie die beiden Stufen stattfinden, als erklärt von RiskIQ:
– Die gesamte erste Stufe wird als eine Funktion ausgeführt, die global definiert ist (das ist wichtig)
– Die zweite Stufe wird codiert und mit Datenmüll gepolstert, die in ein neues div Objekt geschrieben
– Diese Zweitstufendaten werden dann unpadded, decodiert, und schließlich ausgeführt
– Der ausgeführte Code greift sich eine Referenz auf sich selbst (die global festgelegt wurde) und wird durch eine Hash-Funktion gesetzt, die die JavaScript-Implementierung von Java hashCode ist.
– Wenn die Prüfung bestätigt wird, die nächste Stufe ausgeführt.
Zum Glück, Adverline hat bereits das Problem behoben, indem den schädlichen Code aus der betroffenen JavaScript-Bibliothek entfernen.