WordPress

WordPress Angriff und das Sicherheitsplugin schweigt

Um einen Angriff gegen WordPress Installationen schnell und präzise identifizieren und abwehren zu können, werte ich die Logfiles verschiedener Domains parallel und in Echtzeit aus. Um 0:50 Uhr am 28.09.2015 hat mein Frühwarnsystem gelben Alarm ausgelöst.

Ein normaler WordPress Angriff?

Im Regelfall erhalte ich pro Tag 20-30 Meldungen über fehlgeschlagene Anmeldeversuche. Das ist normal und bedarf keiner weiteren Beachtung, solange man Vorkehrungen trifft um unliebsame Besucher aus dem WordPress Backend fern zu halten. Denn ein wirklicher Angriff sieht anders aus, nicht selten erfolgen dabei Anmeldeversuche von hunderten Servern im Sekundentakt. Mit geeigneten Plugins, wie „All In One WP Security“ von „Tips and Tricks HQ“, kann man sich dagegen schützen. Besser ist natürlich der Einsatz einer Firewall auf dem Server oder noch besser vor dem Server, das dürfte aber für die meisten User ein Wunschtraum bleiben.

Als Benutzernamen für den Login in WordPress benutzen Angreifer oft die Domainnamen ohne die Domainendung, also Beispielweise ‚wp-experte‘ auf wp-experte.com, ‚wp-fachmann‘ auf wp-fachmann.com oder ‚wp-spezialist‘ auf wp-spezialist.com. Die Benutzernamen ‚admin‘ und ‚administrator‘ sind obligatorisch, genauso wie der mittels http(s)://[domainname]/?author=1 ausgelesene Benutzer. In diesem Zusammenhang empfehle ich die URL der Autorenseite eines WordPress Benutzers mit Hilfe des Plugins „Edit Author Slug“ zu ändern.

Kein normaler WordPress Angriff?

Normalerweise versuchen sich Angreifer also mit wechselnden Benutzernamen und durch mehrfache Anmeldeversuche Zugang zum WordPress Backend zu verschaffen. Wer Sicherheitstools verwendet hat dort meistens 3 Fehlversuche eingestellt, die dann zu einer Sperre der IP Adresse führen. Was meine Systeme am 28.09.2015 ab 0:50 Uhr aufgezeichnet haben unterscheidet sich von den üblichen Angriffen in einem wesentlichen Punkt. Es handelt sich um einen einzelnen Anmeldeversuch pro Domain, sodass die meisten Sicherheitsplugins nicht anspringen.

Das erinnert mich an den Film „Roter Oktober“ und den Satz von U-Boot Kapitän Ramius: „Geben Sie mir ein Ping Vasili, aber bitte nur ein einziges!“. Da die aktuelle Vorgehensweise genau einem Ping entspricht, erhält sie von mir den Namen „Ramius Manöver“. Durch die kombinierte Analyse (Crossdomain) aller Logfiles mit Fail2Ban sehe ich auch diese Angriffe und konnte in rund zwölf Stunden über 400 IP-Netze zählen, aus denen auf die Anmeldeseite fremder WordPress Installationen zugegriffen wird.

Was steckt hinter dem „Ramius Manöver“

Zunächst könnte es sich um die Vorbereitung für einen großen Angriff handeln. Also die Prüfung wo sich WordPress Installationen befinden. Dagegen spricht allerdings die Tatsache, dass man das nicht von hunderten verschiedenen Adressen aus testen müsste.

