WordPress CVE-2018-6389 Lücke mit Fail2ban absichern
Heute morgen stieß ich auf einen Blogpost der eine bedenklichen Lücke in WordPress beschrieb, die eine DoS Attacke ermöglicht. In diesem Artikel hier möchte ich euch zeigen, wie ich unsere Fail2Ban Konfiguration erweitert habe um diese Lücke zu schliessen.
Über Twitter bin ich auf diesen Blogpost gestoßen (danke Sergej ;-) ), der eine bisher ungenutzte & unbekannte Lücke in WordPress aufzeigt, um eine Denial of Service Attacke ausführen zu können. Dazu wird ein Script von WordPress ausgenutzt, welches Javascript oder CSS Dateien zusammensetzt und dem Browser ausliefert (um einzelne Requests zu sparen).
Allerdings ist das Ausführen dieses Scripts ohne eine Authentifizerung o.Ä. möglich und wenn man diesem Script anweist, alle Standard-Scripts / -Styles von WordPress zu laden, erzeugt es viele I/O Vorgänge (Schreib und Lesevorgänge der Festplatte) auf dem Server, die allesamt Serverressourcen benötigen. Und das nicht zu knapp.
Ein Angreifer hat es so sehr leicht ein Attacke zu fahren und dieses Script massenhaft anzufragen.
Ich habe selber einen Test auf einem Server gemacht (6 Kerne, 16GB RAM, komplett SSD) und einen mini Angriff gestartet. Effektiv schoss innerhalb von Sekunden der Load des Servers extrem in die Höhe und der Webserver kam nach einigen Minuten nicht mehr nach, Websites mit genug Geschwindigkeit auszuliefern. Hätte ich das ganze weiter auf die Spitze getrieben, hätte ich ohne weiteres den gesamten Server lahmlegen können. (Wie gesagt, es war ein mini Angriff von einem Server ausgehend… man stelle sich vor ein Botnetz mit tausenden Rechner startet so einen Angriff…)
WordPress-Entwickler fühlen sich nicht zuständig
In seinem Beitrag schreibt Barak Tawily:
…I thought they* would understand that there is a security issue here and properly address it. After going back and forth about it a few times and my trying to explain and provide a PoC, they refused to acknowledge it and claimed that:
„This kind of thing should really be mitigated at the server or network level rather than the application level, which is outside of WordPress’s control.“
*die WordPress Entwickler des Bug-Bounty-Programs (Anmerkung von mir).
Die WordPress Entwickler sehen sich also nicht für dieses Problem verantwortlich und verweisen auf andere Maßnahmen, die auf Server- oder sogar Netzwerkebene getroffen werden sollen. Somit ist eine baldige Stopfung dieser Lücke nicht in Sicht.
Barak Tawily fügt in seinem Bericht zwar einen Bugfix mit an, der aber die Core-Dateien von WordPress anpasst. Diese werden also bei jedem WordPress-Update wieder überschieben. Also keine praktikable Lösung für uns (mit sehe vielen WordPress Websites auf unseren Servern).
Fail2ban nutzen
Da wir auf unserem Server Fail2Ban nutzen, haben wir uns kurzerhand eine Regel geschrieben. Öffnet das Terminal und erstellt einen neuen Filter mit dem folgenden Inhalt:
nano /etc/fail2ban/filter.d/wp-load.conf# WordPress DOS load scripts & styles filter: /etc/fail2ban/filter.d/wp-load.conf:
#
# Block IPs trying to DOS wp-load-styles and wp-load-scripts!
#
# Matches e.g.
# 12.34.33.22 - [07/Jun/2014:11:15:29] "GET /wp-admin/load-scripts.php%5C?c%5C=1%5C&load%5B%5D%5C HTTP/1.0" 200 4523 ...
#
[Definition]
failregex = ^<HOST> .*"(?:POST|GET) .*wp-admin\/load-(?:styles|scripts)\.php.* .*$
ignoreregex =Danach passt ihr eure fail2ban config an um den Filter zu laden
nano /etc/fail2ban/jail.local[wp-load]
enabled = true
filter = wp-load
logpath = /var/log/apache2/sites_log/*.log
bantime = 600
maxretry = 10
findtime = 2
ignoreip = - bantime: Zeit in Sekunden die der Angreifer gebannt werden soll (hier 10 Minuten)
- maxretry: wieviele Zugriff geschehen dürfen bis geblockt wird
- findtime: die Zeit in Sekunden in der die maximal Anzahl Zugriffe geschehen darf.
- ingoreip: hier könnt ihr die IPs (mit Leerstelle getrennt) eintragen, die ignoriert werden sollen
Nun abspeichern und Faik2Ban neustarten:
/etc/init.d/fail2ban restartIn unseren Tests griff Fail2ban direkt wenn eine Attacke gestartet wurde. Normal-surfende Besucher die sich auf der WordPress Seite im Adminbereich befinden (wo die Scripts hauptsächlich aufgerufen werden) werden bei normaler Handhabung nicht geblockt.
Falls doch könnt ihr beispielsweise die Anzahl bei maxretry etwas höher schrauben.
Nun seid ihr vor dieser Attacke geschützt – denn jetzt nach dem Bekanntwerden wird sie sicherlich früher oder später ausgenutzt.
Im logpath sollten sich nur Access Logfiles sein, keine Error-Logfiles.
Die Error-Logfiles haben ein anderes Format, fail2ban schreibt dann Fehlermeldungen.