Schaust du dir deine Server-Logs an und siehst tausende Anfragen auf eine Datei namens xmlrpc.php? Oder spielt deine CPU verrückt, obwohl kaum echte Besucher auf der Seite sind? Dann bist du wahrscheinlich Opfer einer XML-RPC-Attacke geworden.
In der modernen WordPress-Welt ist die Schnittstelle XML-RPC ein Relikt aus vergangenen Tagen, das heute oft mehr schadet als nützt. In diesem Artikel erkläre ich dir technisch fundiert, was hinter den Kulissen passiert, warum Hacker Methoden wie system.multicall lieben und warum diese Schnittstelle das beliebteste Einfallstor für Brute-Force-Angriffe ist.
Was ist XML-RPC eigentlich?
Bevor wir über Angriffe sprechen, müssen wir verstehen, wozu diese Datei gut ist. XML-RPC (Extensible Markup Language Remote Procedure Call) ist eine Schnittstelle, die es externen Anwendungen ermöglicht, mit deiner WordPress-Seite zu kommunizieren.
In den frühen Tagen des Internets – lange vor der modernen WordPress REST API – war XML-RPC lebenswichtig. Es ermöglichte:
- Die Kommunikation mit der WordPress-App auf Smartphones.
- Das Bloggen über Desktop-Clients wie Windows Live Writer.
- Pingbacks und Trackbacks zwischen verschiedenen Blogs.
Seit WordPress 4.4 ist die REST API der neue Standard. Doch um die Abwärtskompatibilität für uralte Plugins und Tools zu sichern, ist xmlrpc.php bei jeder Standard-Installation von WordPress standardmäßig aktiviert. Und genau das nutzen Angreifer aus.
Die zwei Hauptarten der XML-RPC-Angriffe
Hacker nutzen diese offene Tür primär für zwei Szenarien: Brute-Force-Attacken (Passwörter knacken) und DDoS-Attacken (Überlastung).
1. Brute-Force via system.multicall
Das ist die perfideste Methode. Normalerweise, wenn ein Hacker versucht, dein Passwort über die Login-Seite (wp-login.php) zu erraten, muss er für jeden Versuch eine neue HTTP-Anfrage senden. Das ist laut, langsam und wird von Sicherheits-Plugins schnell blockiert (z. B. nach 5 Fehlversuchen).
XML-RPC erlaubt jedoch eine Methode namens system.multicall.
Das Problem: Mit dieser Methode kann ein Angreifer hunderte, manchmal tausende Befehle in einem einzigen HTTP-Request verpacken.
Stell dir vor, der Hacker sendet folgenden Code an deine Seite:
XML
<methodCall>
<methodName>system.multicall</methodName>
<params>
<param><value><struct>
<member><name>methodName</name><value><string>wp.getUsersBlogs</string></value></member>
<member><name>params</name><value><array><data>
<value><string>admin</string></value>
<value><string>passwort123</string></value>
</data></array></value></member>
</struct></value></param>
<param><value><struct>
<member><name>methodName</name><value><string>wp.getUsersBlogs</string></value></member>
<member><name>params</name><value><array><data>
<value><string>admin</string></value>
<value><string>passwort456</string></value>
</data></array></value></member>
</struct></value></param>
</params>
</methodCall>
Die Folge:
- Der Hacker muss nur eine einzige Anfrage senden.
- Dein Server muss aber hunderte Login-Versuche gleichzeitig prüfen.
- Herkömmliche Login-Limiter greifen oft nicht, da es technisch gesehen nur ein Zugriff war.
- Deine Server-Ressourcen (CPU/RAM) schnellen in die Höhe, die Seite wird langsam („High Load“).
2. DDoS durch Pingbacks
Ein weiterer Klassiker ist der Missbrauch der Pingback-Funktion. Hierbei gaukelt der Angreifer deiner WordPress-Seite vor, sie sei von einer anderen populären Seite verlinkt worden. Deine xmlrpc.php versucht dann, diese Seite zu „pingen“, um den Link zu verifizieren.
Wenn Angreifer dies mit tausenden von WordPress-Seiten gleichzeitig tun (ein Botnetz), können sie eine Ziel-Webseite durch die geballte Kraft unzähliger WordPress-Installationen lahmlegen. Deine Seite wird dabei ungewollt zum Komplizen in einer Distributed Denial of Service (DDoS) Attacke.
Brauche ich XML-RPC heute noch?
In 99 % der Fälle: Nein.
Wenn du nicht gerade uralte Blogging-Software verwendest oder spezifische Plugins hast, die explizit danach verlangen (was selten geworden ist), ist XML-RPC nur unnötiger Ballast. Die moderne WordPress App und Dienste wie Jetpack nutzen zwar teilweise noch XML-RPC, aber auch hier gibt es sicherere Wege.
Wie schütze ich mich?
Jetzt weißt du, warum dein Server unter Last steht und was diese kryptischen Einträge im Log bedeuten. Die Lösung ist simpel: Du musst den Zugriff auf diese Datei unterbinden.
Es gibt verschiedene Wege, die xmlrpc.php unschädlich zu machen – sei es über ein Plugin, einen Filter in der functions.php oder (die beste Methode) direkt auf Serverebene via .htaccess oder Nginx-Config.
Achtung: Einfach die Datei zu löschen ist keine Lösung, da sie beim nächsten WordPress-Update wiederhergestellt wird.
In unserem nächsten Guide zeigen wir dir Schritt für Schritt, wie du XML-RPC korrekt und dauerhaft deaktivierst, ohne deine Seite zu beschädigen. Stay tuned!
Andere Artikel:
