WordPress: Angriffe auf die XMLRPC-Schnittstelle (xmlrpc.php) unterbinden

1. Evolution der Angreiferxmlrpc

Aufgrund ihrer hohen Verbreitung stellt die WordPress-Plattform ein äußerst beliebtes Angriffsziel dar. Angreifer haben häufig leichtes Spiel, wenn sie bspw. Schwachstellen in veralteten Plugins oder schlampig programmierten Themes ausnutzen. Doch auch die WordPress-Entwickler selbst erhöhen durch fragwürdige Design-Entscheidungen das Risiko für die Plattform.

Bruteforce-Angriffe auf den Admin-Bereich sind die meisten Blog-Betreiber schon gewohnt und behelfen sich mit Security-Plugins oder durch Restriktionen in der .htaccess Datei. Doch noch immer wird dabei die XMLRPC-Schnittstelle vernachlässigt, die zwei Hauptfunktionen erfüllt: Die Pingback-API ermöglicht eine Art »Vernetzung« zwischen den Blogs und dient gleichzeitig als Schnittstelle, um WordPress über externe Programmen verwalten zu können.

In der Artikelserie WordPress absichern habe ich bereits vor über zwei Jahren Tipps und Maßnahmen zusammengefasst, die die Wahrscheinlichkeit eines erfolgreichen Angriffs deutlich reduzieren. Die xmlrpc.php habe ich im 5. Teil nur unwahrnehmbar im Zusammenhang mit einem Zugriffsschutz für bestimmte WordPress-Dateien gestreift. In Anbetracht der steigenden Angriffsversuche auf die xmlrpc.php wird es Zeit für ein kleines Update …

2. XMLRPC-Schnittstelle deaktivieren

Die XMLRPC-Schnittstelle stellt eines jener fragwürdigen Design-Entscheidungen dar, die ich bereits in der Einleitung kurz erwähnt hatte. Aufgrund ihres Funktionsumfangs (Blogger API, metaWeblog APIMovable Type APIPingback API) ist die xmlrpc.php nicht nur eine nützliche Bereicherung im Blogger-Alltag, sondern stellt auch für Angreifer ein interessantes Angriffsziel dar. Bevor jemand bspw. über einen Weblog Client Zugriff auf WordPress erhält, findet zunächst eine Authentifizierung bzw. ein Abgleich von Benutzername und Passwort statt. Dies kennen wir vom Admin-Bereich, wenn wir über den Webbrowser die wp-login.php unseres Blogs aufrufen. Auch dort wird zunächst ein Benutzername und Passwort abgefragt, bevor der Zugriff auf das Backend bzw. den Admin-Bereich möglich ist.

2.1 Das Problem

Passwortgeschützte Bereiche sind ein beliebtes Angriffsziel. So ist es nicht verwunderlich, dass viele Blogger die wp-login.php bzw. den Admin-Bereich entsprechend abgesichert haben. Doch das greift in der Praxis leider zu kurz, denn über die XMLRPC-Schnittstelle lässt sich ebenso ein Zugriff auf den Blog realisieren. Angreifer fokussieren ihre Angriffe daher zunehmend auf die xmlrpc.php. Mit geeigneten Tools (die ich jetzt nicht verlinke) sind Bruteforce-Angriffe nicht nur weiterhin möglich, sondern -man glaubt es kaum- auch noch effizienter durchführbar. Bis zu 500 Passwörter lassen sich in einer Anfrage an die xmlrpc.php unterbringen und reduzieren den zeitlichen Aufwand damit erheblich, irgendwann auf die korrekten Login-Daten zu stoßen. Selbst aktuelle WordPress-Versionen (4.3.1) sind davor nicht geschützt.

Ursache dieses Problems ist die Implementierung der WordPress XMLRPC-Schnittstelle, die es Angreifern ermöglicht über Funktionsaufrufe an wp.getUsersBlogs oder wp.getComments Kombinationen von Benutzernamen und Passwort zu erproben. Sobald ein Angreifer Benutzername und Passwort sendet, wird die xmlrpc.php entsprechend Rückmeldung geben, ob die Kombination korrekt ist oder nicht.

<methodCall><methodName>wp.getUsersBlogs</methodName><params><param><value>
 <string>admin</string></value></param>
 <param><value><string>password</string></value></param></params>
</methodCall>

WordPress auf Schwachstellen und Konfigurationsfehler prüfen