Oder die Programmierer haben die Vorgehensweise bei diesem Angriff absichtlich geändert, um sich vor den allgemein üblichen Abwehrmaßnahmen zu verbergen. Denn die Sicherheitsplugins für WordPress haben alle eines gemeinsam, sie zählen die fehlgeschlagenen Anmeldeversuche in einem definiert Zeitraum. Beide Werte kann der Benutzer meistens frei festlegen und die Standardwerte reichen von „3 Versuche innerhalb 5 Minuten“ bis „10 Versuche innerhalb 10 Minuten“. Gelingt es dem Angreifer unter diesen Werten zu bleiben wird er nicht entdeckt. Bei herkömmlichen Angriffen arbeiten Angreifer eine Liste von Benutzernamen pro angegriffene Domain ab. Enthält diese Liste z.B. zehn Benutzernamen sieht man im Logfile des Webserver zehn Aufrufe der Datei wp-login.php hintereinander und das meistens im Abstand weniger Sekunden. Das liegt im Regelfall innerhalb der eingestellten Parameter in den WordPress Sicherheitsplugins und führt somit zum Block der IP-Adresse.

Ändert man die Schleifenstruktur und testet einen Benutzername zunächst gegen alle Domainnamen einer Liste, kann man aus dem Zeitfenster der Sicherheitssysteme ausbrechen. Die Liste der anzugreifenden WordPress Installationen enthält nicht selten tausende, bei einem großen Angriff sogar hunderttausende von Domainnamen. Ausgehend von einem Zeitfenster von 5 Minuten, was 300 Sekunden entspricht, reicht eine Liste mit 300 Domains aus. Wenn man also pro Sekunde auf eine Domain zugreift käme man nach 5 Minuten wieder bei der ersten Domain an und würde unentdeckt bleiben.

Ein großes Zeitfenster für den Angriff

Um herauszufinden ob das der Fall ist, habe ich meine Abwehrstrategie geändert und konnte nach rund 3 Stunden die ersten wiederkehrenden IP-Adressen sehen. Unter der Annahme der Angreifer würde die Liste linear von oben nach unten abarbeiten und dann wieder von vorne anfangen, hätte die Liste bei einem Zugriff pro Sekunde 10.800 Einträge.

Diese Zahlen sprechen sehr deutlich für einen mittleren Angriff und die Angreifer haben ihre Strategie geschickt gewählt. Durch das große Zeitfenster bleiben Sie im Regelfall unentdeckt, denn auch viele Administratoren verlassen sich auf die Standardwerte ihrer Sicherheitssoftware. Bei Fail2ban stehen z.B. bantime und findtime auf nur 10 Minuten, was in diesem Fall wertlos ist. Ich empfehle grundsätzlich die Zeit für das Aussperren einer IP auf einen Tag (86400 Sekunden) zu setzen. Je nachdem wieviel Ressourcen ein Server hat, darf die Zeitspanne für das Auffinden von Einträgen im Log dann auch gerne 6 Stunden betragen. Damit das aber funktioniert muss man in WordPress noch eine Funktion einbauen, die entsprechende Meldungen ins Logfile des Webservers schreibt.

Zu diesem Zweck erstelle ich grundsätzlich die Datei /wp-content/mu-plugins/security.php mit folgendem Inhalt:

<?php
function my_login_failed_403() {
 status_header( 403 );
}
add_action( 'wp_login_failed', 'my_login_failed_403' );
?>

Durch die Ablage im Verzeichnis mu-plugins (einfach unterhalb /wp-content erstellen, falls es ihn nicht gibt) wird sichergestellt, das die Funktion immer geladen wird und auf normalem Weg nicht wie ein Plugin deaktiviert werden kann. Die Funktion selbst ist unspektakulär und fügt bei einem fehlerhaften Login eine 403 Statusmeldung in den Header ein. In Fail2ban kann man die Meldung dann ganz einfach aus den Logfiles auslesen:

failregex = ^<HOST>.*POST.*(wp-login.php|xmlrpc.php).* 403

Updates

Update 28.09.2015 16:45 Uhr

Pro Minute tauchen derzeit 1-2 neue IP-Adressen und 2-3 alte IP-Adressen auf. Das Angriffsvolumen ist seit rund 2 Stunden stabil. Neue Erkenntnisse zum Hintergrund habe ich noch nicht, denn das Angriffsmuster hat sich nicht geändert. Nach wie vor handelt es sich nur um Anmeldeversuche.

Update 28.09.2015 17:20 Uhr

