WordPress im Visier
Kommentare

Immer wieder gibt es Angriffe auf WordPress-Blogs. Und viele davon sind erfolgreich. Ist WordPress also unsicher? Und wenn ja, wieso? Und wenn nicht, was ist da dann los? Viele Fragen, auf die es einige recht einfache Antworten gibt.

Wenn man etwas untersuchen will, muss man zuerst einmal genau festlegen, was dieses „etwas“ genau ist. Was ist also WordPress? – Die Antwort darauf ist nicht ganz einfach, denn im Fall von WordPress müssen wir mehrere Fälle unterscheiden.

WordPress, die Bloganwendung

Ganz allgemein ist WordPress die in PHP geschriebene Blog-Anwendung, die auf WordPress.org zum Download angeboten wird. WordPress.org ist auch das erste potenzielle Angriffsziel: Gelingt es einem Angreifer, sich Zugriff auf den Sourcecode zu verschaffen, kann er ihn so manipulieren, dass er Code für Drive-by-Infektionen [1] enthält oder nach der Installation auf einem Server dort eine Hintertür öffnet. Einen entsprechenden Angriff gab es zum Beispiel im März 2007, als die Downloaddatei der Version 2.1.1 so manipuliert wurde, dass darüber beliebiger PHP-Code ausgeführt werden konnte [2]. Außer dem Code von WordPress selbst können auf WordPress.org auch die darüber verbreiteten Plug-ins manipuliert werden, wie es zum Beispiel im Juni 2011 geschah, als in einige Plug-ins Code für eine Hintertür integriert wurde [3].

Darüber hinaus enthält WordPress wie jede andere Software auch Schwachstellen, die entdeckt und behoben oder auch entdeckt, ausgenutzt und erst dann behoben werden – je nachdem, ob der Finder der Schwachstelle mehr Interesse an ihrer Korrektur oder ihrer Ausnutzung hat. Im Allgemeinen werden Schwachstellen nach ihrem Bekanntwerden von den WordPress-Entwicklern recht zügig behoben, die aktualisierte Version muss dann „nur noch“ überall installiert werden. Und daran hapert es mitunter.

WordPress.com, der Blog-Hoster

Außer der reinen Bloganwendung gibt es die auf WordPress.com laufende Version davon, die von Bloggern ohne weitere Installation genutzt werden kann. Hier befindet sich die Software immer auf dem aktuellen Stand, man sitzt ja direkt an der Quelle und hat selbstverständlich kein Interesse daran, potenziellen Angreifern die Arbeit zu erleichtern. Auch WordPress.com ist natürlich ein Ziel für Angriffe, zum Beispiel kam es im April 2011 zur Kompromittierung mehrerer Server [4], allerdings ohne weitreichende Folgen.

WordPress, selbst gehostet

Kommen wir zur letzten Variante von WordPress: den selbst gehosteten Installationen. Dabei ist es erst einmal egal, ob es sich dabei um die Blogs von Privatpersonen oder Unternehmen handelt, und ob sie auf einem Share-Hosting-Account bei einem Massen-Hoster, einem Root-Server bei einem kleineren Hoster oder dem internen Webserver eines Unternehmens installiert sind.

Diese individuellen Installationen sind teilweise nicht auf dem aktuellen Stand, und teilweise sind sie unsicher konfiguriert. Dabei ist es egal, ob das aus Unfähigkeit, Desinteresse, Zeitmangel oder welchem Grund auch immer so ist: Im Endeffekt führt es zu unsicheren WordPress-Installationen, die angegriffen werden können und die angegriffen werden.

Plug-ins ohne Ende

Ein weiterer Punkt, der beim Betrachten der Sicherheit von WordPress nicht übersehen werden darf, sind die vielen Plug-ins, die es gibt. Viele davon werden laufend gewartet, für etliche gab es schon seit Längerem keine normalen Updates mehr, Schwachstellen werden aber trotzdem behoben, und manche werden von ihren Entwicklern schon seit Langem nicht mehr unterstützt.

Schwachstellen werden in allen Varianten gefunden, zumindest in der letzten aber nie behoben. Aber selbst wenn die Schwachstellen im Plug-in schnell behoben werden, sind sie damit noch lange nicht aus den WordPress-Installationen verschwunden. Dafür müssen die Patches bzw. Updates erst mal installiert werden, was teilweise nur verzögert oder gar nicht passiert.

