Kritische Sicherheitslücke in Magento (XML-RPC-Schnittstelle) [Update]

In der Nacht von 5. Juli auf 6. Juli (mitteleuropäische Zeitzone) veröffentlichte Magento Inc. einen Patch für die Community Edition und Enterprise Edition. Dieser Patch behebt eine kritische Sicherheitslücke in Magento, die durch die XML-RPC-Schnittstelle ausnutzbar ist.

Update 09. Juli: im Magento-Blog findet sich nun ein neue, ausführlichere Information zur Schwachstelle.

Im Netz finden sich dazu bereits viele hilfreiche Posts. Ich möchte nun, nachdem sich der erste Staub gelegt hat, zusammenfassen und auf einige Details eingehen.

Auswirkung, Gefahr und Umfang der Sicherheitslücke

Die Sicherheitslücke ist als sehr kritisch einzustufen, da sie es dem Angreifer auf verwundbaren Systemen ermöglicht, auf jede Datei des Systems lesend zuzugreifen. Das trifft auch auf Konfigurations- und Passwortdateien zu. Im „Worst Case“ kommt es dazu, dass der Angreifer sich Zugangsdaten zu Datenbanken, FTP-Accounts, dem Server selbst oder zu externen Systemen verschaffen kann, mit denen der Webserver in Verbindung steht. Ob und wie sich diese Informationen ausnutzen lassen, hängt von der Konfiguration des jeweiligen Systems ab.

Der Angriff kann auf Webshops ausgeführt werden, welche die XML-RPC-Funktionalität bzw. -Schnittstelle aktiviert haben und nicht gepatcht sind. Gültige Zugangsdaten für die Schnittstelle sind nicht nötig. Es kann also theoretisch jeder Dateien auf diese Weise auslesen. Es ist anzunehmen, dass eine große Zahl von Webshops anfällig sind.

Bin ich betroffen?

Ja. Außer Sie können definitiv ausschließen, dass das so ist. Eine Standard-Magento-Installation ab Community Edition 1.4 bis 1.7.0.1 sowie die Enterprise Edition sind angreifbar.

Tobias Vogt von den Webguys hat ein Testskript zur Verfügung gestellt, mit dem Sie Ihren Shop überprüfen können. Danke an Tobi dafür!

Was kann ich dagegen tun?

Disclaimer: bitte beachten Sie, dass ich keine Haftung für Ihr System übernehmen kann. Führen Sie Änderungen gewissenhaft und auf eigene Gefahr durch. Erstellen Sie immer ein Backup, bevor Sie Aktualisierungen durchführen.

Die Lücke schließen können Sie auf verschiedene Arten:

  • Upgrade auf Magento CE 1.7.0.2 bzw. Magento EE 1.12.0.2
    die neu veröffentlichten Versionen enthalten den Patch. Die aktualisierte Community Edition kann über die Download-Seite oder Magento Connect bezogen werden.
  • Einspielen des Patches
    Magento hat im Blog-Post Patches für diverse Versionen der Community-Edition verlinkt. Diese müssen von Ihren technischen Shop-Verantwortlichen (z.B. Ihrer EDV-Abteilung oder Web-Agentur) eingespielt werden.
    Beispiel-Befehle für das Patchen einer oder mehrerer Magento-Installationen finden Sie bei Webguys oder Vinai Kopp auf Github.
  • Dateien manuell aktualisieren
    Können Sie die zwei oben genannten Varianten nicht verwenden, können Sie sich die Änderungen in den Patch-Dateien ansehen und Sie manuell übernehmen. Alternativ hat Rouven Rieker fertig gepatchte Dateien bei Github online gestellt. Klicken Sie sich zu den Dateien Ihrer Magento-Version durch und kopieren Sie die Inhalte aus der „Raw“-Ansicht.

Um die Lücke auf diese Weise zu schließen, wird die PHP-Funktion libxml_disable_entity_loader() benötigt. Sie ist ab PHP 5.2.11 verfügbar. Eine gar nicht so geringe Anzahl an Providern verwendet noch ältere PHP-Versionen, z.B. wenn als Betriebssystem Debian Lenny im Einsatz ist. Diese Lösung ist somit leider nicht auf alle Systeme anwendbar.

Workarounds, falls eine ältere PHP-Version vorhanden ist

