xmlrpc.php Angriff auf WordPress Blog

Ein Webserver mit mehreren virtuellen Hosts reagierte sehr zäh bei Browser-Aufrufen und auch bei SSH-Login. Ein schneller Blick mit top zeigte eine ungewöhnlich hohe System-Last, und der Apache Server war auffällig häufig bei den Top-Prozessen.

Ein Blick auf die Apache access.log Dateien zeigte, dass ein bestimmter Vhost (auf dem WordPress läuft) mit POST Anfragen auf /xmlrpc.php bombardiert wurde und dies zu hoher Systemlast und langsamen Web-Server Antworten führte.

Als Sofortmaßnahme die IP des Angreifers an der vorgelagerten Firewall gesperrt, daraufhin ging die Systemlast auf normale Werte zurück. Dies ist die gründlichste Lösung dieses Problems: eine Abwehr mittels Web-Server Konfiguration oder mittels WordPress Plugin erfordert weitaus mehr Ressourcen (RAM, CPU), als ein IP-basiertes Blocken des Angreifers. Das Problem ist, eine gerade entdeckte IP dynamisch in das Firewall Blocken aufzunehmen. Klassischer Fall für IPS (Intrusion Protection Systems), hat aber nicht jeder (teuer und/oder komplex).

Das IP-Blocking verschaffte aber Zeit zu recherchieren, was genau das Problem ist und wie wir vorgehen sollten.

Was ist das Problem mit xmlrpc.php?

Es geht um “Password Guessing”, also den Versuch, einen Benutzernamen mit gültigem Passwort zu erraten, um mit diesen Rechten einen fremden Server für eigene Zwecke zu mißbrauchen. Kennt jeder Admin eines im Internet exponierten Servers, egal ob es um FTP, POP/IMAP, SMTP AUTH, Apache htaccess, PHPMyAdmin, WordPress usw geht.

XMLRPC steht für “Remote Procedure Calls over XML”. Das bedeutet, dass ein beliebiger Client im Internet remote eine Prozedur mit selbst definierten Parametern auf unserem WordPress ausführen kann, indem eine korrekt formatierte XML-Datei mit POST an unseren WordPress Server übergeben wird.

Falls die roten Lampen beim letzen Satz noch nicht angegangen sind: jeder beliebige Internet Nutzer kann ohne Authentifizierung die Prozedur “prüfe-password” etwa so aufrufen:

wp.getUsersBlogs("admin", "test")

und kann anhand der Antwort erkennen, ob das Passwort “test” korrekt ist oder nicht. Das ist optimal für “Password Guessing” und vermeidet sogar auffällige Aufrufe von wp-login.php.

Kollege Mike Kuketz hat eine lesenswerte Beschreibung des Problems und bringt das auf den Punkt:

Die XMLRPC-Schnittstelle stellt ein[e] … fragwürdige Design-Entscheidungen dar …. Aufgrund ihres Funktionsumfangs … ist die xmlrpc.php nicht nur eine nützliche Bereicherung im Blogger-Alltag, sondern stellt auch für Angreifer ein interessantes Angriffsziel dar.

Dieses Angriffsziel ist ein Problem, weil die angegriffenen Server signifikante Last- und Stabilitäts-Probleme zeigen. Diese Schnittstelle sollte deaktiviert werden.

Seit WordPress 3.5.1 ist diese Schnittstelle per Default aktiviert, um eine API für Fremdsoftware anzubieten (etwa zum Publizieren von Beiträgen aus MS Word oder von einem iPhone), oder für Erweiterungen wie JetPack. Manche WordPress Plugins könnten nicht mehr wie erwartet funktionieren, dies sollte jeder Admin entsprechend prüfen.

Wir empfehlen, den Zugriff auf /xmlrpc.php abzuschalten. Dies kann auf 3 Arten geschehen:

  • IP-Blocking per Firewall
  • Webserver Blocking (zB Apache/htaccess)
  • WordPress Blocking (Plugin Disable XML-RPC)

Diese Techniken können unabhängig oder im Kombination (buzzword multi-layer security) verwendet werden.

IP-Blocking per Firewall

Dies ist die effizienteste Variante, da eine unerwünschte Anfrage gar nicht erst den Webserver erreicht und dort Ressourcen verbraucht. Der Nachteil ist, dass man die IP-Adresse des Angreifers mühselig aus den Logs extrahieren und manuell in der Firewall eintragen muss, oder ein dynamisches Firewalling erforderlich ist, welches eigene Probleme haben könnte (Stichwort false-positives). Dynamisches Firewalling wird in einem späteren Artikel beschrieben.

Webserver Blocking

In einer Apache Konfigurationsdatei oder .htaccess Datei kann mit der folgenden Anweisung der Zugriff auf xmlrpc.php und andere sensitive Dateien unterbunden werden:

# Disallow access to important WordPress files
<FilesMatch "(^\.|wp-config\.php|xmlrpc\.php)">
  Order deny,allow
  Deny from all
</FilesMatch>

Ähnliche Lösungen gibt es für nginx und andere Webserver.