Auf WordPress.com werden die Plug-ins zentral verwaltet und können ggf. schnell aktualisiert oder auch deinstalliert werden. Individuelle Plug-ins sind auf WordPress.com generell verboten, die Betreiber müssen also nur auf die von ihnen ausgewählten Plug-ins achten.

Bei selbst gehosteten Installationen können alle im Internet verfügbaren Plug-ins installiert werden. Ob überhaupt Updates installiert werden und wie schnell das passiert, hängt vom jeweiligen Betreiber ab. Leider sind darunter viele, die es zwar gerade noch schaffen, WordPress und Plug-ins zu installieren, beim Updaten aber schon überfordert sind. Generell hat die Erfahrung gezeigt, dass außerhalb von WordPress.com sehr viele Plug-ins mit bekannten Schwachstellen installiert sind.

Beispiele für Angriffe

Nachdem Sie nun die verschiedenen Angriffsziele kennen, ist es Zeit für ein paar Beispiele. Zu WordPress selbst und WordPress.com gibt es oben bereits Beispiele. Als Erstes geht es im Folgenden um einen Angriff auf einen Massenhoster.

Ein bösartiger Kunde bei Network Solutions schlägt zu

Im April 2010 liefen Angriffe auf WordPress-Installationen auf von Shared Hostern, insbesondere Network Solutions, gehosteten Sites. Dabei wurde vom Angreifer die siteurl in der Tabelle wp-option geändert, sodass die Besucher der Website sofort auf eine für Drive-by-Infektionen [1] präparierte Seite umgeleitet wurden.

Im Forum auf WordPress.org wurde anfangs von einem SQL-Injection-Angriff ausgegangen [5]. Auffällig war, dass fast alle betroffenen Blogs bei Network Solutions gehostet wurden [6]. David Dede von Sucuri hat die Angriffe dann genauer untersucht und festgestellt, dass die Lösung viel einfacher war [7], [8]: WordPress speichert die Zugangsdaten für die Datenbank als Klartext in der Datei wp-config.php, für die viele Benutzer unsichere Zugriffsrechte gesetzt hatten. WordPress empfiehlt für die Datei wp-config.php 400 oder 440 zu verwenden [9]. Damit wäre die Datei nur vom Benutzer oder vom Benutzer und vom Webserver zu lesen. Viele Benutzer verwendeten aber die unsichere Einstellung 755, sodass jeder die Datei lesen konnte.

Bei Network Solution sorgte der Vorfall für Verwirrung, es dauerte etwas, bis man eine eigene Lösung präsentieren konnte [10], [11], [12]. Ein bösartiger Benutzer von Network Solutions durchsuchte in der Zwischenzeit die Server mit einem Skript nach den wp-config.php-Dateien und sammelte die Zugangsdaten ein, mit denen er dann auf die Datenbanken zugreifen und die Einträge manipulieren konnte.

Go Daddy hat ein Problem und merkt es erst nicht

Im Mai 2010 erwischte es die nächsten WordPress-Blogs bei Shared Hostern, diesmal bei Go Daddy [13]. Regina Smola hat den Angriff untersucht und Folgendes herausgefunden [14]:

  • die meisten betroffenen Server verwendeten das veraltete PHP 4.x
  • die Zugriffsrechte für einen Teil der oder alle Verzeichnisse und/oder Dateien war auf 777 oder 755 gesetzt
  • in der Konfigurationsdatei wp-config.php waren keine oder schwache Authentication Unique Keys (Geheime Schlüssel) angegeben
  • für Datenbanken, FTP-Zugang und wp-admin wurden schwache Passwörter verwendet

Mit anderen Worten: Die WordPress-Installationen waren unsicher konfiguriert, was den Angriff darauf vielleicht erklärt. Es ging aber noch weiter: Go Daddy behauptete, dass nur veraltete WordPress-Versionen betroffen waren [15], während laut David Dede auch aktuelle Versionen gehackt wurden [16]. Etwas später stellte sich heraus, dass sich evtl. eine Schwachstelle in Go Daddys Infrastruktur befand, Go Daddy an der Aufklärung aber kein Interesse hatte [17]. Die Behauptung, die WordPress-Versionen seien veraltet, war die Folge eines Fehlers bei Go Daddy: Dort hatte man sich auf die Versionsangabe des Hosting Control Panels verlassen, das aber nur die darüber installierte WordPress-Version anzeigte. Wenn die Benutzer das Update für WordPress aus dessen Administrationsbereich heraus installierten, bekam das Control Panel das nicht mit und zeigte weiter die alte Version an.

