Angriff auf andrefritsche.com – Wie sichert man WordPress ab?

Auffälligkeiten in den Logs

Es ist Karfreitag Abend und du sitzt nichtsahnend am Tisch zusammen mit der Familie. Ein paar Gespräche kommen auf, denen du aber nicht immer folgen kannst. So denkst du dir: “Schaue ich doch mal nach wie die Zugriffszahlen auf meinem Blog sind!”. Da du mit Amazon AWS Cloudfront die Ladegeschwindigkeit für großen Content erhöhen willst siehst du hier öfter mal nach. Und siehe da, außergewöhnlich viele HTTP/S Verbindungen. Im Schnitt hast du 977 Verbindungen pro Tag. An diesem Tag waren es 4200. Was war denn das?

HTTP Verbindungen

Das reicht dir aber noch nicht. Es müssen noch mehr Hinweise gesammelt werden. War an diesem Tag einfach nur viel los? Oder war es doch ein Angriff? Die nächste Station ist die Auftrennung zwischen HTTP und HTTPS. Die meisten deiner Besucher kommen über HTTPS, denn deine Verlinkungen sind meistens mit diesem Protokoll versehen. Aber auch das sieht nicht nach einem normalen Betriebstag aus:

HTTP/HTTPS Verbindungen

Ein ziemlich hoher Peak an HTTP Verbindungen gegenüber den HTTPS Verbindungen. Auffällig, aber so richtig lässt sich nichts darüber aussagen. Es kann durchaus sein, dass ein Beitrag viral wird und per HTTP geteilt wird. Das war nicht der Fall. Denn ein Blick auf die vom Server zurückgeworfenen HTTP Response Codes schlüsselt das Bild etwas mehr auf. Vor ab schon einmal erwähnt: Es sind nicht die HTTP 200 OK Meldungen, die abgesendet wurden:

HTTP Response Code Übersicht

Es waren HTTP Responses aus der 300er Klasse. Das war sehr seltsam! Interessant aber: Die Anzahl der 200 Responses ist vergleichsweise “normal”, also scheinen Besucher ganz normal unterwegs gewesen zu sein. Irgendetwas hat hier versucht mehr anzustellen, als nur Inhalte zu konsumieren. Wobei die Klasse der 300 Codes ja in Richtung Umleitung gehen. Das ist noch nicht so tragisch. Sehen wir weiter. Und zwar fragst du dich nun: Na gut, ich habe 300er Codes in den Logs. Hier sehe ich noch nichts konkretes darüber welche Responses es genau gab, aber ich kann sehen welches eine sehr häufig angefragte Ressource bisher ist. Und jetzt wird es spannend!

Häufig angefragte Ressource

Tada! Wer hätte es gedacht. wp-login.php ist mit Abstand am häufigsten aufgerufen worden und zu 99,26% durch Amazon Cloudfront ausgeliefert worden. Zu 100% mit einem Responsecode aus der 300er HTTP Klasse. Für alle, die nicht wissen was diese Datei genau macht: Hier logt man sich für gewöhnlich ein, dadurch sieht ein Anwender, Bot, Angreifer usw. ein Formular für Name und Passwort. Aber jetzt möchtest du schon wissen, was genau denn passiert ist? Vielleicht ist nicht alles über Amazon Cloudfront zu sehen? Und das ist es nicht!

access_log_andrefritsche.com_attack_wp-login

Jetzt bitte ganz gut hinehen. Es gibt laufend ein:

GET http://www.andresilaghi.com/wp-login.php HTTP/1.0

Worauf ständig POSTs folgen:

POST http://www.andresilaghi.com/wp-login.php HTTP/1.0

Laufend ändern sich die User Agents, Mal ist es Mozilla/4.0 MSIE 6.0, dann Mozilla/5.0 Windows NT 5.0/5.1, Opera usw. Hier wurde versucht laufend ein Login durch zu führen. Vermutlich, das kann ich aber nicht sicher sagen, ein Bruteforce Angriff auf den Login Mechanismus, um die Webseite zu erobern. Aber die Angreifer waren schlau. Sie wussten, es ist eine WordPress Seite, also spekulierten sie: Da gibt es die xmlrpc.php Datei und mit ihr können wir 50 Passwörter und mehr gleichzeitig an die Seite feuern, damit diese schneller per Bruteforce gekapert werden kann. Das sieht im Log sehr ordentlich aus, aber ich bin enttäuscht, dass sich niemand mehr die Arbeit gemacht hat, einen vernünftigen User Agent an zu geben:

Access.log andrefritsche.com XMLRPC

