Xurum: Neue Magento-Kampagne entdeckt

Der digitale Handel im Allgemeinen ist ein beliebtes Angriffsziel von Cyberkriminellen. Leider ist Magento aufgrund seiner Popularität besonders attraktiv (und lukrativ). Der bemerkenswerteste konkrete Angriff ist ein Magecart-Angriff,  bei dem die Angreifer JavaScript-basierte Skimmer einsetzen, um illegal an vertrauliche Nutzerinformationen zu gelangen. Diese Magecart-Angreifer nutzen bekannte Schwachstellen im Internet, um diese Daten zu stehlen.

Seit 2015 waren die Magento-Stores Angriffen aus mindestens sieben Bedrohungsgruppen ausgesetzt, was die Wichtigkeit der Plattform und den Erfolg, den Angreifer mit diesem Angriff haben, verdeutlicht.

Anfang 2022 wurde die Schwachstelle CVE-2022-24086 entdeckt, mit der Angreifer die Magento-Template-Engine ausgenutzt haben, um beliebigen PHP-Code auf anfälligen Zielgeräten auszuführen. Der Angriff läuft in mehreren Schritten mit gängigen Angriffsvektoren ab. Dazu gehören der Missbrauch des Bezahlvorgangs oder der Wunschlistenfunktion.. Seit ihrer Entdeckung hat sich diese Schwachstelle als primärer Einstiegspunkt für zahlreiche Magecart-Angreifer erweisen, die Angriffe auf anfällige Magento 2-Stores durchgeführt haben.

In den letzten Monaten hat Akamai besonders eine Kampagne verfolgt, die konkret auf eine relativ kleine Anzahl von Magento-Implementierungen abzielt. Wir nannten die Kampagne Xurum, nach dem Domain-Namen des C2-Servers, den die Angreifer verwenden.

Während der laufenden Kampagne haben wir beobachtet, wie Angreifer versuchten, zwei verschiedene Payloads von insgesamt vier IP-Adressen aus auszuführen (Abbildung 1). Diese IPs sind mit der Infrastruktur von zwei Hosting-Anbietern verknüpft: Hetzner in Deutschland und Shock Hosting in den USA.

Unsere Untersuchung des Servers xurum.com haben gezeigt, dass er sich in den Niederlanden befindet (Abbildung 4) und von dem russischen Hosting-Unternehmen VDSina.ru gehostet wird (Abbildung 5).

Da es mehrere Iterationen dieses Angriffs gibt, haben wir ihn xurum genannt, um diese Kampagne von anderen abzugrenzen.

Häufig wenden Angreifer eindeutige Namenskonventionen für ihre Domains oder Malware an, die versehentlich oder absichtlich zu ihrer Signatur werden. Während unserer Untersuchung der Bedeutung von "xurum" sind wir auf zwei mögliche Interpretationen gestoßen.

Laut Google Translate ist xurum das lateinische Wort für "richtig" und wird als "das Richtige tun" übersetzt (Abbildung 7). Im WordSense-Wörterbuch hingegen heißt es, dass xurum das Wort für „Junge“ in einer inzwischen toten Sprache ist, die einst in Guatemala gesprochen wurde (Abbildung 8).

Bemerkenswert ist, dass die Angreifer zum Zeitpunkt dieses Blogbeitrags ihren Xurum-Server heruntergefahren haben und zu einem anderen Server gewechselt sind, der sich anscheinend noch in der Phase der Qualitätssicherung befindet.

Das schädliche PHP-Skript, das vom Xurum-Server heruntergeladen und auf dem betroffenen Computer ausgeführt wird, weist mehrere Infektionsphasen auf.

Zunächst werden technische Informationen über das Opfer gesammelt, wie z. B.:

• PHP-Version

• Ob der Angriff das Verzeichnis „/pub„ (gemeinsame Verzeichnisstruktur in Magento) erreicht hat

• Ob die Datei „/var/www/html/vendor/magento/google-shopping-ads/registration.php“   vorhanden und nicht schreibgeschützt ist 

• Der Inhalt der Datei “env.php“, der wichtige Informationen über die Anwendungen von Magento enthält, wie etwa umgebungsspezifische Einstellungen, aber auch geheime Informationen wie den Verschlüsselungsschlüssel, der zum Schutz von sensiblen Daten, wie Kennwörtern, Kreditkarten- und Kundeninformationen, verwendet wird

