Irgendwann musste es einmal passieren: Wir wurden Opfer eines (vermutlich) russischen Hackers, der eine Schwachstelle in der WordPress-Installation ausnutzte, um unseren Server für den Vertrieb von Potenzpillen (oder noch schlimmer von Schadware, die auf den Potenzpillen-Seiten installiert war) zu missbrauchen. Der Schaden ist behoben, nun folgt ein kurzer Rückblick.
Wie das geht? So genau wissen wir das nicht, aber in einer Art detektivischer Kleinarbeit haben wir bei der Auswertung der Zugriffsstatistik auf unseren Server Beiträge in unserem Weblog bemerkt, die nicht von uns stammen. Diese Einträge enthielten Stücke von PHP-Code, die die Ausführung einer Datei auslösten, von der wir nur sagen können, dass es sich dabei nicht, wie die Datei-Endung txt vorgaukelte, um eine Text-Datei handelte…
Wie haben wir das überhaupt bemerkt? Weil wir ein etwas spezielleres Layout haben, müssen wir viele Änderungen von Hand vornehmen, während WordPress sonst die meisten Einstellungen am Layout über eine komfortable Administrationsoberfläche ermöglicht. Dafür griff ich per FTP auf die Datei-Ablage auf dem Webserver zu und entdeckte dabei unbekannte Dateien und bemerkte vor allem das Fehlen der Layout-Vorlagen. Offensichtlich hatte der Hacker den gesamten Dateiverkehr über einen anderen Server umgeleitet, wo sich die Layout-Vorlagen befanden. Bemerkt haben wir von alledem jedoch nichts.
Wer war’s? Unsere beschränkten Informatik- und Netzwerk-Kenntnisse haben uns immerhin herausfinden lassen, dass von einer seltsamen (gekaperten?) IP-Adresse irgendwo in Südafrika mit einem russischen Mozilla-Browser die entsprechenden Zugriffe (und Eingriffe) auf unseren Webserver vorgenommen wurden. Wir fantasieren uns zusammen, dass ein russischer Hacker vermutlich bei einem automatisierten Abgrasen von Weblogs, die mit WordPress laufen, bei uns ein Sicherheitsloch entdeckte und ein Standard-Paket hochlud.
Und jetzt? Wir haben eine neue Version von WordPress installiert, die Daten in die neue Installation importiert und einige Vorkehrungen getroffen, um in Zukunft keine solchen unangenehmen Überraschungen mehr zu erleben. Zur künftigen Online-Kompetenz von Historiker/innen gehört wohl vermehrt auch die Analyse von netzbasierten IT-Angriffen und das Beherrschen von Abwehrmassnahmen.
Übrigens: Sachdienliche Hinweise oder Erläuterungen sind willkommen, ebenso Links zu hilfreichen Websites wie http://blogsecurity.net/.
Auf hämische oder spöttische Kommentare verzichten wir hingegen gerne…
Gehackt (eigentlich: gecrackt) zu werden ist sehr ärgerlich. Umso schöner, dass ihr damit offen umgeht.
Als ich vor der Entscheidung stand, einen Root-Server zu mieten, hatte ich lange gezögert. Technisch ist die Wartung eines unix-basierten Servers für mich kein Problem, aber den damit verbundenen Zeitaufwand würde ich lieber für interessantere Dinge verwenden. Denn für jede extra installierte Software muss ich zum Beispiel die Security Announcements verfolgen, um schnell reagieren zu können. Schließlich hat man als Website-Betreiber eine gewisse Verantwortung, dass der eigene Server nicht zur Spam-Schleuder verkommt oder anderen kriminellen Machenschaften dient und damit die Mitmenschen »gefährdet«.
WordPress ist ein Projekt, dass sich im Security-Bereich nicht mit Ruhm bekleckert hat. Und da die installierte Basis sehr groß ist, ist es damit auch ein lohnenswertes Ziel für automatisierte Angriffe. Da bleibt einem nichts anderes übrig, als ständig hinterher zu patchen und seinen Server ständig im Auge zu behalten.
-Tim
Vermutlich seid Ihr Opfer der WordPress Cookie Authentication Vulnerability:
http://www.cl.cam.ac.uk/~sjm217/advisories/wordpress-cookie-auth.txt
die Sache ist recht unerfreulich:
III. Solution
No vendor patch is available.
No timeline for a vendor patch has been announced.
aber es werden einige Workarounds genannt (update auf aktuellste Version um bekannte SQL-Injections zu vermeiden).