Für Deine WordPress-Installation habe ich ein spezielles Leistungspaket im Angebot:
  • Scan Deiner WordPress-Installation auf Schwachstellen
  • Auswertung und Beurteilung der gefundenen Schwachstellen
  • Auf Basis der Ergebnisse erhälst Du von mir individuelle Maßnahmenempfehlungen zur Behebung und Absicherung

Wenn du Deine WordPress-Installation nachhaltig absichern möchtest, kannst Du mich gerne kontaktieren.

Gut zu wissen: Sicherheit erlangst Du nicht durch die Installation unzähliger Security-Plugins, sondern durch eine saubere Konfiguration, stetige Updates und proaktive Maßnahmen zur Absicherung. Kontakt aufnehmen

2.2 Die Lösung(en)

Apache Zugriffsschutz für die xmlrpc.php und weitere »interessante« Informationen:

# Bis einschließlich Apache 2.3
# Disallow access to important files
<FilesMatch "(^\.|wp-config\.php|xmlrpc\.php|(?<!robots)\.txt|(liesmich|readme)\.*)"> 
   Order deny,allow 
   Deny from all 
</FilesMatch>

# Ab Apache 2.4
# Disallow access to important files
<FilesMatch "(^\.|wp-config\.php|xmlrpc\.php|(?<!robots)\.txt|(liesmich|readme)\.*)">
   Require all denied
</FilesMatch>

nginx Zugriffsschutz für die xmlrpc.php und weitere »interessante« Informationen:

# Disallow access to important files
location ~* (/\.|wp-config\.php|xmlrpc\.php|(?<!robots)\.txt|(liesmich|readme).*) {
   return 444;
}

Wer partout nicht auf die xmlrpc.php verzichten möchte, um bspw. weiterhin über externe Programme (Weblog Client) seinen Blog zu managen, der findet im Artikel »Serverseitiger Schutz – WordPress absichern Teil5« weitere Hinweise.

Hilf mit die Spendenziele zu erreichen!

Unabhängig. Kritisch. Informativ. Praxisnah. Verständlich.

Die Arbeit von kuketz-blog.de wird vollständig durch Spenden unserer Leserschaft finanziert. Sei Teil unserer Community und unterstütze unsere Arbeit mit einer Spende.

Mitmachen ➡

2.3 Weitere Maßnahmen

Zusätzlich lassen sich noch weitere Maßnahmen ergreifen, wie bspw. die vollständige Deaktivierung der XMLRPC-Schnittstelle über die functions.php:

/* Disable XMLRPC */
add_filter( 'xmlrpc_enabled', '__return_false' );

Wer dann noch möchte, dass der XMLRPC Tag aus dem HTML-Header verschwindet, kann zusätzlich folgende Änderung an der functions.php vornehmen:

/* Remove XMLRPC, WLW, Generator and ShortLink tags from header */
remove_action('wp_head', 'rsd_link');
[...]

3. Fazit

Angreifer finden immer einen Weg. Doch mit der Umsetzung bzw. dem Schutz der XMLRPC-Schnittstelle endet zumindest dieser Versuch in einer Sackgasse. Mit der Umsetzung dieser Maßnahme erreiche ich bei meinen Kunden eine deutliche Reduzierung der Serverlast und sorge gleichzeitig für eine Erhöhung der Sicherheit. Man könnte auch sagen: Zwei Fliegen mit einer Klappe geschlagen.

Wer sich für Angriffe auf die WordPress-Plattform interessiert, dem sei der Artikel »Hacking WordPress – Ein Blick hinter die Kulissen« empfohlen. Dort reiße ich kurz an, wie ein Angreifer vorgeht, wenn er es auf eine WordPress-Installation abgesehen hat.

In zukünftigen Versionen sollten die WordPress-Entwickler diese »Schwachstelle« endlich adressieren und eine Funktionstrennung innerhalb der xmlrpc.php vornehmen. Anstatt neuen Funktionsumfang zu implementieren, sollten bestehende Kinderkrankheiten angegangen und nachhaltig korrigiert werden.

Bildquellen:

WordPress: WordPress, Free License
Schild: Shaitaka, Creative Commons CC0

Über den Autor | Kuketz

Mike Kuketz