Ursache der Manipulationen an WordPress (und anderen Webanwendungen) war ein PHP-Skript, das von den Cyberkriminellen auf den Go-Daddy-Server eingeschleust wurde [18]. Wie genau, wurde nie bekannt gegeben, Go Daddy hat lediglich zugegeben, dass es eine Schwachstelle in der eigenen Infrastruktur war [19]. Die Angriffe gingen auf jeden Fall noch einige Zeit weiter [20], [21]. Was im Forum auf WordPress.org nicht besonders gut aufgenommen wurde [22].

Kommen wir nun zu Angriffen auf einzelne Blogs.
Robert Scoble mag keine Updates, dafür Hacker seinen Blog

Der Blog von Robert Scoble (Scobleizer) wurde im August 2009 Opfer eines Hackerangriffs [23]. Schuld war seine veraltete WordPress-Installation, der Angreifer konnte über eine in der aktuellen Version behobene Schwachstelle Scobles Administratorpasswort zurücksetzen und über das neue Passwort auf den Blog zugreifen. Scoble erklärte seine Abneigung gegen Updates mit seiner Arbeit für Microsoft: „I didn’t update WordPress because I used to work at Microsoft and was scared (updates sucked 1/8th of the time) …“. – Ein böser Fehler, wie er schmerzhaft feststellen musste.

Es gibt in diesem Fall allerdings eine kleine Ungereimtheit: Die in WordPress 2.8.4 behobene Schwachstelle erlaubt laut Matt Mullenweg zwar das Zurücksetzen des Passworts, das neue Passwort wird aber an den Accountinhaber geschickt [24]. Was zwar unschön ist, aber eigentlich keinen Zugriff auf den Blog erlaubt, da das neue Passwort ja an Robert Scoble gesendet worden wäre und nicht an den Angreifer. Vermutlich wurde Robert Scoble also das Opfer einer älteren Schwachstelle, zum Beispiel den in Version 2.8.3 behobenen Schwachstellen CVE-2009-2853 [25] oder CVE-2009-2854 [26], die das Erlangen von Admin-Rechten bzw. unautorisierte Änderungen erlaubten. Denn Scobles Blog lief mit einer 2.7.x-Version [27]. Übrigens schlugen die Angreifer mindestens zwei Mal zu: Beim ersten Mal hinterließen sie Verweise auf Porno-Sites in mehreren Einträgen, die Scoble entfernte. Daraufhin kehrten die Angreifer zurück und löschten die Einträge von rund zwei Monaten, für die Scoble kein Back-up hatte. Auch ein böser Fehler, den er sicher sehr bereut hat. Außerdem hinterließen die Angreifer Schadcode, der Google dazu bewegte, den Blog aus dem Index zu schmeißen.

Reuters – aktuelle Nachrichten, veraltetes WordPress

Im August 2012 wurde die Nachrichtenagentur Reuters das Opfer von Angriffen [28]. Unter anderem wurden falsche Nachrichten im Blog eines Journalisten auf der Reuters-Website veröffentlicht. Ursache war eine veraltete WordPress-Version [29]: Statt der aktuellen Version 3.4.1 wurde Version 3.1.1 samt etlicher bekannter (und in der aktuellen Version behobener) Schwachstellen verwendet.

Außer Cyberkriminellen, die die Blogs selbst angreifen, gibt es auch noch Schadsoftware, die sich über WordPress-Blogs hermacht. Ein kompromittierter Blog muss also nicht zwingend einem gezielten Hackerangriff zum Opfer gefallen sein, er kann sich auch einfach einen Wurm eingefangen haben.

WordPress mit Wurmbefall

Im August/September 2009 machte sich ein Wurm über WordPress-Installationen her. Der Wurm suchte nach WordPress-Installationen mit bestimmten Schwachstellen, verschaffte sich dort über diese Schwachstellen einen Administratorzugang und verbreitete danach Spam und Schadsoftware über den übernommenen Blog. Damit der neue Zugang nicht zu schnell entdeckt wurde, wurde der neu angelegte Benutzer mittels JavaScript aus der Liste der Benutzerkonten ausgeblendet [30].

