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”.