Auf Webservern mit älteren PHP-Versionen als PHP 5.2.11 erhalten Sie nach Einspielen des Patches/Upgrades beim Aufruf der XML-RPC-Schnittstelle diese Fehlermeldung:

Call to undefined function libxml_disable_entity_loader()

Die Schnittstelle ist dadurch nicht mehr verwendbar. Setzen Sie XML-RPC nicht ein, wird Ihr Geschäftsablauf zwar nicht gestört, doch es kann eine unschöne Fehlermeldung geben, die Angreifern auch mehr verrät, als sie sollte.

Update 14. Juli: wir haben von Fällen erfahren, in denen der Patch bei alten PHP-Versionen dazu führt, dass man sich nicht mehr in das Magento-Backend einloggen kann.

Sind Sie auf die XML-RPC-Schnittstelle angewiesen, kommen Sie um den Patch und somit eventuell um eine PHP-Aktualisierung nicht herum.

Falls Sie die XML-RPC-Schnittstelle nicht benötigen und nicht regulär patchen können, gibt es Workarounds:

  • Code in der indexAction() entfernen
    Sie können wie im Magento-Blog beschrieben den XML-RPC-Controller bearbeiten und den Code im Body der indexAction() auskommentieren/entfernen.
  • Anfragen direkt im Webserver umlenken
    Sie können auch – und das ist eine Methode, die mir persönlich besser gefällt – den Webserver anweisen, für XML-RPC-Anfragen eine „Seite nicht gefunden“-Anweisung zurück zu geben.
    Dazu setzen Sie in Ihrer vHost-Konfiguration bzw. htaccess-Datei die Zeile

    Auch für diesen Tipp geht mein Dank wieder an Tobi.

Bei den Workarounds handelt es sich um temporäre Maßnahmen, die wieder rückgängig gemacht werden sollten, wenn der Patch oder das Upgrade eingespielt werden konnten.

Ursache

Nachdem wir uns der Problembehebung gewidmet haben, wollen Sie wahrscheinlich wissen: wie kommt es zu dieser Sicherheitslücke?

Magento verwendet verschiedene Code-Bibliotheken, darunter auch das weit verbreitete Zend Framework (ZF). Das österreichische Unternehmen SEC Consult hat eine Schwachstelle in der XML-RPC-Komponente von Zend Framework identifiziert und die dahinter stehende Firma Zend am 18. Juni informiert. Der Fehler wurde innerhalb von 3 Stunden behoben. Bei solchen Vorfällen muss ein bestimmter Prozess eingehalten werden (Vorbereitung und Test neuer Softwareversionen, Vorbereitung der Sicherheitsmeldung etc.). Dieser wurde am 22. Juni abgeschlossen. Am darauf folgenden Montag, dem 25. Juni, wurde die neue Version und somit die Information über die Lücke veröffentlicht. (Falls Sie sich wundern: solange eine Lücke noch nicht im großen Rahmen bekannt ist, ist es besser, die Information erst an einem Arbeitstag bekannt zu geben. Die zuständigen Stellen können somit schneller reagieren als am Wochenende.)

Die eigentliche Schwachstelle befand sich somit lange Zeit unentdeckt in Zend Framework, nicht in Magento selbst. Solche Situationen können und werden leider immer wieder vorkommen, wenn eine Software andere Bibliotheken einbindet.

Beurteilung

Es bleibt eine weitere wichtige Frage:  ist Magento sicher?

Von der Veröffentlichung des ZF-Patches bis zur Identifizierung der Gefahr für Magento und der Herausgabe des Patches vergingen anderthalb Wochen. Das ist nicht katastrophal, auch kein Spitzenwert. Natürlich muss man hier aber einen kritischen Blick haben, da es sich um eine schwerwiegende Sicherheitslücke handelt. Da zählt jeder Tag, vielleicht jede Stunde. Bei „kleineren“ Sicherheitslücken wird man das eher auf die leichte Schulter nehmen können.

Für Magento Inc. und auch die Entwickler-Community wird der Vorfall ein Fingerzeig sein müssen, dass man in Zukunft die eingebundenen Bibliotheken noch besser im Auge behält. Was ich positiv bemerken möchte ist, dass die Community wie gewohnt sehr proaktiv und kooperativ gehandelt hat. Auch die offizielle Kommunikation von Magento fand ich gelungen. Die Meldung wurde über mehrere Kanäle publiziert und mit dem Blogpost konkrete Information und Handlungsweisen für verschiedene (auch veraltete) Magento-Versionen angeboten.