Nachdem der Wurm entdeckt wurde, haben die Entwickler die ausgenutzten Schwachstellen behoben – in Version 2.8.3 [31]. Es handelt sich also um die bereits beim Angriff auf Robert Scobles Blog erwähnten Schwachstellen mit den CVE-IDs CVE-2009-2853 [25] oder CVE-2009-2854 [26]. Scobles Blog könnte theoretisch beim ersten Angriff auch dem Wurm zum Opfer gefallen sein, beim zweiten Angriff jedoch nicht, da der Wurm keine „Vandalismusfunktion“ besitzt, das Löschen von Beiträgen ist nicht vorgesehen. Es wäre ja auch sehr kontraproduktiv: Der eingeschleuste Schadcode soll ja möglichst niemandem auffallen, gelöschte Einträge stoßen den Betreiber aber geradezu mit der Nase darauf, dass da irgendetwas nicht stimmt.

Übrigens hat der Wurm allem Anschein nach so genannte 0-Day-Schwachstellen ausgenutzt, das heißt Schwachstellen, für die es beim ersten Angriff noch keinen Patch gibt. Denn den haben die Entwickler ja erst nach dem Auftauchen des Wurms entwickelt.

WordPress als Exploit-Schleuder

Im Januar 2012 wurden WordPress-Installationen für Drive-by-Infektionen präpariert [32]. Dabei gingen die Angreifer mehrere Wege: Über Schwachstellen in zwei Plug-ins und ausgespähte FTP-Zugangsdaten wurden WordPress-Seiten präpariert, oder es wurde über nicht genannte Funktionen eine präparierte HTML-Seite hochgeladen und die Opfer dann gezielt auf diese Seite im Uploadverzeichnis gelockt.

Diese Angriffe sind ein gutes Beispiel für die Verwirrung, die nach einem Massenangriff zumindest anfangs herrscht: Man erkennt zwar, dass Schadcode in die Blogs eingeschleust wurde, und was der macht, lässt sich dann leicht ermitteln. Aber wie er in die Seiten gelangt ist, lässt sich manchmal nicht so einfach feststellen. Und wenn sich die Schwachstelle nicht ermitteln lässt, kann sie auch nicht beseitigt werden. Veraltete Anwendungen kann man auf den aktuellen Stand bringen und damit bekannte Schwachstellen beheben, falls der Angriff aber über eine unbekannte Schwachstelle erfolgte, wird der Blog meist schnell erneut kompromittiert, und die Suche nach dem Einfallstor geht von vorne los.

Als letztes Beispiel dient ein Angriff über ein Plug-in.
TimThumb – beliebt bei Entwicklern, Nutzern und Cyberkriminellen

TimThumb dient dazu, die Größe von Bildern zu ändern [33]. Deswegen ist es bei Entwicklern und Benutzern beliebt und wird vielfach eingesetzt. Leider kann man darüber in einigen Versionen aber auch einen Server kompromittieren [34]. Und das macht es bei den Cyberkriminellen sehr beliebt. Vor allem weil es von sehr vielen WordPress Themes und -Plug-ins genutzt wird, dadurch sehr verbreitet ist und selten aktualisiert wird, da die meisten Benutzer gar nicht wissen, dass es bei ihnen installiert ist.

Die im August 2011 entdeckte 0-Day-Schwachstelle ist ausführlich dokumentiert [35], [36] und es gibt auch einen öffentlichen Exploit, also Code zum Ausnutzen der Schwachstelle [37]. Die Schwachstelle erlaubt es, ein als Bild getarntes PHP-Skript auf den Server zu laden und danach auszuführen.

Kurz nach Bekanntwerden der Schwachstelle kam es zu einer regelrechten Angriffswelle mit Masseninfektionen, die zum Beispiel von Websense [38], [39] und Trend Micro [40] dokumentiert wurden. Mitte August wurden 25 betroffene WordPress-Plug-ins und 45 betroffene WordPress Themes gezählt [41]. Meist wurde bei den Angriffen Code für Drive-by-Infektionen oder die Verbreitung von Scareware [42] in die Blogs integriert, aber teilweise nutzten die Cyberkriminellen auch die Gelegenheit, um eine Hintertür zu hinterlassen [43].

Je nach Testmethode wurden 1 Million [44] oder mehr infizierte Websites gezählt. Wohlgemerkt im Herbst 2011, aber mit den Infektionen war auch im Mai 2012 noch nicht Schluss [45].

