Das Wochenende habe ich damit verbracht, mich über eine relativ neue Art von Hack schlau (naja) zu machen, den "google conditional hack": Irgendwann letztes Jahr tauchten vermehrt Seiten auf, die bei einem normalen Besuch mit dem Webbrowser ganz normal aussahen, sobald sie jedoch mit einem User-Agent-String, der auf einen Suchmaschinen-Bot schliessen ließ, besucht wurden, zeigten sie auf einmal jede Menge Viagra- und anderen Medikamentenspam inklusive Links, die allerdings auf weitere Seiten innerhalb der Website verwiesen, wo dann ebenfalls Viagraspam auftauchte.

Das Perfide an diesem Hack: Man merkt zunächst nicht, dass die Seite betroffen ist, für normale Besucher sieht alles normal aus. Derweil wird die Seite aber von google und anderen Suchmaschinen indiziert, diese erhalten aber nicht die realen Inhalte der Seite, sondern den Viagraspam.

Dass man betroffen ist, merkt man erst, wenn man die eigenen Suchergebnisse auf google kontrolliert, zb mit "site:derdomainname.tld Viagra", ist die Seite betroffen, kann man die Kreativität der Spammer bewundern. Aufmerksame Webmeister bemerken vielleicht, dass weniger Traffic über google kommt als zuvor, da google betroffene Seiten mittlerweile als "Die Seite wurde möglicherweise manipuliert" in den Suchergebnissen anzeigt und somit die Wahrscheinlichkeit, dass ein Besucher diese trotzdem klickt, sinkt.

Unklar ist, wie die Hacker sich Zugang verschaffen, die Beiträge, die ich gefunden habe, gehen von PHP-Schwachstellen, unsicheren oder abgefischten FTP-Zugängen oder Sicherheitslücken in TYPO3 oder WordPress aus.

Warum hat mich das beschäftigt? - Nun, ein mir nahestehender Webserver wurde auf diese Art gehackt, und das auf einem System, welches relativ gut gepflegt und aktualisiert ist. Da ich selbst mich dort um die TYPO3-Installation und die Updates kümmere, habe ich ein großes Interesse herauszufinden, was da gemacht wurde und wie der Einstieg erfolgte.

Der Server wurde unmittelbar nach Kenntnis über den Hack komplett vom Netz genommen und zunächst nur lokal untersucht. Heute ging er wieder ans Netz, allerdings hinter einer Firewall, die nur Zugriffe des Providers und von unserer IP durchlässt. Heute waren wir den ganzen Tag damit beschäftigt, das System wieder zu restaurieren und die kompromittierten Daten zu untersuchen, um den Hack zu identifizieren.

So wie es derzeit aussieht, wurde der Server automatisiert abgescannt und auf Port 8080 antwortete ein Apache-Tomcat-Admin, der offenbar mit einem schwachen User/Passwort abgesichert war. Über diesen Adminbereich konnte der Angreifer munter irgendwelche .jar Dateien hochladen, unter anderem einen Dateimanager und einen IRC Bot, und offenbar über das gesamte System verteilt php-Dateien so verändern, dass sie als Backdoor dienen konnten. Interessanterweise ist diese Backdoor nicht offen, sondern reagiert erst, wenn man den richtigen String per Parameter übergibt. Überhaupt scheint das nicht unbedingt ein "Scriptkiddie" Hack zu sein, die Spuren waren sehr gut verwischt (zb keine Veränderung im Modifikationsdatum der betroffenen Dateien, keine Shell-Historie-Einträge…) und die injizierten Codes variieren auch genug, um das Spiel mit grep anspruchsvoll zu machen.
Das Ding, was dafür verantwortlich ist, dass die Seiten bei google und Co modifiziert auftauchen, sieht in etwa so aus, und ist zigfach durch base64, rot_13 und preg_replace verschleiert.

Aus der Erfahrung der letzten Tage kann ich jedem nur dringend empfehlen: Lasst auf dem Webserver wirklich nur die Sachen, die wirklich benötigt werden, jede Kopie einer Datei, die man mal so quasi als ad-hoc Backup macht, kann in so einem Fall einem das Leben schwer machen.

Dass man nicht benötigte Script-Dateien und Erweiterungen von zb WordPress oder TYPO3 nicht auf dem Server belässt, sondern löscht, ist auch etwas, was man zwar weiss, aber dann im Tagesgeschäft doch gerne mal unterlässt… auch das kann ziemlich eklige Konsequenzen nach sich ziehen.

Man sollte tatsächlich immer mit dem Schlimmsten rechnen - was ist zb, wenn man so einen Hack erst nach einer ganzen Weile feststellt und man davon ausgehen muss, dass mittlerweile alle Backups, die turnusmässig laufen, die kompromittierten Dateien enthalten?

Und ich kann nur eindringlichst empfehlen, die Sicherheitsupdates aller Komponenten mitzumachen - bekannte Lücken werden ausgenutzt und wenn es dann mal kracht, ist der Aufwand und die Kosten, um das System wieder in den Griff zu bekommen, deutlich höher als der Aufwand, den man ggf. mit der Anpassung an neuere und sicherere Versionen von zb PHP und den CMS-Komponenten hat.

Und das nützt alles nichts, wenn man dann an den Zugangsdaten schwächelt, und selbst vermeindlich komplexe User/Passwort-Kombinationen nützen nix, wenn man evtl User auf dem Server hat, deren lokale Rechner sich was eingefangen haben.

Das Web ist kein Ponyhof.

Mehr dazu:
http://www.stevepenny.com/googleviagraspamhack.html
http://www.itmagazine.ch/Artikel/46679/Typo3-Hack_auf_der_Spur.html
http://developer-news.com/2011/04/28/etliche-typo3-webseiten-gehackt/
http://stylish-and-co.blogspot.com/2011/05/typo3-web-site-hack.html