(C) 2009 - 2014 by Mourad Louha · Alle Rechte vorbehalten

Gegenmaßnahmen zum Angriff auf die WordPress XML-RPC-Funktionen

In der zweiten Juli-Woche 2014 wurde mein Server Ziel von Angriffen, der sich primär auf die XML-RPC-Schnittstelle der auf dem Server eingerichteten WordPress Blogs konzentrierten. Zudem traten ebenfalls gehäuft Zugriffsversuche auf die Anmeldeadressen meiner Websites auf. Im Visier standen beispielsweise die Subdomains zum Excel-Translator oder zum Excel-Wiki.

Die XML-RPC-Schnittstelle in WordPress dient dazu, um den Blog mit externen Programmen verwalten bzw. mit ihm von außen kommunizieren zu können. Microsoft Word verwendet beispielsweise diese Schnittstelle, wenn mit Word ein Blog-Artikel erstellt wird. Auch Anwendungen für das Smartphone, wie z.B. WordPress for Windows Phone, verwenden die Schnittstelle. Die Schnittstelle dient zudem auch dazu, dem Blog Benachrichtigungen in Form von Pingbacks senden zu können. Die XML-PRC-Schnittstelle ist seit der Version 3.5 von WordPress standardmäßig aktiv und lässt sich anhand der Oberfläche nicht abschalten.

Folgende Abbildung zeigt eine beispielhafte Auswertung der Zugriffe innerhalb eines Tages und für drei ausgewählte Subdomains vom Excel-Translator. In WordPress wird die XML-RPC-Schnittstelle anhand der Datei xmlrpc.php zur Verfügung gestellt. Die Datei ist im Wurzelverzeichnis jeder WordPress-Installation zu finden. Die Zugriffe fanden nicht konstant verteilt über den Tag statt, sondern bewegten sich innerhalb eines Zeitfensters von ein paar Stunden pro Tag, was den Server dann ziemlich beschäftigte.

Auswertung der Zugriffe auf die XML-RPC-Funktionen

Eine Auswertung meiner Log-Dateien zeigte, dass bei den Angriffen zum überwiegenden Teil die Kennung „Mozilla/4.0 (compatible; Win32; WinHttp.WinHttpRequest.5)“ als Browserkennung übermittelt wurde. Eine Internet-Recherche zu der Kennung ergab einige Treffer und die von mir konsultierten Websites sind sich einig, dass der Absender der Kennung nichts Gutes im Schilde führt.

Angriffserkennung

Zunächst war mir der Angriff nicht aufgefallen, denn ich bin nicht konstant auf den Websites aktiv. Erst als ich über den Tag verteilt im Excel-Wiki neue Funktionen testete, bemerkte ich, dass die Website recht langsam reagierte und manchmal komplett aussetzte. Ein Testaufruf weiterer Websites auf dem Server ergab, dass sich die meisten so verhielten. Das Problem bezog sich somit nicht nur auf das Wiki. Eine Rückfrage bei meinem Provider ließ zunächst auf ein Problem mit einem WordPress Plug-In schließen. Das Plug-In, welches über mehrere Domains verteilt installiert ist und WordPress Ereignisse wie beispielsweise Login-Versuche protokolliert, lief Amok und kam mit seinen internen mySQL-Abfragen nicht mehr nach.

Das Plug-In lief aber bis dato einwandfrei. Zwar wurde es vor kurz vor dem Angriffszeitpunkt aktualisiert, dennoch sprach nichts für eine Fehlfunktion. Ich habe mich dann mit dem Entwickler des Plug-Ins in Verbindung gesetzt, um nachzufragen, worin die Ursache des Problems liegen könnte. Fazit war, dass die Zahl der Anfragen ungewöhnlich hoch sein müsste und da diese mitprotokolliert würden, ein entsprechender Ressourcenverbrauch zustande käme. Die Anzahl der Anfragen überprüfte ich anschließend anhand des vom Provider angebotenen Web-Statistik-Tools und danach in den Rohdaten der Logfiles. Ein Auswertetool, wie beispielsweise Piwik oder Google Analytics hilft hier nicht weiter, denn dieses filtert solche Anfragen schon vorher heraus, so dass man diese nicht sieht.