Das ist fast wie im Märchen: „Und wenn sie nicht gepatcht wird, dann wird sie auch noch heute angegriffen“. Inzwischen wurden die Schwachstellen längst behoben, es sind aber noch genug angreifbare Versionen im Web verteilt, um die Schwachstelle auch nach über einem Jahr noch für Cyberkriminelle interessant zu machen: Im Oktober 2012 wurde ein JavaScript-Wurm entdeckt, der die infizierten Rechner unter anderem dazu nutzt, um bei Google nach über die Schwachstelle in TimThumb angreifbaren Servern zu suchen [46]. Die verrät er dann an seine Entwickler. Was die mit dieser Information machen, dürfte klar sein.

TimThumb aktualisieren

Wenn Sie einen Shell-Zugang zu Ihrem Server haben, können Sie mit einem Befehl alle installierten TimThumb-Plug-ins finden und bei Bedarf mit einem weiteren Befehl pro veraltetem TimThumb-Skript aktualisieren. Das Vorgehen basiert auf einem Vorschlag, den Tony Perez von Sucuri in einem Blogeintrag gemacht hat [47]. Sein Ansatz war aber verbesserungsfähig, da sein curl-Aufruf die HTTP-Header in das PHP-Skript schreibt, wo sie erstens nichts zu suchen haben und zweitens stören. Zuerst suchen Sie mittels

admin:/var/www/ # grep -Eir --include "*thumb.php" 'define.*VERSION' .

nach allen installierten TimThumb-Plug-ins. Das führt zu einer Ausgabe wie zum Beispiel

./pfad/zum/theme/timthumb.php:define ('VERSION', '1.33');   // Version of this script 
./pfad/zu/plugin1/thumb.php:define ('VERSION', '2.1.1'); // Version of this script
./pfad/zu/plugin2/timthumb.php:define ('VERSION', '2.8.11'); // Version of this script

Alle Skripte, die älter als die aktuelle Version sind (zurzeit ist Version 2.8.11 aktuell) können Sie danach mit folgendem Befehl mit der aktuellen Version überscheiben:

admin:/var/www/ # curl http://timthumb.googlecode.com/svn/trunk/timthumb.php > /Pfad/zur/Datei/Dateiname.php

Den Pfad zur Datei und den Dateinamen können Sie aus der grep-Ausgabe übernehmen. Achten Sie dabei darauf, dass der vollständige Pfad benötigt wird. Falls Sie also den grep-Aufruf wie im Beispiel im Verzeichnis /var/www/ ausgeführt haben, ergeben sich für die ersten beiden Skripte folgende curl-Aufrufe:

admin:/var/www/ # curl http://timthumb.googlecode.com/svn/trunk/timthumb.php > /var/www/pfad/zum/theme/timthumb.php
admin:/var/www/ # curl http://timthumb.googlecode.com/svn/trunk/timthumb.php > /var/www/pfad/zu/plugin1/thumb.php

Nach all den Schwachstellen im Rechner gibt es zum Abschluss noch eine Schwachstelle vor dem Rechner: Die Benutzer und ihre Passwörter.

Unsichere Passwörter

Für manche Angriffe kann der Betreiber der Plattform nichts: Wenn die Benutzer unsichere Passwörter verwenden oder ihre sicheren Passwörter unsicher verwenden. So konnte zum Beispiel im Oktober 2012 ein Cyberkrimineller tausende auf WordPress.com gehostete Blogs mit Werbung verunzieren, weil die Benutzer ihre WordPress-Passwörter auch anderswo im Internet verwendet hatten, wo sie ausgespäht worden waren [48]. Damit Ihnen so etwas nicht passiert, müssen Sie nur zwei simple Regeln beachten:

  1. Verwenden Sie sichere Passwörter, die sich nicht über einen Wörterbuchangriff knacken lassen. Gute Passwörter sind lang und bestehen aus Groß- und Kleinbuchstaben, Ziffern und möglichst auch Sonderzeichen.
  2. Verwenden Sie jedes Passwort nur für genau einen Zweck. In letzter Zeit gab es mehrmals Passwortlecks, bei denen Unmengen von Passwörtern ausgespäht wurden. Wird ein Passwort bei mehr als einer Website etc. verwendet, kann der Angreifer damit nicht nur auf den angegriffenen Server zugreifen, sondern auch auf weitere. Er muss nur ein bisschen suchen, bis er weitere Dienste findet, für die die gleichen Zugangsdaten gültig sind.