Parallel zu diesem Angriff tauchen in meinen Honeypots nun Anfragen von Bots nach folgenden Tags auf
GET /tag/plaginy/
GET /tag/patchi/
GET /tag/virusy/
GET /tag/nextgen-gallery/
GET /tag/kontaktnaya-forma/
GET /sql-inekciya-v-plagine-wordpress-event-registration/

Update 28.09.2015 17:55 Uhr

Aus dem WordPress Angriff lässt sich ein erstes Muster erkennen. Pro Minute tauchen zwei neue IP Adressen auf. Nach wie vor greift jede IP Adresse nur einmal auf die wp-login.php einer Domain zu. Während von der einen Adresse die Anmeldung mit dem Benutzer „admin“ oder „administrator“ versucht wird, probiert man es von der zweiten Adresse mit dem Domainnamen ohne die Domainendung als Benutzer. Das geschieht absolut regelmäßig und lässt nur den Schluss auf einen koordinierten Angriff durch ein Bot-Netz zu. Viel Sinn macht das aber nicht, denn anscheinend erfolgt keine Rückmeldung an das zentrale System, sonst würde von den nächsten Adressen nicht wieder das gleiche Muster verwendet.

Update 28.09.2015 18:20 Uhr

Der Angriff wurde bis jetzt im Wesentlichen von IP-Adressen aus Osteuropa durchgeführt: Russland, Georgien, Ukraine und Litauen. Seit einigen Minuten tauchen nun vereinzelt Netze aus Brasilien auf. Langsam komme ich zu dem Schluss, dass es sich um ein verhältnismäßig kleines Bot-Netz handelt und die Initiatoren keinen richtigen Plan haben. Die Menge der Zugriffe reicht nicht für eine DDOS Attacke und das Angriffsmuster zielt augenscheinlich weder auf einen Exploit ab noch taugt es für eine Brute-Force-Attacke.

Update 28.09.2015 18:55 Uhr

Seit dem letzten Update hat sich die Frequenz des Angriffs reduziert. Wiederkehrende IP Adressen gibt es seit 18:30 Uhr keine mehr und einzelne neue Adressen tauchen nur noch alle 4-5 Minuten auf. Die Zeit habe ich genutzt weitere von mir betreute WordPress Installationen zu prüfen. Von bis jetzt 118 geprüften Webseiten wurden 29 angegriffen, was den Angriff an sich noch verwirrender macht. Es fehlt also nicht nur der Sinn sondern auch das Auswahlkriterium. Und das macht mich besonders stutzig, denn zufällig ausgewählte Ziele riechen förmlich nach Stichproben.

Update 28.09.2015 22:10 Uhr

Wirklich neues gibt es nicht zu berichten. Tatsächlich tauchen nun vermehrt Adressen aus Südamerika auf sowie vereinzelte aus der Türkei. Das es sich um ein Bot-Netz handelt dürfte damit als sicher gelten. Muster und Frequenz sind seit dem Update um 18:55 Uhr gleich geblieben. Nach dem jetzigen Stand er Dinge bleibt also nur abzuwarten wann der Angriff stoppt.

Update 29.09.2015 11:15 Uhr

Der Angriff lief die Nacht vom 28.9 auf 29.9 ohne Veränderungen weiter. Sinn ergibt das Vorgehen nach wie vor nicht. Seit heute früh wird für jede geblockte IP-Adresse automatisch ein Abuse Report an den für die betroffene IP-Adresse hinterlegten Abuse Kontakt geschickt. Falls ich in 7 Tagen die Adressen immer noch in Angriffen sehe, erfolgt Meldung an die jeweilige Registry des Landes. Mal sehen ob man auf diese Weise etwas bewegt bekommt.

Update 29.09.2015 23:45 Uhr