Und wieder sieht man, es sind POSTs. Das heißt, es wurden Daten an diese PHP Datei geschickt. Wer genau wissen will, wie das funktioniert kann bei Sucuri nachschauen. Ein sehr schöner Artikel, kann ich nur empfehlen! Aber irgendwann haben die Angreifer gemerkt: So richtig weit kommen wir nicht. Da hat sich jemand bei Name und Passwort etwas gutes einfallen lassen. Also gehen die Angreifer davon aus, du hast Plugins im Einsatz. Sie haben dafür eine Liste mit Sicherheitslücken in diversen Plugins und befeuern nun deine Seite mit allem was ihre Datenbank hergibt. Irgend ein Plugin wird schon dabei sein und der Zugriff kann erfolgen.

Du als Verteidiger musst JEDEN Angriff abwehren, und damit gewinnen. Der Angreifer, muss nur ein einziges Mal gewinnen.

Hier ist ein kleiner Ausschnitt aus den Logs, die zeigen, wie der Angreifer hier vorgegangen ist:

Access.log andrefritsche.com Bruteforce Plugins

Jede Anfrage zielte auf irgendeiner Datei ab, die eventuell vorhanden sein könnte. Aber alle Anfragen wurden vom Server mit 404 Not Found beantwortet. Ernüchternd für so einen Angreifer und gleichzeitig lehrreich, denn er hat ganz unterschiedliche Wege gesucht. Dieses Log oben, ist eines der letzten Einträge mit Nachweis des Angriffs. Davor hat er versucht bestimmte Dateien mit Parametern zu füttern, damit dem System Informationen entlockt werden können. Das sieht imposant aus:

Access.log andrefritsche.com Kreatives Bruteforcing

Man beachte die vielen Dateien, die angefragt werden und gleichzeitig der Parameter:

?password=&action=publish

Interessante Anfrage. Für gewöhnlich liefert man nach einem = einen Wert und folgt anschließend mit einem & zum nächsten Parameter. Hier wird das Passwort ignoriert und einfach gleich zur Tat geschritten. action=publish. Das hat nicht funktioniert (Errorcode 404), aber wer weiß welche Plugins und deren Lücken dies zulassen. Eine Katastrophe gar, wenn wp-config.php durch so einen Trick ausgelesen werden könnte. Dort stehen u. a. auch die Logins für die Datenbank.

Nachtrag vom 26.03.2016

Der Kreativität sind keine Grenzen gefragt. Die nachfolgenden Angriffe ein paar Tage später zeichnen sich aus durch Directory Traversing Versuche. Basierend auf schlecht programmierten Themes ist dies möglich. So sehen wir hier die vielen Versuche und einen leichten Anstieg an Redirect Errorcodes (300er HTTP Response)

Access.log andrefritsche.com Directory Traversing

Ganz schön sieht man die Versuche beispielsweise beim Theme Trinity, welches ich nicht installiert habe:

GET http://www.andresilaghi.com/wp-content/themes/trinity/lib/scripts/download.php?file=../../../../../wp-config.php

Geschickt! Durch die vielen .. ließen sich Verzeichnisbäume auf dem Server hochklettern, um anschließend den Download der wp-config.php aus zu führen. Bravo, ich bin beeindruckt von den vielen unterschiedlichen Versuchen und gespannt, wie lange meine Seite noch durchhält. :-)

Gegenmaßnahmen

Es gibt zahlreiche, ja sogar Unmengen an Plugins beispielsweise, die in WordPress helfen. So richtig traue ich denen nicht. WordPress selbst läuft ja auf einem Webserver. Also müssen hier bereits Mechanismen wirken, um die Anwendung zu schützen. Aber gleichzeitig lassen sich auch Vorkehrungen in WordPress selbst treffen. Auf Kosten der Funktionalität natürlich, aber diese bin ich bereit aufzugeben.

Zugang zu Dateien verhindern über .htaccess

Im root Verzeichnis der Anwendung, also der WordPress Installation befindet sich eine Datei mit dem Namen .htaccess. Hier lässt folgender Code den Zugriff auf sensible WordPress Dateien verschwinden:

<FilesMatch "(^\.|wp-config\.php|xmlrpc\.php|(?<!robots)\.txt|(liesmich|readme)\.*)">
Order deny,allow
Deny from all
</FilesMatch>

Damit ist auch der Zugriff auf die xmlrpc.php Weg. Ping/Trackbacks von anderen Blogs sind damit nicht mehr möglich. Aber irgendwie hat mir das nicht gereicht. Der Webserver (Apache) wird sich zwar um den Zugriff kümmern, aber was passiert wenn nicht? Ein blöder Zufall, ein Bug, irgendetwas verhindert das korrekte Parsen dieses Textes. Ein Backup muss her.