Apache mod_security bietet einen regelbasierten Ansatz, um unerwünschte Zugriffe zu sperren. Es ist allerdings recht komplex und muss gut verstanden werden, um false-positives zu vermeiden und damit legitime Anwender auszusperren.

WordPress Blocking

Als letzte Verteidigungslinie kann es sinnvoll sein, ein WordPress Plugin zu installieren, das den Zugriff auf xmlrpc.php unterbindet. Mit einer WordPress Plugin-Suche nach “disable xmlrpc” finden sich etliche Plugins, wir benutzen “Disable XMLRPC”.

WooCommerce variables Produkt, Probleme bei vielen Varianten

WooCommerce ist ein Shop-System Plugin für WordPress. Variable Produkte in WooCommerce sind Produkte, die in verschiedenen Ausführungen verfügbar sind.

Etwa ein bestimmtes T-Shirt Motiv, das in 9 Grössen und Zweifarben-Design erhältlich ist. Jede der beiden Farben kann frei aus 40 verschiedenen Farbtönen gewählt werden. Dadurch ergibt sich für dieses eine T-Shirt Produkt die Menge von 14.400 möglichen Produktvarianten (9 Größen * 40 Farbe1 * 40 Farbe2).

In WooCommerce würde dieses T-Shirt Produkt als “variables Produkt” definiert, und unter “Eigenschaften” die 9 Größen und die je 40 Farbe1 und Farbe2 eingetragen. Anschliessend kann unter “Varianten” ausgewählt werden “Generiere Varianten aus allen Attributen”, dies erzeugt automatisch alle kombinatorisch möglichen Varianten.

Dies ist sehr praktisch und funktioniert einwandfrei, solange die Menge der möglichen Varianten klein ist (etwa 3 Größen * 3 Farbe1 * 3 Farbe2 = 27). Mit 14.400 Varianten funktioniert das alles andere als gut. Das ist mathematisch die kombinatorische Explosion, die irgendwo im WooCommerce Programm-Code zuschlägt.

Die “normale” Vorgehensweise

Die sehr nützliche Option “Generiere Varianten aus allen Attributen” ist per Default auf 50 Varianten pro Durchlauf beschränkt. Dies geschieht sicher aus gutem Grund, je mehr Varianten in einem Rutsch erzeugt werden, desto mehr Speicher und Ausführungszeit werden benötigt, und das kann auf schwach ausgestatteten Servern zu Ausführungsfehlern und evtl. Dateninkonsistenz führen.

Wenn unser Besipiel T-Shirt 4 Größen * 4 Farbe1 * 4 Farbe2 = 64 Varianten hat, werden mit dem Aufruf von “Generiere Varianten aus allen Attributen” die ersten 50 Varianten erzeugt. Ein erneuter Aufruf erzeugt dann die restlichen 14. Soweit gut.

14.400 Varianten in 50er Häppchen zu erzeugen erfordert die Geduld für 288 einzelne Klicks. Must be a better way..

Hacking WooCommerce

Ein wenig Google-Suche und WooCommerce Code lesen führt zu der Variable WC_MAX_LINKED_VARIATIONS, welche bestimmt wie viele Varianten pro “Generiere Varianten” Aufruf erzeugt werden (Default 50). Vorausgesetzt dass die PHP Variablen memory_limit und max_execution_time großzügig gesetzt sind, kann die Variable WC_MAX_LINKED_VARIATIONS deutlich erhöht werden. Ich habe sie auf 3000 gesetzt, indem ich die folgende Zeile systemweit zu wp-config.php hinzugefügt habe.

define( 'WC_MAX_LINKED_VARIATIONS', 3000 );

Das hat schon mal 3.000 von 14.400 Varianten erzeugt und etwa 30min gedauert. Die nächten Portionen von 3.000 Varianten dauerten zunehmend länger, aber mit 5 Klicks und alle 1-2h nachschauen waren alle Varianten erzeugt. Übrigens meldet das Popup-Fenster weiterhin “Sie erzeugen 50 Varianten, weiter?”, obwohl tatsächlich 3.000 pro Durchlauf erzeugt werden.

Funktioniert leider nicht

Alle Varianten waren im Produkt-Menu sichtbar und konnten bearbeitet werden (z.B. Preis für alle setzen). Sie tauchten auch korrekt auf der für Kunden sichtbaren Produkt-Seite auf und konnten mit HTML Auswahlfeldern gewählt werden.

Allerdings erschien nach jeder ausgewählten Farbkombination nicht wie erwartet der Produkt-Preis, sondern ein Hinweis “dieses Produkt ist nicht lieferbar”. Auch nach expliziter Prüfung, ob für einzelne Varianten der Preis gesetzt und die Variante aktiv ist sowie ob Bestandsmengen Einstellungen im Weg sind, liess sich dieses Problem nicht lösen. Eine Google-Suche lieferte einige, teils obskure Ideen, aber ebenfalls keine funktionierende Lösung.

Die grosse Menge von Varianten scheint irgendwelche Programm-Limits zu sprengen.

Update 13.2.2016: Update auf WooCommerce 2.5.2 behob das Problem

Das scheint ein WooCommerce Bug gewesen zu sein, nach Update auf das aktuelle WooComerce 2.5.2 funktionierte alles genau wie es sollte.