In meiner freiberuflichen Tätigkeit als Pentester / Sicherheitsforscher (Kuketz IT-Security) schlüpfe ich in die Rolle eines »Hackers« und suche nach Schwachstellen in IT-Systemen, Webanwendungen und Apps (Android, iOS). Des Weiteren bin ich Lehrbeauftragter für IT-Sicherheit an der Dualen Hochschule Karlsruhe, sensibilisiere Menschen in Workshops und Schulungen für Sicherheit und Datenschutz und bin unter anderem auch als Autor für die Computerzeitschrift c’t tätig.

Der Kuketz-Blog bzw. meine Person ist regelmäßig in den Medien (heise online, Spiegel Online, Süddeutsche Zeitung etc.) präsent.

Mehr Erfahren ➡

SpendeUnterstützen

Die Arbeit von kuketz-blog.de wird zu 100% durch Spenden unserer Leserinnen und Leser finanziert. Werde Teil dieser Community und unterstütze auch du unsere Arbeit mit deiner Spende.

Folge dem Blog

Wenn du über aktuelle Beiträge informiert werden möchtest, hast du verschiedene Möglichkeiten, dem Blog zu folgen:

Bleib aktuell ➡


Diskussion

6 Ergänzungen zu “WordPress: Angriffe auf die XMLRPC-Schnittstelle (xmlrpc.php) unterbinden”

  1. Comment Avatar Hannes sagt:

    Nur eine kleine Anmerkung: Fehlt in der FilesMatch-Direktive oben nicht die xmlrpc\.php Bedingung?

  2. Comment Avatar Jan sagt:

    Kann man die xmlrpc.php auch einfach umbenennen oder gar löschen?
    Ich brauche sie nicht.
    Sicherlich wird sie aber bei einer Systemaktualisierung von WP wieder installiert?

    • Comment Avatar Mike Kuketz sagt:

      Hallo Jan,
      nein das ist keine gute Idee. Wenn du die Funktionalität nicht benötigst, dann solltest du den Zugang auf die xmlrpc.php wie dargestellt untersagen.

      • Comment Avatar Dietmar sagt:

        Hallo Mike,

        da würde ich gerne nachhaken. Mir ist klar, dass es keine gute Idee ist die xmlrpc.php einfach zu löschen, da sie mit dem nächsten Update wieder kommt. Ich hatte das bei mir trotzdem gemacht. Obwohl die xmlrpc.php nicht vorhanden war ist mein Server immer wieder in die Knie gegangen.
        (Den Link im Head des Templates: hatte ich vergessen zu entfernen! Grober Fehler von mir! Ich vermute darum ging es immer wieder rund ;-)

        Nur weil die Angreifer eine nicht existierende Datei aufgerufen haben, geht mein Server in die Knie? Das könnten sie dann ja bis in alle Ewigkeit machen. Ich frage mich jetzt ob eine Sperrung per .htaccess – wie von dir vorgeschlagen – für die Ressourcen (CPU Last) des Servers schonender wäre. Was meinst du?
        a) Sperrung per htaccess und Angreifer wird von .htaccess geblockt Ressourcen schonender, oder
        b) Löschung und Aufruf einer nicht existierender Datei durch Angreifer Ressourcen schonender?

        Deine Meinung würde ich gerne hören.

        Danke im Voraus.

        • Comment Avatar Mike Kuketz sagt:

          Ob der Server nun einen Error-Code 404 (Not Found) oder Error-Code 401 (Unauthorized) zurückliefert sollte eigentlich keinen Unterschied machen.

          Man kann da aber durchaus noch weitere Maßnahmen ergreifen. So lässt sich bspw. mit fail2ban die anfragende IP-Adresse für eine gewisse Zeit sperren, wenn sie sich »auffällig« verhält.

HilfeWenn du konkrete Fragen hast oder Hilfe benötigst, sind das offizielle Forum oder der Chat geeignete Anlaufstellen, um dein Anliegen zu diskutieren. Per E-Mail beantworte ich grundsätzlich keine (Support-)Anfragen – dazu fehlt mir einfach die Zeit. Kuketz-Forum

Abschließender Hinweis

Blog-Beiträge erheben nicht den Anspruch auf ständige Aktualität und Richtigkeit wie Lexikoneinträge (z.B. Wikipedia), sondern beziehen sich wie Zeitungsartikel auf den Informationsstand zum Zeitpunkt des Redaktionsschlusses.

Kritik, Anregungen oder Korrekturvorschläge zu den Beiträgen nehme ich gerne per E-Mail entgegen.