Seit der WordPress-Version 3.5 ist die XML-RPC-Schnittstelle standardmäßig aktiviert. Das wäre nicht weiter schlimm, wenn WordPress nicht das beliebteste Content Management System der Welt wäre. Denn die Schnittstelle stellt nicht nur nützliche Funktionen bereit, sondern dient auch als ein wichtiges Angriffsziel für Hacker. Die Angreifer nutzen immer mehr die xmlrpc.php für ihre Brute-Force-Angriffe gegen WordPress, weil ein Angriff gegen diese Schnittstelle wesentlich effizienter und mit weniger Aufwand als andere Methoden verbunden ist.
Dazu dient die XML-RPC-Schnittstelle
Die Schnittstelle ist ein nützliches Werkzeug für die Verwaltung von Inhalten. Sie dient dazu, dass man mittels der Desktop– und der Smartphone-Apps die Website verwalten und Artikel verfassen kann. Ebenso kümmert sie sich um Pingbacks. 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. Unterstützt werden neben der WordPress API auch die Blogger API, die metaWeblog API, die Movable Type API, und die Pingback API.
Die meisten Nutzer brauchen diese Schnittstelle jedoch nicht, weil sie ihre Artikel direkt in WordPress verfassen. Und auf die Pingbacks von anderen Blogs könnte man durchaus verzichten.
Deshalb ist die xmlrpc.php ein Sicherheitsrisiko
Passwortgeschützte Bereiche sind ein beliebtes Angriffsziel. Auch die xmlrcp.php gehört zu diesen Bereichen. Da jedoch immer mehr Blogger den Adminbereich ihrer Website absichern, fokussieren sich die Angreifer nun auf die Verwaltungs-Schnittstelle und lassen ihre Brute-Force-Angriffe auf dieses Ziel laufen. Problematisch ist hierbei, dass sich die Angriffe auf die XML-RPC-Schnittstelle wesentlich effektiver ausführen lassen, als es bei einem Angriff auf den Adminbereich von WordPress der Fall wäre.
Mit den geeigneten Tools lassen sich bei nur einer Anfrage an die Schnittstelle unglaubliche 500 Passwörter unterbringen. Die Datei ermöglicht es den Angreifern, über Funktionsaufrufe an wp.getUsersBlogs oder wp.getComments Kombinationen von Benutzernamen und Passwort zu erproben. Sobald ein Hacker Benutzername und Passwort sendet, wird die xmlrpc.php entsprechende Rückmeldung geben, ob die Kombination korrekt ist oder nicht.
Das macht das Hacken einer WordPress-Installation über diesen Weg sehr effektiv und aussichtsreich. Somit stellt die zumeist ungenutzte Schnittstelle ein erhebliches Sicherheitsrisiko dar und sollte zügig abgeschaltet werden. Ein weiterer, eher genereller Vorteil des Abschaltens nicht genutzter Funktionen ist die Erhöhung der Performance einer Website.
Die XML-RPC-Schnittstelle abschalten
Seit der WordPress-Version 3.5 ist die XML-RPC Schnittstelle standardmäßig aktiviert. Früher liess sie sich noch ganz einfach deaktivieren, heute ist dies nur noch über Umwege möglich. Doch diese Umwege sind nicht zu schwierig. Insgesamt sind drei Schritte nötig, um die Schnittstelle komplett abzuschalten und sämtliche Anfragen an sie zu unterbinden.
Teil eins: Die Schnittstelle über einen Filter abschalten
Folgender Code muss in die functions.php des Themes eingetragen werden.
Ein Klick auf die Grafik öffnet das Gist bei GitHub
Die Schnittstelle ist nun komplett deaktiviert. Allerdings erscheint die Schnittstelle noch im HTTP-Header der Website.
Teil 2: Den HTTP-Header Eintrag deaktivieren
Was noch angezeigt wird, kann auch angefragt werden. Das stellt vielleicht kein Sicherheitsrisiko mehr dar, allerdings kann es durchaus die Performance der Website beeinträchtigen. Daher muss dieser Eintrag entfernt werden. Auch dieser Code-Schnipsel kommt in die functions.php eures Themes. Hier der vollständige Code mit dem Filter aus dem ersten Teil:
Ein Klick auf die Grafik öffnet das Gist bei GitHub
Teil 3: Die xmlrpc.php via .htaccess blocken
Solange unser WordPress noch Zugriff auf die xmlrpc.php hat, entstehen natürlich versteckte Zugriffe auf die Datei. Das kommt der Performance der Website nicht gerade zugute, also sollte die Datei noch einmal per .htaccess-Datei geblockt werden.
Wichtig vorab: vor jeder Änderung an der .htaccess, bitte ein Backup der Datei erstellen!
Ein Fehler bei einer Änderung der Datei kann eine nicht mehr funktionierende Website zur Folge haben. Zu beachten gilt ebenfalls, dass die .htaccess unter Mac OS X als Systemdatei gilt, aufgrund des Punktes vor dem Dateinamen. Das sorgt dafür, dass die Datei nicht angezeigt wird, sobald sie sich auf dem Desktop befindet. Man kann die versteckten Dateien entweder über das Terminal oder über ein Dashboard-Widget anzeigen lassen.
Folgenden Eintrag bitte in die .htaccess-Datei im Hauptverzeichnis der WordPress-Installation kopieren. Der Eintrag sollte oberhalb von #Begin WordPress stehen. Die Datei lässt sich mit einem Texteditor wie Notepad oder TextEdit öffnen und bearbeiten.
Das Hauptverzeichnis einer WordPress-Installation
Ein Klick auf die Grafik öffnet das Gist bei GitHub
Fazit
Diese drei kleinen Schritte haben WordPress wesentlich sicherer gemacht. Ein Angriff über die xmlrpc.php ist nun unmöglich, auch Anfragen an die Datei werden nicht mehr beantwortet, was zudem der Performance zuträglich ist. Allerdings sollte klar sein, dass WordPress nun keine Pingbacks mehr empfängt und sich natürlich auch nicht mehr mit Apps jeglicher Art verwalten, beziehungsweise füllen lässt. Doch das dürfte nur ein kleiner Wermutstropfen sein, der den erheblichen Sicherheitsgewinn nicht schmälert.
Quelle: WordPress: Angriffe auf die XMLRPC-Schnittstelle (xmlrpc.php) unterbinden
(dpe)
12 Antworten zu „WordPress-Sicherheit: Die XML-RPC-Schnittstelle abschalten“
— was ist Deine Meinung?
Hallo,
ich bin bekennender Fan und dr.web und die e-books haben mir schon viele graue Haare erspart.
Aber hier noch ein paar Fragen:
Besteht das Problem mit der sml-rpc-Schnittstelle etwa immer noch??
Und müssen zwingend alle drei Schritte durchgeführt werden oder ist Teil 3 via .htaccess ggf. ausreichend?
Teil 1 + 2 _ einfügen von Code in die functions.php des Themes – bedeutet dies, immer wenn ich das Theme wechsele muss ich ans einfügen des Codes denken?
Viele Grüße
Antje
natürlich xml-rpc …
1 Beispiel:
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.
Sogar inklusive der Hochkommatas – das nenn ich Copy&Paste. ^^
Moin,
ja, da ist mir wohl ein Satz durchgerutscht. Soll so nicht sein, kann aber mal passieren. Trotz des Checks mit Copyscape. Das tut der Qualität des Artikels jedoch keinen Abbruch, denn alle anderen Sätze stammen eindeutig von mir. Sorry, doch wer viel arbeitet, macht auch mal Fehler. Auch Du machst Fehler in deinem Job. So ist das nun mal. Und nur neue und noch niemals irgendwo publizierte Artikel über WordPress zu schreiben ist ein Ding der Unmöglichkeit. Und nun entspann Dich doch einfach mal.
Lustig, wenn sogar ganze Sätze von anderen Blogs kopiert werden. Der „original“ Beitrag ist jedenfalls hier zu finden: https://www.kuketz-blog.de/wordpress-angriffe-auf-die-xmlrpc-schnittstelle-xmlrpc-php-unterbinden/
😉
Dann wäre ich an Belegen interessiert. Wir verwenden Copyscape und konnten keinerlei Kopiererei feststellen. Das Thema haben wir natürlich nicht erfunden. Das waren die Jungs von Automattic 😉
Beispiel kommt:
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.
Sogar inklusive der Hochkommatas – das nenn ich Copy&Paste. ^^
Danke für die Anleitung.
Ich hab jetzt noch eine andere Frage. Kann es sein das Plugins wie Limit Login Attempts das schon verhindern oder Caching Tools wie W3 Total Cache? Weil wenn ich Seiten von mir überprüfe bekomme ich keinen X-Pingback angezeigt im Header Http.
Kann ich es irgendwie testen ob es geklappt hat? Außer mit Chrome auslesen?
Schöne Grüße
Stefan
Ist meine Frage so lächerlich, dass man nicht mal eine kurze Antwort bekommt?
Sorry für die späte Antwort, Stefan.
Nein, Plugins wie Limit Login Attempts oder W3 Total Cacher verhindern das nicht. Dann wird halt der Header nicht angezeigt, weil das vielleicht auf Deinem Server so geregelt ist. Das heißt jedoch nicht, dass die Schnittstelle bereits abgeschaltet ist. Noch ein Wort zu Limit Login Attempts und ähnlichen Kram: Plugins dieser Art schaffen keinerlei Sicherheit, weil sie nur eine IP blocken können. Ein richtiger Angriff findet mit hunderten IPs statt.
Danke für die Antwort, dann muss ich da noch mal meine andere Seiten überprüfen die auf anderen Servern liegen.
Zu dem PlugIn Limit Login Attempts bin ich ein bisschen verwirrt, ich hab mir das eigentlich nur installiert weil es hier empfohlen wurde, sogar von ihnen.
Ebenso versteh ich nicht was sie meinen mit, es wird nur eine IP geblockt?
Wenn ich in das Plugin schaue sehe ich dort jede IP Adresse die gesperrt wurde.
Bedeutet das, dass diese nur da stehen und nicht mehr geblockt werden oder wie muss ich das verstehen?
Schöne Grüße
Stefan
Der Link noch http://www.drweb.de/magazin/eine-wordpress-installation-korrekt-absichern/