Zuletzt habe ich mit Bastian Ike bei der Konferenz „Meet Magento“ über das Thema Magento und Sicherheit gesprochen. Er ist in der Magento-Community als Sicherheitsexperte anerkannt und hat mir den Eindruck bestätigt, dass es sich bei Magento – gerade in den aktuellen Versionen – um eine sehr sichere Software handelt.

Feedback

Was mich nun interessieren würde:

  • Was ist Ihre Meinung zu der Sicherheitslücke an sich und der Art/Geschwindigkeit der Reaktion?
    (Basti, vielleicht willst du ja sogar etwas dazu sagen. ;-))
  • Konnten Sie Ihre Patches bereits erfolgreich durchführen?
  • Gibt es bekannte Fälle, bei denen diese Sicherheitslücke ausgenutzt wurde?

Ich freue mich über Ihre Kommentare.

12 Antworten

  1. Bastian Ike sagt:

    Moin,

    „Basti, vielleicht willst du ja sogar etwas dazu sagen“ – ja, warum nicht? 😉

    Zuerst einmal: ein gutes write-up zu der Lücke. Soweit kann ich sagen das ist alles korrekt, und der Artikel fasst das verständlich zusammen.

    Noch eine Anmerkung von mir:
    „“Worst Case” kommt es dazu, dass der Angreifer sich Zugangsdaten zu Datenbanken, FTP-Accounts, dem Server selbst oder zu externen Systemen verschaffen kann, mit denen der Webserver in Verbindung steht. Ob und wie sich diese Informationen ausnutzen lassen, hängt von der Konfiguration des jeweiligen Systems ab.“
    Die Lücke ist ohne Frage kritisch. Man kann beliebige Dateien auf dem Server auslesen (sofern man den Pfad zu der Datei kennt). Zugriff auf FTP-Accounts o.ä. wäre allerdings grob fahrlässig wenn der Administrator diese Passwort irgendwo plaintext speichert.
    Der einzig wirklich interessante Punkt ist bei Magento Installationen natürlich die Datei local.xml. Datenbankzugangsdaten sind, sofern kein Zugriff auf PhpMyAdmin besteht, meistens nicht so kritisch, da der Zugang zu MySQL sowieso nur durch den Host „localhost“ erlaubt sein sollte.
    Sehr interessant ist natürlich das Installationsdatum (ich kann leider nicht ausführen wieso…) sowie der secret_key der zur Verschlüsselung von u.a. Bankdaten genutzt wird.

    Daher sollte so oder so jeder Shop ASAP gepatched werden!

    Aber ansonsten: Top Artikel 😉

    Gruß, Basti

  2. Daniel Lang sagt:

    Danke für diese tolle Zusammenfassung. @Bastian: Na toll, jetzt _muss_ ich herausfinden warum das Installationsdatum interessant ist… 😉

  3. Jürgen Hauser sagt:

    Kommunikation mag für die Community Edition gelungen sein, aber ich als Enterprise Kunde wurde über keinen einzigen Kanal informiert, kein E-Mail, kein Anruf,nichts!

    • Stimmt, für das Geld einer Enterprise-Edition kann man sich mehr erwarten. Mal abwarten, ob zumindest eine Security-Mailing-Liste kommt.

  4. Giorgio Kastner sagt:

    Also die Seite eines unserer Kunden ist von der angesprochenen Sicherheistlücke betroffen. Wir haben jetzt schon etliche Dinge probiert und kommen aus dem Teufelskreis nicht mehr raus.
    Mittlerweile konnte die alte Version auf 1.7.0.2 upgedatet werden und diese läuft auch soweit.
    Allerdings wollten wir jetzt mal die FTP Zugänge mit einem neuen Passwort versehen aber das scheint komplett unmöglich da sich der Cache in Magento für: System (config.xml, local.xml) und Modul Konfigurationsdateien (config.xml).
    weder deaktivieren noch aktualisieren lässt und bei der Umstellung auf eine anderes Passwort und entsprechende Änderung in der local.xml die Seite einfach nicht mehr laufen will, da ja bekanntlich die Daten erstmal aus dem Cache genommen werden.
    Weiter ist jede Aktualisierung z.B. der deutschen Lokalisation über Magento Connect unmöglich, da diese immer mit einer Fehlermeldung: Exception during Cache and session cleaning
    quittiert wird und bei Rückkehr aus Magento Connect in den Admin-Bereich glatt überhaupt nichts mehr geht und man weder über das Fronten noch das Backend wieder auf die Seite kommt.
    Ich haben heute schon den den ganzen Tag damit verbracht den Fehler zu eliminieren, leider erfolglos und muss ständig auf den letzten Wiederherstellungspunkt zurück da die Seite ansonsten nicht mehr erreichbar ist. Und so wie diese jetzt ist landet die Seite mit Sicherheit wieder bei Google auf der Blacklist, da der Hacker ständig die .htaccess Datei umschreibt und somit alle Kundendaten abfängt.
    ich bin mit meinem Latein am Ende und habe kenne Ahnung mehr, was man jetzt noch tun kann.

    • Gehe in das Magento-Backend, deaktiviere alle Caches und führe „Magento-Cache leeren“ bzw. „Cache-Storage leeren“ aus (die Buttons heißen zumindest so ähnlich. ;-)) Lösche alle Dateien und Ordner unter var/cache/ sowie die Datei app/etc/use_cache.ser. Sind Caches wie APC oder memcached im Einsatz, kann man die auch noch einmal explizit über einfache Skripte löschen. Als Beispiel für APC: http://stackoverflow.com/questions/911158/how-to-clear-apc-cache-entries
      Eigentlich sollte dann da nichts mehr gecacht sein. Falls der Compiler aktiviert ist, sollte auch der deaktiviert und der Inhalt gelöscht werden. (Geht über shell/compiler.php oder das Backend.)
      Bist du sicher, dass ihr allgemein kein Problem mit den Datei-/Ordner-Rechten habt? Es klingt mir ein wenig danach. Und wenn bereits jemand eure .htaccess umgeschrieben hat, würde ich das Ding zuerst vom Netz nehmen und einer Sicherheitsüberprüfung unterziehen.
      Updates (über Magento Connect, oder besser noch ohne) würde ich nur in Entwicklungssystemen durchführen und dann die Änderungen ins Livesystem synchronisieren. Dadurch erspart man es sich auch, dem Webserver Schreibrechte auf Dateien und Ordner einzurichten, wenn das eigentlich gar nicht nötig ist.

  5. Giorgio Kastner sagt:

    Falls jemand Hilfe weiss, bitte, bitte melden.
    Vielleicht ist das noch wichtig. Die Fehlermeldung, die ich bekommen, wenn ich über Magento Connect ein Update z.B. der deutschen Lokalisierung mache ist folgender:

    Exception during cache and session cleaning: Error in file: „/html/magento/app/code/core/Mage/Directory/data/directory_setup/data-upgrade-1.6.0.0-1.6.0.1.php“ – SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry ‚default-0-general/region/display_all‘ for key ‚UNQ_CORE_CONFIG_DATA_SCOPE_SCOPE_ID_PATH‘

    • Vermeide es allgemein, Updates einzuspielen, wenn der Cache aktiviert ist. Das führt zu Problemen. Gerady Integrity-constraint-violation-Meldungen sind beliebt, wenn man ein Update mehrfach und/oder mit gecachten Inhalten laufen lässt.

  6. Giorgio Kastner sagt:

    Herzlichsten Dank für die schnelle Reaktion und die Tips.
    Leider ist in der Installation folgendes Problem:

    1. Wenn ich die Cache Einstellung für den Punkt KONFIGURATION deaktiviere steigt das System komplett aus und ich komme nicht mal mehr in das Backend rein.
    2. Wenn ich den Cache für den Punkt KONFIGURATION aktualisiere passiert das Gleiche.

    Es ist zum Mäuse melken und ich habe leider 0 Idee woran das liegt.

    • Überprüfe, ob Meldungen in var/log/system.log, var/log/exception.log oder im Verzeichnis var/report zu finden sind. Wenn nein: Dateien und Datenbank herunterladen, auf ein Entwicklungssystem packen, Entwickler-Modus und alle Fehlerausgaben sowie Logging aktivieren und dort durchtesten. Ich kann in dem Fall leider kein Patentrezept geben.

  1. 11.10.2012

    […] in vergangenen Versionen ein paar angreifbare Punkte (für den gravierendsten Fall siehe Kritische Sicherheitslücke in Magento). Zugleich müssen Entwickler beachten, dass sie mit ihren eigenen Modifikationen keine […]