Ich habe den heutigen Tag zur Hälfte damit verbracht die Abwehr solcher WordPress Angriffe zu optimieren. Zwischenzeitlich hat mich der RIPE von seinen Whois-Servern verbannt, weil ich zu viele Abfragen produziert habe. 4017 geblockte IP-Adressen in 24 Stunden entsprechen einem Anmeldeversuch alle 21 Sekunden. Ich hätte möglicherweise von Anfang an die Whois Abfragen auf zwei pro Zugriff beschränken sollen. Dennoch hätte ich nicht gedacht, das 20.000 Abfragen ein Problem darstellen. Da die Sperre aber wieder aufgehoben wird steht weiteren Tests nichts im Wege. Interessant ist auch, dass rund 25% der für die IP-Adressen hinterlegten Abuse Kontakte nicht funktionieren und die Emails zurück kommen.

Update 30.09.2015 10:40 Uhr

Die Anzahl der Zugriffe hat abgenommen und die Liste der IP Adressen ist auf rund 600 gesunken. Das könnte das Ende des WordPress Angriffs einläuten. Nur noch alle 5-6 Minuten taucht eine neue Adresse auf und nur alle 20-30 Minuten kommt eine bereits bekannte Adresse wieder. Auf Whois kann ich auch wieder zugreifen und ein Provider hat auf meine Abuse Meldung geantwortet – eine Antwort auf rund 4000 Abuse Mitteilungen – traurig.

Update 6.10.2015 11:55 Uhr

Seit 3.10.2015 17:53 Uhr ist Ruhe, der WordPress Angriff ist vorbei. In einem weiteren Beitrag habe ich den Angriff noch einmal genauer analysiert und komme zu einem überraschenden Ergebnis.

Geeignete Abwehrmaßnahmen

Wer bis jetzt noch immer keine Maßnahmen gegen unliebsame Besucher ergriffen hat, sollte sich spätestens jetzt damit auseinandersetzen. Mit wenigen Handgriffen ist es möglich WordPress gegen eine Vielzahl von Angriffen zu schützen. Meine Empfehlungen lauten:

  1. Verwenden Sie sichere Passwörter mit mindestens 15 Zeichen, wovon mindesten 3 Zahlen, 3 Sonderzeichen und 3 Großbuchstaben sind.
  2. Verwenden Sie niemals „admin“ und „administrator“ als Benutzername. Auch nicht als Honeypot!
  3. Verwenden Sie für den „Nickname“ in WordPress nie den Benutzernamen (Login ) und ändern Sie den „Author Slug“. „Edit Author Slug“ hilft Ihnen dabei.
  4. Installieren Sie ein Sicherheitsplugin wie z.B. „All In One WP Security“ und erhöhen Sie die Standardwerte für die Erkennung von fehlerhaften Logins sowie die Zeit der IP Sperre.
  5. Halten Sie WordPress, Ihr Theme und Ihre Plugins aktuell. Ein wöchentliches Update ist das Minimum, besser ist sofort zu reagieren.
  6. Verwenden Sie nur Plugins von bekannten und vertrauenswürdigen Entwicklern. Trauen Sie kostenlosen Plugins nicht uneingeschränkt.
  7. Machen Sie täglich ein Backup und sichern Sie es am besten auf einem externen Speicherplatz.
  8. Installieren Sie ein Audit System, wie z.B. „WP Security Audit Log“ um die Vorgänge in WordPress nachvollziehen zu können.

Und für alle, die sich das nicht selbst zutrauen oder bei denen die Maßnahmen zu spät kommen, also WordPress durch einen Angriff bereits gehackt wurde, biete ich die Absicherung bzw. Sanierung von WordPress an.

 

Achtung! Dieser Beitrag ist älter als 6 Monate. Daher ist es möglich, dass die enthaltenen Informationen nicht mehr gültig sind.

WordPress Experte und SpezialistAls WordPress Entwickler mit 12 Jahren Erfahrung unterstütze ich Unternehmer bei der Erstellung von Applikationen und Webseiten auf der Basis von WordPress. Als WooCommerce Spezialist konzentriere ich mich auf e-Commerce Anwendungen mit WordPress. Auf meiner Know-How Seite erfahren Sie mehr über mich.