xmlrpc.php in WordPress deaktivieren

Dies erledigt man in der functions.php. Dazu muss man zu Design -> Editor -> functions.php. Ich habe folgende Zeile Code eingetragen, um xmlrpc zu deaktivieren:

add_filter( 'xmlrpc_enabled', '__return_false');

Fazit

Leider kann ich kein Fazit ziehen. Ein Angriff erfolgte, ich habe reagiert und hoffe, dass die Angreifer beim nächsten Mal ebenfalls kein Glück haben. Natürlich könnte ich noch meine Kennwörter ändern, damit ich auf Nummer Sicher gehe. Aber ansonsten bleibt die Hoffnung, dass WordPress sich stetig weiter verbessert und kritische Bugs, Stück für Stück beseitigt werden. Falls du diese Seite irgendwann nicht mehr sehen solltest, oder eine Hackergruppe sie defaced hat, dann waren die bösen Jungs einen Tick schneller als ich. :-) Wer aber tiefer ins Detail gehen will, dem sei durch Mike Kuketz geholfen. Er hat ausgezeichnete Artikel zum Thema WordPress Sicherheit veröffentlicht.

Art der Angriffe

  • Password Bruteforcing beim Login
  • Beschleunigung des Bruteforcings mit xmlrpc.php
  • “Plugin/Theme” Bruteforcing / Ausfindig machen von unsicheren Plugins

Quell IP Adressen

  • Russland
  • Ukraine
  • China
  • Schweden

Bücher zum Thema

 

Blog aktiv unterstützen

Artikel teilen:

