XMLRPC Attacke auf WordPress

Vor gut zwei Jahren wurde die XMLRPC Schnittstelle auf WordPress standardmässig aktiviert – vorher war das ein wahlweise zuschaltbares Feature, ab Version 3.5 kann man das nur noch mit Tricks deaktivieren.

XMLRPC ist „Remote Procedure Call via XML“, damit kann man unter anderem WordPress von seinem Smartphone aus bedienen und Track/Pingbacks erzeugen. Bei sowas jauchzen die Geeks natürlich sofort auf – bei mir als verantwortungsbewussten Programmierer gehen sofort die Alarmglocken an: denn RPCs sind (wenn sie sicher sind) nicht nutzbar und wenn sie unsicher sind auch nicht nutzbar denn sie laden geradezu zum Missbrauch ein.

Am Abend meldete sich ein Anwender, dass sein Forum und das zugehörige Blog nicht mehr erreichbar seien. Zuerst habe ich auf einen der seltenen Hänger getippt und den virtuellen Server erstmal neu gestartet. Nach paar Sekunden war die Maschine wieder da – und auch genauso schnell wieder nicht mehr erreichbar. Also mal auf den Host geschaut: die VM belegte einen Core zu 100% und sah auch sonst sehr beschäftigt aus. Das SSH-Login funktionierte, zusammen mit einem beherzten „sudo -s“ sind ca. 15min vergangen bis ich eine root-shell hatte. „htop“ brauchte nochmal 5min bis zur ersten Anzeige und dann wurde der Schuldige gefunden: Apache war bis zum Anschlag ausgelastet. Normalerweise ein Anzeichen dafür, dass irgendeine Websoftware verseucht ist und nun die Maschine damit belastet, Spam herauszuschicken.

Aber nachdem ich den Webserver mit einem beherzten „killall apache“ abgeschossen hatte, wurde das System wieder responsiv und ich konnte mal genauer in den Datenverkehr reinschauen.

Nach etwas herumprobieren kam ich auf folgendes Script:

rm -f tmpfile
echo "waiting for 500 packets (^c to see whats collected until now)"
tcpdump -vvv -n -A -c 500 'tcp port 80' > tmpfile
less tmpfile
rm tmpfile

Und siehe da: die Installation war in Ordnung, aber irgendein Idiot versucht via xmlrpc.php ein Pingback an eine andere Seite zu senden. Kleiner Input, riesen Output – so kennen wir das.

Soforthilfe schafft eine .htaccess im Hauptverzeichnis von WordPress:

<Files "xmlrpc.php">
Order Allow,Deny
deny from all
</Files>

Damit ist die Fernsteuerung von WordPress erstmal abgeknipst und die Gesamtinstallation erreichbar.

Nur noch die Netze abklemmen, die einen bewerfen. Wie immer Vollspacken von OVH und Ecatel – deren AS gehören eigentlich in jeder Debian-Installation per Default in die iptables.

Problem erkannt, Problem gebannt!

Drunter und drüber

Dass die Telekom ihre ISDN-Anschlüsse lieber gestern als morgen einstampfen würde, ist schon lange bekannt. 2018 ist dann entgültig Schluss mit dem „Integrated Services Digital Network“ und alles muss auf IP-Telefonie umgestellt sein.

Damit das zügig läuft, bombardiert die Telekom ihre Kunden mit allerlei Werbepost und Anrufen in denen das Blaue vom Himmel herunter versprochen wird. Vorallem das Argument „mehr Internetgeschwindigkeit und billiger“ zieht bei vielen Anwendern.

Letzte Woche Donnerstag, also genau vor dem „Tag der Deutschen Einheit“ ruft mich ein völlig aufgelöster Kunde an. „Nichts geht mehr – kein Internet, kein Telefon“ und rückte nebenbei heraus, dass man ein Angebot der Telekom angenommen hätte wo alles viel „schneller, besser und billiger“ sei. Auf der Fahrt zum Einsatz schwante mir schon, was da passiert ist und beim Kunden langte ein Blick in die Auftragsbestätigung dass der Kunde mit „All-IP“ beglückt wurde – völliger Unsinn bei einem Unternehmen welches noch auf etliche ISDN-Features angewiesen ist und erst in 2 Jahren migrieren wird.

Aber wie schon Adenauer sagte: „Die Situation ist da!“ und nun gilt es zu retten, was zu retten ist. Kunde gefragt, ob wenigstens ein VoIP-Router geliefert wurde. Versprochen wurde er vom Telekom-Vertrieb, die Auftragsbestätigung schwieg sich darüber aus und geliefert wurde daher auch nichts. Mit einer Fahrt zum nächsten Saturn/Media-Markt zwecks Beschaffung eines VoIP-Routers wäre zumindest in paar Stunden (Zeit die ich eigentlich gar nicht habe) wenigstens bisserl Telefonie und Internet möglich, aber als Dauerzustand für den ganzen Betrieb nicht tragbar. Also Hotline, Situation geschildert und Rückabwicklung (Zurück-umstellung auf ISDN) beauftragt. Wegen dem Feiertag ist mit der Fertigstellung nicht vor Dienstag zu rechnen, zum Glück hat der Kunde genügend Mobiltelefone mit Internet so dass die Grundversorgung gesichert ist. Noch schnell eine externe Anrufweiterschaltung der Hauptnummer auf das Mobilbiltelefon der Chefin angeleiert und gut war.

Das mit der Weiterschaltung klappte aber nicht. Nachdem ich paarmal zwischen Vertrieb und Störungsstelle pendelten durfte, kam auch der Grund heraus: Trotz Rückabwicklung muss die Telefonie intern erst auf IP umgestellt werden (das passiert erst Samstag) damit die AWS funktioniert und dann wird alles auf einen Schlag auf den alten Zustand zurückgestellt.

Tage vergingen, Mittwoch nachmittag dann die frohe Botschaft: Telefon geht wieder, aber kein Internet. Also wieder zum Kunden. DSL ist synchron, login fehlgeschlagen. Störungsstelle war auch ratlos „alles wurde auf den vorherigen Zustand zurückgesetzt, vielleicht Router kaputt?“. Na – ich musste eh nach Hanau einkaufen fahren, da langte die Zeit noch für Routerbeschaffung (unser Lager ist nämlich leer, die letzten Gewitter haben mächtig zugeschlagen).

Zurück den neuen Router ausprobiert, gleiches Ergebnis. Da kommt der Kunde mit einem Umschlag „ach, das war auch dabei“ um die Ecke. Neue Zugangsdaten mit denen dann auch das Login funktionierte (soweit zum Thema „alles auf den Ursprungszustand).

Anwender glücklich, Admin mit den Nerven runter.