Dann entschlüsselt es einen mit Base64 verschlüsselten Blob und schreibt ihn in die Datei „/var/www/html/vendor/magento/google-shopping-ads/registration.php“ (Abbildung 9).

Die neue Datei enthält faszinierende Inhalte. Statt einer eigenen Kopie einer Webshell, die auf ihrem C2-Server gehostet wird, verweist der Code in der neuen Datei auf ein öffentliches GitHub-Repository, das sich im Besitz eines Sicherheitsforschers namens "Bad Advertiser" oder "@0xbadad“ befindet. In diesem Repository befindet sich eine bekannte Webshell namens wso-ng. Besonders interessant ist jedoch, dass die Webshell sich nicht auf die Festplatte des Servers befindet. Stattdessen wird sie nur aus dem Speicher abgerufen und ausgeführt "", wenn auf die neu erstellte Seite registration.php zugegriffen wird. Zum weiteren Schutz vor unbefugtem Zugriff muss die Anfrage außerdem einen bestimmten "magemojo000-"Cookie beinhalten, damit die Webshell erfolgreich ausgeführt werden kann.

Anschließend registriert der Angreifer die neue Webshell-Funktion als neue Magento-Komponente, die als „GoogleShoppingAds“ getarnt ist (Abbildung 10).

Nach der Installation der Backdoor rufen die Angreifer Informationen über die Zahlungsmethoden aus Kundenbestellung der vorhergehenden 10 Tage ab und extrahieren diese Daten zusammen mit den zuvor erfassten technischen Informationen in die Dropzone von xurum.com (Abbildung 11).

Im letzten Schritt erstellen die Angreifer einen Backdoor-Admin-Nutzer mit dem Namen "mageworx" (oder "mageplaza" in einigen Varianten). Diese Namen entsprechen Mageworx und Mageplaza, den beliebten Erweiterungs-Stores von Magento 2 (Abbildung 12). Diese Namenswahl ist wohl der Versuch, ihre Aktivitäten im Zusammenhang mit diesen seriösen Erweiterungsanbietern als legitim zu tarnen.

Bemerkenswert ist dabei eine interessante Nuance in den E-Mail-Adressen des Backdoor-Nutzers. In der E-Mail-Adresse developer@mageplazza.com ist „mageplazza“ mit einem doppelten „z“ geschrieben, während der Name der legitimen Speicherdomain mageplaza.com nur mit einem „z“ geschrieben wird, was wie ein Tippfehler der Angreifer wirkt. Ein ähnlicher Tippfehler findet sich in der anderen E-Mail-Adresse des Backdoor-Nutzers: support@magaworx.com,  wo sich anstelle des „e“ aus dem Original-Storenamen Mageworx ein „a“ befindet.

Eine Web-Shell ist ein schädliches Skript oder Teilstück eines Codes, das Angreifer hochladen und auf einem Webserver ausführen, um unbefugt Zugriff auf den Server und seine zugrunde liegenden Dateien und Daten zu erhalten und diese dauerhaft zu kontrollieren.

Bei diesem Vorgang nutzen die Angreifer die sehr fortschrittliche Webshell wso-ng, die vor einigen Jahren von einem Sicherheitsforscher erstellt wurde. Laut dem Autor handelt es sich bei wso-ng um eine neue Generation der älteren und bekannten WSO (Web Shell by Orb). 

Zusätzlich zu den typischen Funktionen von Webshells, wie z. B. der Erfassung von Systeminformationen sowie der Verwaltung von Dateien und SQL, verfügt wso-ng über weitere bemerkenswerte Funktionen, die sie von anderen Webshells unterscheiden (Abbildung 13).

Eine dieser neuen Funktionen ist die versteckte Anmeldeseite. Beim Zugriff auf die Seite wird ein HTTP-Statuscode 404 („nicht gefunden“) ausgegeben, der den Eindruck erweckt, die Seite sei nicht vorhanden. Der sichtbare Inhalt wirkt auf den ersten Blick wie eine leer Seite (Abbildung 14). Bei der Prüfung des Quellcodes wird jedoch ein verborgenes Anmeldeformular angezeigt.

