Hacker-Konsole »Shell.CA.2«, mit der so ziemlich alles im angegriffenen System machbar ist

••• Aus Fehlern lernt man, heißt es. Nun, es müssen nicht unbedingt die eigenen sein. Ich habe Fehler gemacht und lade euch ein, den Erkenntnisgewinn mit mir zu teilen, bevor es euch selbst trifft.

Vor einigen Wochen wurde der Server, auf dem neben dem Turmsegler noch diverse andere Websites befreundeter Künstler beheimatet sind, von islamistischen Hackern aus Malaysia angegriffen. Anlass war den muslimischen »Freunden« der Beginn des Fastenmonats Ramadan. Dass auch mir der Appetit vergangen ist, als ich morgens per SMS die Meldung bekam »Meine Website wurde gehackt!« — kann man sich denken. Noch mehr vergällt war er mir, als ich das Ergebnis sah: Antisemitische Hass-Banner auf den Homepages der betroffenen Sites.

Obwohl ich sofort einschreiten und vom Handy aus den Server vom Netz nehmen konnte, war der Schaden bereits beträchtlich. Es hat eineinhalb Tage gedauert, die Sicherheitslücke zu identifizieren und zu schließen, den Schaden zu beseitigen und das System durchgängig mit neuen Account-Passwörtern zu versehen.

Nun ist es einerseits peinlich, wenn man einräumen muss, den Hackern eine Tür offen gelassen zu haben, durch die sie eintreten konnten, um solchen Schaden anzurichten. Andererseits denke ich mir, nachdem ich nach nun mehr als vier Wochen wieder sicherem Betrieb, den Schrecken überwunden habe, dass es ein lehrreiches Beispiel für andere Site-Betreiber sein kann, wenn ich an dieser Stelle einmal erzähle, wie die Hacker eingedrungen sind, welche Tools sie verwendet haben und was alles sie damit sonst noch hätten anstellen können.

Die meisten Websites auf meinem Server verwenden das Content Management System (CMS) WordPress. Es ist auf Millionen Installationen weltweit erprobt, wird regelmäßig aktualisiert und gegen mögliche neue Angriffsvarianten gehärtet. Das schützt den Anwender jedoch nur bedingt. WordPress erfreut sich unter anderen deshalb so großer Beliebtheit, weil es durch Plugins für jeden denkbaren und undenkbaren Einsatzzweck erweitert werden kann. Ich selbst habe Plugins für WordPress geschrieben, MintPopularPostsWP und RearviewMirrorWP beispielsweise für die »Rückspiegel«-Funktion wie hier im Blog. Gelegentlich verwenden die Entwickler solcher Plugins ihrerseits Komponenten von Drittanbietern — bspw. Flash-Komponenten für die Bereitstellung von Upload-Funktionen.

Ein solches WordPress-Plugin, im Einsatz auf zwei der betreuten Websites, war das Einfallstor. Das Plugin nutzte eine vom Entwickler nicht korrekt konfigurierte Flash-Upload-Komponente. Diese ermöglichte es nicht nur — wie vorgesehen — Bilder auf den Server zu laden, sondern auch ausführbaren Skript-Code und das auch noch für beliebige unangemeldete Benutzer. Ein Konfigurationsfehler meinerseits gestattete die Ausführung von Skript-Code aus Verzeichnissen, die das Plugin für Uploads nutzte.

Die Hacker haben einen Automaten verwendet, der stumpfsinnig WordPress-Websites weltweit nach dem fehlkonfigurierten Plugin absuchte. Der Automat sandte einfach an die typische URL einen Upload-Request. Ist das Plugin vorhanden, landet so eine Hacker-Konsole (»Spy.CA.2« und »Spy.Prance.A«) als PHP-Script auf dem Server. War der System-Admin gewissenhaft, ist der Angriff damit zu Ende, denn aus einem Upload-Verzeichnis sollte der Server nie Code ausführen dürfen. Sollte. Der Automat prüft das, indem direkt im Anschluss versucht wird, die Hacker-Konsole aufzurufen. Gelingt das, ist der Server kaum noch zu retten. Ein Mensch übernimmt dann über die Konsole den Server.

In meinem Fall wurden zwei unterschiedliche Hacker-Konsolen verwendet. Die eine (s. folgendes Bild) dient zur Ausführung von beliebigen Shell-Befehlen unter dem OS-User, unter dem der Webserver läuft. (Gelegentlich, habe ich mir sagen lassen, ist das bei manchen Systemen auch mal der User root, der alles darf.) Aber auch, wenn man sich diese fatale Blöße nicht gegeben hat, ist es schlimm genug. Das »Turbopanel« unternimmt diverse Brute-Force-Attacken, um die Passwörter von OS- und Datenbank-Usern zu knacken.

»Turbopanel«, Hacker-Konsole für Passwort-Klau

Darauf allerdings ist der Hacker, der die Konsole bedient, gar nicht angewiesen. Die »Super!«-Konsole aus dem Bild am Beginn dieses Artikels bietet dem Hacker nämlich Zugriff auf das Dateisystem des Web-Servers, soweit der OS-User, unter dem der Web-Server betrieben wird, dies lesen darf. In diesem Dateisystem finden sich nun auf alle Fälle die Konfigurationsdateien von WordPress, in denen u. a. die Datenbankverbindungen des CMS eingetragen sind. So kommt der Hacker in den Besitz von validen Datenbank-Benutzernamen samt Passwort. Einmal in der Datenbank, liegen dann auch die Accountnamen aller registrierten Benutzer offen, das CMS ohnehin, so dass die Websites im Handumdrehen mit Inhalten gefüllt werden können, die dem Hacker gefallen, dem enteigneten Admin der Website hingegen höchstwahrscheinlich nicht.