Nachdem ich nun relativ sicher war, dass es sich um einen Angriff handeln musste, ging ich erstmal auf Recherche nach Gegenmaßnahmen, zumal ich kein Sicherheitsexperte bin. So berichteten bereits einige Blogger über ähnliche Angriffe; bei manchen fanden diese bereits März 2014 statt. Die meisten Gegenmaßnahmen, die ich im folgenden Abschnitt beschreibe, entstammen der Blog-Artikel in Deutsch und Englisch, die ich am Ende des Artikels verlinkt habe.

Gegenmaßnahmen

Die folgende Gegenmaßnahmen beziehen sich auf einen Server, wo ein Zugriff per FTP auf die Dateien des Servers möglich ist. Gegebenenfalls lässt sich nicht jede Maßnahme umsetzen, da es ja auch Unterschiede zwischen den Providern und Paketen gibt.

Die erste Frage, die ich mir stellte war, brauche ich überhaupt die XML-RPC-Schnittstelle in WordPress? Die Antwort ist recht einfach: Nein, denn ich benutze weder externe Programme zum Erstellen von Beiträgen, noch verwalte ich meine Blogs über das Mobiltelefon. Und, Pingbacks sind beispielsweise für den Excel-Translator nicht notwendig.

Um nur Pingbacks in WordPress abzuschalten, kann in die Datei functions.php des aktiven WordPress-Themes folgender Code-Abschnitt am Ende der Datei hinzugefügt werden. Die Datei befindet sich im Verzeichnis „wp-content/themes/name_des_themes“ des aktiven Themes.

Falls das WordPress Theme mal geändert wird, muss die Anweisung allerdings in das neue Theme übernommen werden. Auch ein Update des Themes kann dazu führen, dass die functions.php vom Update überschrieben wird. Da ich mir aber eine lokale Textdatei angelegt habe und dort jegliche Änderungen und Ergänzungen innerhalb meiner Theme-Dateien dokumentiere, ist es ein Leichtes Buch zu führen.

Wenn die XML-RPC-Schnittstelle komplett abgeschaltet werden soll, kann der Zugriff auf die Datei xmlrpc.php über eine .htaccess-Anweisung vollständig gesperrt werden. Es erübrigt sich dann das Ändern der Theme-Datei. Wird die gesperrte Datei z.B. im Browser aufgerufen, erhält der Aufrufer die Fehlerantwort 403 vom Server. Für meine Blogs habe ich diese Variante gewählt, da dies auch Server-Ressourcen spart und „nur“ die Fehlermeldung erscheint. Bevor jedoch die XML-RPC-Schnittstelle vollständig abgeschaltet wird, sollte geprüft werden, ob nicht ein oder mehrere Plug-Ins den Zugriff auf die Datei benötigen. Beispielsweise ist dies für das WordPress Plug-In JetPack der Fall.

Die htaccess-Datei befindet sich im Wurzelverzeichnis des Blog und kann mit einem Texteditor wie Notepad++ editiert werden. Folgenden Block habe ich an den Anfang der .htaccess-Datei gesetzt.

Es gibt auch WordPress Plug-Ins, die die zuvor beschriebenen Aufgaben übernehmen können. Dies finde ich allerdings etwas überdimensioniert, denn das Editieren der Dateien ist in drei Minuten erledigt.

Unabhängig von den Gegenmaßnahmen zum Zugriff auf die XML-RPC-Schnittstelle habe ich auch die Gelegenheit genutzt, die Standard-Anmeldeadresse der Blogs zu verlegen. Heißt, die Standardadresse wird ins Leere umgeleitet und die Anmeldeadresse an einen anderen Ort verlegt. Und, der Anmeldedialog beinhaltet ein zusätzliches Feld, welches bei der Anmeldung abgefragt wird. Hierzu verwende ich das Plug-In Stealth Login Page.