Das Formular wird mithilfe einer einfachen CSS-Täuschung, bei der es um 1.000 Pixel nach links verschoben ist, aus dem sichtbaren Bereich entfernt. Dieses verborgene Anmeldeformular „wartet“, bis der Nutzer das Kennwort eingibt.

Wir haben im Arsenal der Angreifer auf dem Server xurum.com ein weiteres Interessantes Tool gefunden: einen öffentlich zugänglichen Exploit einer älteren CVE-2016-5195-Schwachstelle namens Dirty COW zur lokalen Umgehung von Linux-Berechtigungen (Abbildung 15).

Da viele unserer Kunden mit Web Application Firewall (WAF) diese Kampagne effektiv abwehren konnten, konnten wir weitere Aktionen der Cyberkriminellen nicht unmittelbar beobachten. Bei unserer Untersuchung sind uns jedoch Websitenamen aufgefallen, die indirekt mit dieser Kampagne in Zusammenhang standen und im Ursprungs-/Referenz-HTTP-Header der Exploit-Anfrage angezeigt wurden.

Mindestens eine dieser Websites war mit einem einfachen Web-Skimmer infiziert. Der Skimmer wurde auf der Hauptseite installiert und verwendete keine Verschleierungstechniken. Er sammelte Kreditkarteninformationen und speicherte sie in einer Dropzone, die auf „smileface.site“ gehostet wird Abb. 16).

Auf einen Zugriffsversuch reagiert die Website mit einem kalten „Get out!“ (Abbildung 17).

Die IP-Informationen zeigen, dass sich der Server in Moskau befindet und vom russischen Hosting-Dienst „Reg.ru“ gehostet (Abbildung 18).

Unsere Untersuchung dieser Kampagne ergab, dass sie mindestens bis Ende Januar 2023 zurückreicht. Die Angreifer haben akribisch gearbeitet, indem sie konkrete Magento-2-Instanzen angegriffen haben, anstatt ihre Exploits wahllos über das Internet zu verteilen. Sie verfügen über ein hohes Maß an Fachwissen über Magento und investieren viel Zeit in das Verständnis der internen Komponenten, die Einrichtung einer Angriffsinfrastruktur und das Testen ihrer Exploits an realen Zielen.

Diese Kampagne dient als praktisches Beispiel dafür, wie ältere Schwachstellen auch Jahre nach ihrer Offenlegung weiterhin genutzt werden, da Unternehmen Schwierigkeiten haben, Patches und Sicherheitsmaßnahmen zeitnah anzuwenden.

Um den initialen Zugriff auf den Server zu verhindern, sollten Sicherheitsexperten stets die neuesten Patches installieren und sie durch eine WAF wie Akamai App & API Protector ergänzen.

Da das Hauptziel der Magecart-Angreifer ist, Magento-Seiten mit Web-Skimmern zu infizieren und Kreditkarteninformationen von Kunden zu stehlen, empfehlen wir dringend, zusätzliche spezielle Sicherheitslösungen zu verwenden. Diese Lösungen sollten Einblicke in das Verhalten von Browserskripten und Schutz vor clientseitigen Angriffen bieten.

Ein effektiver Ansatz besteht darin, Sicherheitsmaßnahmen näher an dem Ort zu implementieren, wo die tatsächlichen Angriffe auf Clients stattfinden. Dazu gehört das Erkennen versuchter Lesezugriffe aus sensiblen Eingabefeldern und von Datenextraktion. Wir empfehlen, diese Ereignisse umgehend zu erfassen, um durch Sicherheitsprodukte wie Akamai Page Integrity Manager eine schnelle und effektive Abwehr zu ermöglichen.

Bei unserer Analyse der jüngsten Versuche zur Ausnutzung der Schwachstelle Magento CVE-2022-24086 bei unseren Kunden sind wir auf weitere Kampagnen gestoßen, die wir derzeit untersuchen. Wir werden unsere Untersuchungen fortsetzen und unsere Erkenntnisse an die Sicherheit-Community weitergeben. Um weitere aktuelle Sicherheitsforschungsergebnisse zu lesen, folgen Sie uns auf Twitter.

Die folgenden Bedrohungsindikatoren (Indicator of Compromise, IoC) sollen der Community helfen, die im Beitrag beschriebenen schädlichen Aktivitäten zu erkennen.