13 Gedanken zu „Angriff auf andrefritsche.com – Wie sichert man WordPress ab?

  • 27. März 2016 um 12:19
    Permalink

    Hallo André,
    vielen Dank für deinen aufschlussreichen Beitrag. Hast du dann eigentlich vorab die wp-login.php nicht über die .htaccess oder über einen Verzeichnissschutz im Apache selber geschützt? In der Apache Konfigurationsdatei zum Blog habe ich die wp-config.php separat mit einem Zugriffsschutz versehen. Ich denke das ist doch schon eine größerer Hürde, da man ja erst den Zugriff zur wp-login.php herausfinden muss. Sollte man auch die wp-config.php so absichern? Gibt es noch weitere Möglichkeiten, um die WordPress Seite zu schützen? Vor allem hinsichtlich der Plugins?

    Antwort
    • 27. März 2016 um 13:20
      Permalink

      Hallo Markus, danke für den Kommentar. Genau den Punkt muss ich noch zusätzlich konfigurieren. Momentan schützt vor allem Akismet und erkennt Bruteforcing. Es gibt weitere Plugins, aber so richtig viel bringen nur die wenigsten. Ich werde mich aber näher damit beschäftigen und berichten. :-)

      Antwort
      • 27. März 2016 um 14:15
        Permalink

        Mit den zusätzlichen Plugins bin ich mir auch nicht sicher. Ich habe noch Wordfence im Einsatz. Diese meldet schon immer viele geblockte IP´s und Länder. Aber ob das wirklich sehr viel bringt bin ich mir auch nicht sicher. Ich denke der Verzeichnisschutz ist eines der effektivsten Mittel. Ich habe übrigens auch meinen Zugang zu phpmyadmin so abgesichert. Mit Akismet bin ich mir nicht so sicher, da es ja in Deutschland rechtlich umstritten ist! Freue mich auf deine Berichte, wenn du dich damit weiter beschäftigst.

        Antwort
        • 27. März 2016 um 17:43
          Permalink

          Über Verhalten lässt sich ja sehr viel erkennen und blocken. Ob Wordfence das alles liefert müsste ich mir genauer anschauen. Mein Webhoster allerdings bietet mir die Möglichkeit bestimmte IPs firewallseitig zu blockieren. Aber bei laufend wechselnden Adressen ist das wohl nicht immer gegeben.

          Vielen Dank für das positive Feedback :-)

          Antwort
    • 27. März 2016 um 22:25
      Permalink

      Vielen Dank für das Angebot, aber ich überwache momentan selbst. Komme darauf zurück, wenn es interessanter werden sollte :-)

      Antwort
  • 28. März 2016 um 10:04
    Permalink

    Moin,
    “Wordfence” wurde ja bereits angesprochen. Ich halte Wordfence in einem Punkt für ziemlich geschickt: Das Vergleichen der lokal installierten WP-Dateien (Core, Themes, Plugins) mit den Dateien, die von WordPress selbst in den Repositories vorgehalten werden. Das kann man sicherlich auch mittels anderer Tools erledigen – Wordfence macht das aber schonmal ganz gut.
    Hintergrund ist der, dass man so recht einfach diese typischen base64-Codeschnipsel findet, die bei erfolgreichen Hacks eingefügt werden. I.d.R. merkt man ja selbst nicht einmal, wenn man selbst zum unfreiwilligen Spam-Versender mutiert ist. o_O

    Antwort
    • 29. März 2016 um 18:50
      Permalink

      Hi Marc, danke für die vielen Tipps. Müssen wir mal bei Gelegenheit besprechen welche Tricks du da alles angewendet hast und danke für’s Mitmachen hier :-)

      Antwort
  • 29. März 2016 um 19:23
    Permalink

    Mich interessieren auch die ganzen Tricks und Möglichkeiten, welche ihr verwendet um WordPress abzusichern. Wie überwacht ihr eigentlich euer Log´s? Ich habe Logwatch im Einsatz. Kennt ihr noch andere Alternativen, mit welchem man sich die Logs schön und übersichtlich anzeigen lassen kann? Ich bin gerade noch am testen mit piwik, ob man hier auch HTTP Fehler usw. angezeigt bekommt? Für die Analyse ist es sonst ja ziemlich gut! Bin auch gespannt Marc, was es noch so alles an Sicherheitstipps gibt.

    Antwort
    • 30. März 2016 um 18:22
      Permalink

      Hallo Markus. Logwatch selbst halbe ich noch nie getestet. Piwik hingegen schon und es hat mir gut gefallen, da die vielen Statistiken aussagekräftig sind. Ansonsten ist der sicherste Weg der, über eine Web Application Firewall. Mod_security bietet sich als kostenfreies Tool an. Marc hat da aber mehr Erfahrung als ich. Früher habe ich mit PHP IDS gearbeitet. Das ist aber leider sehr inaktiv was die Entwicklung angeht. Gruß Andre

      Antwort
      • 5. April 2016 um 09:00
        Permalink

        OK vielen Dank. Also ich bin jetzt wieder weg von Piwik, hat mich nicht so überzeugt. Logwatch ist auf jeden Fall super. Man erhält täglich einen Email Bericht über Aktivitäten auf deinem Server. Das Mod_security ist ein Apache Modul oder?. Das werde ich mir auf jeden Fall mal näher ansehen.
        Gruß Markus

        Antwort
        • 5. April 2016 um 17:44
          Permalink

          Ich schreibe demnächst auch mal ein bisschen was zu mod_security. Das ist ein Apache-Modul und eine Art WAF. Damit ist es dann beispielsweise auch möglich, solche Angriffe auf die xmlrpc oder wp-login in gewisser Weise zu kontrollieren. Also beispielsweise mit gezielten http-Status-Codes zu reagieren, falls innerhalb einer gewissen Zeit eine bestimmte Anzahl von Aufrufen auf diese Datei stattfinden (beispielsweise “403” für eine solche IP-Adresse, etc.).
          In der Kurzfassung installiert man mod_sec zunächst, bzw. aktiviert das Modul und “loggt” zunächst mal mit, was mod_security blockieren würde, um daraus dann später die eigenen Filterregeln zu erstellen und letztendlich mod_sec in den aktiven Modus zu schalten. I.d.R. ist es nicht so sinnvoll, mod_sec sofort aktiv zu schalten, da das Modul mit den Grund-Filtern schon mal seeeeehr viel per se blockiert und so beispielsweise große Teile von WordPress gar nicht mehr funktionieren, bzw. das Sicherheitsloch “PHP” in großen Teilen fast abschaltet. Ist eben ziemlich strikt… ^^
          -> logwatch hatte ich übrigens auch eine Zeit lang im Einsatz. Das ist schon eine ganz gute Sache, je nachdem, wieviele Server man so im Einsatz hat. Mit der Zeit habe ich für mich dann allerdings bemerkt, dass ich die morgentlichen Mails von logwatch nicht mehr sehr aufmerksam gelesen hatte. Ab einer gewissen Größe finde ich dann Zabbix u.a. für solche Überwachungen ganz cool. Eigentlich ein reines Monitoring (Stichwort: “wie Nagios – nur bedienbar…” ;-)), aber mit sehr mächtigen Werkzeugen, um von den Servern weitere wichtige Informationen einzusammeln, oder gar Aktionen auszulösen (Updates, Festplatten, Logs, etc.).

          Antwort

Kommentar verfassen