Fassen wir zusammen …

Sie haben nun alle möglichen Angriffe kennengelernt: Die unsichere WordPress-Konfiguration bei Network Solutions, eine von WordPress unabhängige unsichere Infrastruktur bei Go Daddy, veraltete und damit unsichere WordPress-Versionen bei Robert Scoble und Reuters, einen Wurm für WordPress, Angriffe über WordPress- und Plug-in-Schwachstellen und nicht zu vergessen unsichere Passwörter.

Es gibt also ziemlich viele Wege, über die ein Angreifer einen WordPress-Blog kompromittieren kann. Sehr wahrscheinlich mehr, als Sie sich vorstellen können. Suchen Sie ruhig einmal in einer Schwachstellendatenbank nach „WordPress“. Sie werden erstaunt sein, wie viele Schwachstellen es gibt – die meisten davon in Plug-ins.

Der dänische Sicherheitsdienstleister Secunia erfasst nur selbst geprüfte und bestätigte Schwachstellen und führte am 25. Januar 2013 für den Suchbegriff WordPress 676 Advisories (mit oft mehreren Schwachstellen) und 461 Produkte auf [49]. In der Exploit-DB werden Exploits, also Code zum Ausnutzen von Schwachstellen, gesammelt: Am Stichtag gab es insgesamt 279 Exploits für WordPress [50]. In der CVE-Datenbank werden Schwachstellen eindeutige Identifier, die CVE-IDs, zugewiesen – WordPress lieferte am Stichtag 358 Ergebnisse [51]. Und dann gibt es noch WordPress Exploit, eine Liste, die Exploits für WordPress und seine Plug-ins aufführt [52] – am Stichtag mit 420 Einträgen.

Nun muss man dabei die WordPress- und Plug-in-Versionen abziehen, die so alt sind, dass sie allerhöchstens noch in Archive.org zu finden sind, aber es bleiben genug Möglichkeiten übrig, einen nicht aktuellen WordPress-Blog anzugreifen. Und teilweise auch aktuelle Installationen, da es für einen Teil der Schwachstellen in Plug-ins keine Patches gibt – oft weil die Entwickler die Weiterentwicklung längst aufgegeben haben.

Alte Installationen – Freiwild für Cyberkriminelle

Chester Wisniewski von Sophos hat sich im Juli 2011 anlässlich der Veröffentlichung von WordPress 3.2 stichprobenartig angesehen, welche PHP- und WordPress-Versionen von kompromittierten WordPress-Installationen verwendet werden [53]. Von den dreißig zuletzt von Sophos entdeckten URLs, die zu Schadsoftware verbreitenden WordPress-Installationen führten, konnte er für zehn Server sowohl PHP- als auch WordPress-Versionen ermitteln.

Die neueste PHP-Version war die im Januar 2011 veröffentlichte (und im Juli nicht mehr unterstützte) Version 5.2.17 (die älteste 4.4.3), aktuell war damals Version 5.3.6.

Bei WordPress sah es nicht besser aus: Die neueste Version war 3.1.2 (die ältestes 2.3), die neben der gerade veröffentlichten Version 3.2 aktuelle Version war 3.1.4 mit mehr als zwei Dutzend sicherheitsrelevanten Verbesserungen gegenüber Version 3.1.2.

WordPress absichern

Kommen wir zum entscheidenden Punkt: Wie kann man WordPress absichern? Wer sich nicht mit der Installation von Updates abmühen möchte und keine Lust hat, etwas Zeit in die Absicherung seiner WordPress-Installation zu investieren, sollte seinen Blog von WordPress.com hosten lassen. Aber ich gehe davon aus, dass die meisten von Ihnen problemlos in der Lage sind, ihren Blog aktuell zu halten und abzusichern. Denn das ist gar nicht so schwer.

Die wichtigste Regel lautet: „Halten Sie Ihren Blog aktuell!“ Am besten installieren Sie alle Updates so schnell wie möglich, auf jedem Fall aber die sicherheitsrelevanten. Dabei ist es egal, ob damit bereits ausgenutzte Schwachstellen gepatcht werden oder welche, die bisher nicht öffentlich bekannt waren. Jeder kann sich den WordPress-Sourcecode herunterladen, es ist also kein Problem, aus einem Patch die damit geschlossene Schwachstelle zu ermitteln und einen Exploit dafür zu schreiben.