Ist man derart entkleidet, hat man einiges an Arbeit vor sich. Zunächst muss man die Sicherheitslücke überhaupt erst einmal finden und sie schließen. Dann ist festzustellen, wann genau der Einbruch erfolgt ist. Reparieren kann man vergessen. Will man sicher sein, keinen Schadcode und keine fremden Inhalte auf den Sites oder in der Datenbank zu haben, muss man ein Backup von Datenbank und Dateisystem einspielen, das vor dem Angriff erstellt worden ist.

Damit ist es aber nicht getan. Immerhin muss man davon ausgehen, dass die Hacker sich nun im Besitz der Account-Informationen von Weblog-Nutzern und Datenbankbenutzern befinden. Also müssen alle Passwörter für diese Accounts geändert werden.

Die meisten CMS ermöglichen es, dass ein einmal angemeldeter Benutzer künftig über einen Cookie erkannt wird und sich so nicht bei jedem Besuch neu anmelden muss. WordPress bietet dieses Feature ebenfalls an. Nach einem Hacker-Einbruch muss es deaktiviert oder aber auf anderem Weg sichergestellt werden, dass alle bisher generierten Cookies ihre Gültigkeit verlieren. Bei WordPress ist dies möglich, indem die Kryptographieschlüssel geändert werden. Andernfalls braucht sich der Hacker während der Attacke nur einmalig gültig angemeldet zu haben, um später bei weiteren »Besuchen« über den Cookie als valide angemeldeter Blog-Benutzer erscheinen zu können. Wirklich sicher ist die Änderung der Schlüssel jedoch nur, wenn man ausschließen kann, dass Benutzer-Passwörter zu den Blog-Accounts entwendet wurden. WordPress speichert alle Passwörter verschlüsselt. So soll es auch sein. Ob diese Verschlüsselung für einen wirklich ambitionierten Hacker ein echtes Problem darstellt, mag ich nicht beurteilen.

Ins Merkheft geschrieben: Was sollte man auf jeden Fall berücksichtigen, wenn man einen Server im Internet betreibt?

1. Tägliche Backups vom Dateisystem und den Datenbanken müssen vorhanden sein.
2. Tägliche Backups vom Dateisystem und den Datenbanken müssen vorhanden sein.
3. Tägliche Backups vom Dateisystem und den Datenbanken müssen vorhanden sein.
4. Alle Komponenten vom Betriebssystem über die Server-Software bis hin zu Plugins müssen auf aktuellem Stand gehalten werden, so dass Sicherheitslücken, die den Entwicklern bekannt geworden sind und von ihnen geschlossen wurden, auch auf dem eigenen System geschlossen werden.
5. Server-Software (Web-, Mail-, Datenbank-Server etc.) müssen unter unterschiedlichen minderberechtigten OS-Usern laufen und keinesfalls unter dem User root.
6. Ermöglichen Komponenten den Upload von Inhalten auf den Server, muss verhindert werden, dass es sich dabei um ausführbaren Code handelt oder bestehende Inhalte gleichen Dateinamens überschrieben werden können.
7. Der Web-Server muss so konfiguriert werden, dass er in keinem Fall Code aus Verzeichnissen ausführt, die für Uploads freigegeben sind.
8. Es empfiehlt sich der Einsatz einer Software, die das Dateisystem des Webservers überwacht und den Admin benachrichtigt, wenn sich im Dateisystem bislang unbekannte Inhalte finden, insbesondere Dateien mit ausführbarem Code.

Punkt 4, 6, 7 und 8 waren auf meinem Server nicht erfüllt. Das besagte Plugin war seit zwei Jahren nicht aktualisiert worden. Die Sicherheitslücke (Verstoß gegen Punkt 6) war dem Hersteller des Plugins bekannt und bereits seit 1 1/2 Jahren durch eine neuere Softwareversion geschlossen. Mein Web-Server erlaubte die Ausführung von Code aus Upload-Verzeichnissen, und ein Monitoring des Dateisystems gab es nicht.

Selbst schuld also. Erkenntnis durch Schmerz.

Es würde mich interessieren, welche Blog-Betreiber unter den Turmsegler-Lesern alle 8 Punkte beruhigt abhaken können. Eine Google-Recherche am Tag des Angriffs zeigte, dass tausende WordPress-Weblogs in aller Welt an diesem Tag auf die gleiche Weise von den gleichen Hackern übernommen worden sind. Google hatte die gefälschten Inhalte bereits indiziert. Und da Hacker auf spezifische Weise eitel sind, haben sie in den Hass-Seiten Fingerabdrücke hinterlassen, um ihren weltweiten »Erfolg« auch belegen zu können.

Jetzt sind hier die Schotten dicht, nun ja, nach aktuellem Kenntnisstand. Besucher aus Malaysia müssen ab sofort übrigens draußen bleiben. Sorry, aber wenn die entsprechenden Provider auf Meldungen über Hacker-Angriffe via IP-Adressen aus ihren Pools nicht einmal reagieren, geschweige denn Maßnahmen ergreifen, dann bleibt einem nichts anderes übrig, als die Rote Karte zu ziehen.