Fazit

Die Zugriffsversuche sind seit den Gegenmaßnahmen bislang relativ wenig zurückgegangen, was aber meines Erachtens auch zu erwarten war. Die Blogs reagieren aber nun wieder deutlich schneller, verbrauchen weniger Ressourcen und vor allem sind keine Ausfälle mehr zu verzeichnen.

Folgend einige Links zu Websites, die mir bei der Suche nach Gegenmaßnahmen behilflich waren. Die beiden letzten Links beinhalten Tipps & Tricks im Umgang mit htaccess sowie zur Sicherheit von WordPress.

Mourad Louha

Über den Autor · Mourad Louha

Mourad arbeitet seit 2005 als selbständiger Softwareentwickler und Trainer und lebt in Aachen, gelegen am Dreiländereck Belgien, Deutschland und Niederlande. In seiner Freizeit engagiert er sich in Online Communities rund um Office, schreibt beim Excel Ticker Artikel zu Office & Co. und betreibt weitere Community Projekte in Zusammenarbeit mit Freunden und Partnern, wie das Forum zu Microsoft Office 365 und Office 2013, den Excel Soccer oder den Excel Formel Übersetzer. Für sein außergewöhnliches Engagement wurde er seit Januar 2011 jährlich von Microsoft als Microsoft Most Valuable Professional (MVP) ausgezeichnet.

 
Comments

Dies hat mir sehr zu Sicherheitsthemen bzgl. WordPress geholfen.

Hallo. Ich habe jetzt auch Loginversuche auf einem meiner Blogs festgestellt obwohl ich den Login Bereich schon über die htaccess geschützt habe. Gleichzeitig habe ich von der Möglichkeit dies über die diese xml-rpc Schnittstelle gelesen. Den Code habe ich in die htaccess eingetragen, nur kann ich mich ja dann selber nicht mehr über die Anmeldung in den Blog einloggen, auch in Piwik ist ein Einloggen nicht mehr möglich, welches im selben Verzeichnis liegt. Wie stelle ich den nun das einloggen für mich an? Kann ja nicht jedesmal den betreffenden Code aus der htaccess löschen.
Gruß Karsten

Hallo Karsten,

kann ich zwar erstmal nicht so viel zu sagen, warum das bei Dir so ist, aber meines Wissens sollte das nicht, wenn die Anweisungen in der htaccess korrekt sind. Hast Du vielleicht auch Verzeichnisse, wie z.B. wp-admin, geschützt? Falls Ja, kann es m.W. solche Probleme geben.

Was mich betrifft, so logge ich mich aber nur über den Browser ein und nutze keine externen Editoren oder Apps, welche häufig die XMLRPC benötigen. Zusätzlich habe ich noch für’s Login ein weiteres Authentifizierungsfeld drin. Dafür gibt’s Plugins, z.B. Stealth Login Page. Falls das mit der htaccess bei Dir (gar) nicht geht, probiere das Plugin mal aus.

Gruß

Ja ich schütze unter anderem per htpasswd auch wp-admin. Dies ist ja auch in der htaccess hinterlegt. Einloggen tue ich mich auch nur über den normalen Anmeldebutton von WP und mit nix anderem. Allerdings bekomme ich nun die 403 Fehlerseite zu sehen wenn ich diesen Codeschnippsel in die htaccess eintrage.

Hallo,

sorry für die späte Antwort und Freischaltung, hatte aber gestern zuviel zu tun. Soweit ich informiert bin, kann das Schützen des wp-admin Ordners per htaccess genau den Effekt haben kann, den Du beobachtest. Z.B. wenn sich noch ein Plugin einklinkt; hatte ich auch mal. Ich würde das nochmal checken, z.B. ob die htaccess sich nach Deiner IP richtet, Du aber eine dynamische hast. Von AskApache gibt es ein Plugin, dass das Management mit htaccess übernimmt. Habe ich selbst nicht ausprobiert.

Gruß

Guten Morgen.

Auf Plugins möchte ich erst einmal verzichten, so wenige wie möglich ist da meine Devise. Ich hatte den Code als neue Zeile in die htaccess geschrieben. Nun habe ich xmlrpc.php mal dem FilesMatch hinzugefügt in dem steht welche Dateien durch htpasswd geschützt werden sollen. Sperre mich damit jedenfalls nicht selber aus, weis aber auch nicht ob das so überhaupt nen nutzen hat^^.

Guten Morgen,

auch ich nutze so wenig Plugins wie möglich; allein auch schon der Perfomance wegen. Das Stealth Login kann man m.E. bedenkenlos nutzen. Die XMLRPC ist z.B. notwendig wenn Du von aussen auf den Blog zugreifen möchtest, z.B. gibt’s ja Leute, die mit Word oder per Handy im Blog posten. Die XMLRPC kann aber auch von anderen Servern angepingt bzw. aufgerufen werden. Das war bei mir extrem der Fall, weshalb ich die dann per htaccess geblockt habe. Da ich den Zugriff von aussen nicht nutze und auch auf Pingbacks verzichte, stört’s nicht. Seitdem und in Kombination mit dem Stealth Login ist wieder Ruhe eingekehrt, wobei Abfragen z.B. von doofen Bots sich meist nicht vermeiden lassen. Aber das hält der Server aus. Den Schutz per htaccess-login nutze ich für mich nicht. Aber das Übliche, also gute Kennwörter, admin nicht als Name, usw.

Gruß

Nochmal mich kurz melden will. Nachdem ich wie oben beschrieben xmlrpc.php den FilesMatch hinzu gefügt habe, ist ruhe. Ich hoffe das es auch daran liegt und nicht nur der Typ keine Lust mehr hatte und woanders weiter macht^^. Also für die die htpasswd im Einsatz haben, eine Möglichkeit.

Hallo Karsten, freut mich zu hören, dass Du den oder die Störfaktor/en los bist :-) Gruß

Hallo, bin auch ein XMLRPC Opfer geworden und habe die .htacess geändert. Das Problem: meine Startseite enthält nun einen toten Link. Wie bekommt man den weg`?

Hallo Kristin,

wenn Du die htaccess geändert hast, blockst Du den Zugriff auf die XMLRPC-Seite von aussen, was ja das Ziel war. Wenn die restlichen Seiten funktionieren und Du dort keine Probleme hast, z.B. im Backend-Bereich, stört’s m.E. nicht. Falls Du allerdings meinst, dass die XMLRPC noch im Quelltext der Seite als Link auftaucht, könntest Du noch in den Einstellungen bei Diskussionen das Erlauben von Pingbacks und Trackbacks abschalten. Möglicherweise bleibt der Link im Quellcode aber noch drin. Dann hilft z.B. noch eine kleine Änderung im Template, meist functions.php, wie hier link Link beschrieben: http://fastwp.de/2068/

Gruß

Hallo Mourad!
Vielen Dank für den sehr guten Artikel. Half er mir doch zu verstehen ob ich die Schnittstelle überhaupt benötige und wozu diese da ist.
Über das WordPress Plugin iThemes Security kann man diese Einstellungen bezüglich der RPC-Schnittstelle (und noch einige mehr) bequem über das eigene Menü des Plugins durchführen.

Gruß Frank

Hallo Frank,

Vielen Dank für das Lob und den Tipp :-)

Das Plugin hört sich sehr interessant bzw. habe mir mal die Website ithemes.com/security/ von denen angeschaut. Gibt‘ auch eine Pro-Version, die dann was kostet (Infos für weitere Leser/innen hier im Blog) und dann aber auch mehr kann. Persönlich bin ich eher ein Verfechter des Sparsamen, denn jedes Plugin nimmt Ressourcen in Anspruch. Hängt dann ein bißchen davon ab, wie hoch die Zugriffe sind und was der Server so an Leistung hergibt, ohne dann zu teuer zu werden.

Viele Grüße, Mourad

Trackbacks for this post