Die zweitwichtigste Regel: „Haben Sie ein aktuelles Back-up!“ Im Falle eines Angriffs werden Sie froh sein, Ihren Blog zügig wiederherstellen zu können. Auch dann, wenn nichts gelöscht, sondern „nur“ Daten manipuliert wurden. Im Allgemeinen ist es einfacher, WordPress neu zu installieren und die Daten wieder einzuspielen, als eingefügten Schadcode und mögliche Manipulationen wie eine in irgendein Skript integrierte Hintertür zu suchen und zu löschen. Vor allem, weil dabei immer die Gefahr besteht, etwas zu übersehen.

Die dritte Regel lautet: „Härten Sie Ihren Blog!“, sichern Sie ihn vor Angriffen. Eine offizielle Anleitung zum Härten von WordPress gibt es auf WordPress.org [54].

Zum dort unter anderem vorgeschlagenen „Security through obscurity“, dem Umbenennen des Administratoraccounts und der Änderung des Tabellenpräfixes, erscheint mir eine Ergänzung nötig: Wie in der Anleitung erwähnt, ist „Security trug obscurity“ generell kein brauchbares Konzept. Im Fall des Tabellenpräfixes erhöht dessen Änderung aber tatsächlich die Sicherheit, da die meisten SQL-Injection-Angriffe vom Default-Wert ausgehen und an einem geänderten Präfix scheitern. Sofern aber eine Fehlermeldung die Tabellennamen verrät, war die Änderung vergeblich, der Angreifer kann seinen Exploit leicht anpassen.

Die Änderung des Administratoraccounts halte ich für überflüssig. Betrachten Sie die oben beschriebenen Angriffe: In keinem davon hätte eine Änderung des Accountnamens irgendeine Auswirkung gehabt. Ein geänderter Accountname hilft nur gegen Brute-Force-Angriffe, da der Angreifer dann nicht nur das Passwort, sondern auch den Benutzernamen des Administrators erraten muss. Aber in dem Fall sollte man sich einfach auf sein gutes Passwort verlassen, bei allen anderen Accounts macht man es ja auch.

Und weil ich gerade beim Thema bin: Das Verstecken der WordPress-Versionsnummer erzeugt nur ein falsches Gefühl von Sicherheit und ist den Aufwand nicht wert. Denn dadurch wird nur verhindert, dass der Blog bei einer entsprechenden Google-Suche sofort als angreifbar erkannt wird. Die Schwachstellen verschwinden dadurch nicht, die Exploits funktionieren trotzdem. Im Zweifelsfall probiert ein Angreifer einfach alle Exploits aus, statt nur gezielt die zur Version passenden zu verwenden. Und außerdem gibt es ja immer noch die Versionsnummern der Plug-ins und Themes, aus denen sich ggf. auch auf die WordPress-Version schließen lässt.

Eine Anleitung für weitere Verbesserungen der Sicherheit, zum Beispiel durch das Anpassen von Zugriffsrechten, gibt es von Daniel Cid von Sucuri [55]. Leider vertragen sich diese Verbesserungen nicht mit Shared Hosting.

Fazit

WordPress ist gefährdet. Aber nicht, weil es von Haus aus unsicher ist, sondern weil es oft unsicher betrieben wird und als eine der beliebtesten Bloganwendungen sehr weit verbreitet ist. Und das zieht natürlich die Cyberkriminellen an. Für die ist es viel lukrativer, möglichst automatisiert zigtausende WordPress-Blogs zu kompromittieren als einige wenige Installationen einer Webanwendung, die außer dem Entwickler nur eine Handvoll Betreiber hat (hochrangige Ziele natürlich ausgenommen, Facebook als Anwendung läuft natürlich auch nur bei Facebook und zieht trotzdem bzw. gerade deswegen Angreifer an wie das Licht die Motten).

Also: Sichern Sie Ihre Installation ab, und falls es doch einmal zu einem Angriff kommt, richten Sie sich nach der entsprechenden Anleitung von WordPress.org [56]. Im Zweifelsfall ist „Löschen und neu installieren“ immer die sicherste Lösung. Ein aktuelles Back-up Ihres Blogs haben Sie ja hoffentlich. Wenn nicht, Sie wissen ja: Wer den Schaden hat, braucht für den Spott nicht zu sorgen!

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -