So ungern man darüber spricht, dass eigene Typo3-Installation gehackt/missbraucht wurden, so gerne möchte ich anderen Leuten helfen, die sich mit demselben Problem beschäftigen.
Was ist geschehen?
Kurz vor dem Osterwochenende (kaum ein Zufall) wurden wir darauf aufmerksam gemacht, dass eine Website von uns (auf Basis von Typo 3, Version 4.1.x) mit „Viagra-Spam» in der Google Trefferliste erscheint. Also in etwa so (Anfrage an Google „site:*DOMÄNE* viagra»).
Bei Klick auf einem der Treffer wird der Besucher über die auf der Trefferliste genannte Site mit einem serverseitigen Redirect (http 302, found) auf die Domäne http://https-checker.com/ (bei Amazon AWS gehostet) umgeleitet und von dort aus auf eine «Online-Pharmacy» in den USA oder in Kanada.
Auf Anfrage gebe ich gerne Auskunft über alle technische Details, doch hier nur das Wichtigste. Die ganze Sache wurde (aber der IP 178.122.14.205) sehr professionell ausgeführt und in unserem Fall bereits zwischen dem 20. und dem 23. Februar eigebaut. Die zwei genannten Probleme i) Ergänzung des Seiteninhaltes mit „Viagra» und co…
…und ii) Redirection auf die Kauf-Site griff nur, wenn entweder der Referrer oder der User Agent (Crawler) google beinhaltete. Zudem gab es noch eine kleine Zufallskomponente, so dass das unerwünschte Verhalten nicht immer greift.
Was tun?
Hier eine Anleitung was wir getan haben um das System (nun seit über einer Woche ohne Probleme stabil) wieder in Betrieb zu nehmen.
1) Site abstellen (resp. den User auf eine statische Information schicken). Dies haben wir getan als wir merkten, dass der Angreifer während der Reparatur Katz und Maus mit uns spielte. Anmerkung: Eine erwogene Alternative war es dem Apache über mod_header und der Direktive «header unset Location» die Redirection abzustellen, doch war uns die Präzenz des Hackers zu unangenehm.
2) Für unsere Arbeit änderten wir die Domäne vorübergehend (mit einem lokalen Hosts-Eintrag)
3) www.xxx.ch/typo3 über IP restriction und mit einem Passwort (simple authentication) sperren. Der „erste» Einstieg des Hackers erfolgte in unserem Fall hier.
4) Hier wollten wir eigentlich den Restore zurückspielen, aber da die Veränderung lange zurück lag und wir nicht soviel Content verlieren wollten, beschlossen wir das System zurück zu bauen.
5a) Die Veränderungen waren über Dutzende von Typo3-Dateien verteilt. Vereinfacht hatte es uns die Suche nach der Funktion preg_replace die genutzt wurde um die Änderungen zu verschleiern (und die sonst kaum/nicht genutzt wird). Beispiel für eine der Veränderungen ist das folgende Codefragment
Update 5b) Im Fall einer weiteren Site in der wir Schadcode entfernt haben, wurde zur Verschleierung des Klartextes (Obfuscation) die Funktion str_rot13 genutzt. Konkret stand in localconf.php der folgende Zeilenbeginn:$a4d752de1a1e8d=str_rot13(‹tmhapbzcerff›);$a4d752de1a2…
6) Die obengenannten Fragmente haben wir vollständig entfernt. Zudem haben wir alle Extentions die nicht wirklich benötigt werden gelöscht.
7) Danach haben wir alle User deaktiviert/gelöscht, einen neuen Admin angelegt und die kritischen Dateien/Verzeichnisse akribisch geprüft (und zurückgebaut): typo3conf/, localconf.php, index.php, .htaccess und /typo3/sysext/cms/tslib/index_ts.php. Nun zeigten unsere Tests ein normales Verhalten der Site.
8) Und schlussendlich haben wir unsere T3-Security Checkliste vorgenommen und das Ding sehr restriktiv (re)konfiguriert: Installation von Extentions verbieten, keine Schreibrechte von T3 auf das Dateisystem (ausser das allernötigste) und Install-Tool entfernen.
Ich hoffe die Infos sind nützlich und wie gesagt bin ich für Fragen hier oder direkt gerne zu haben.
Update (4. Mai): Hier noch einen Post von Peter Kraume zu demselben Thema: Die eigene Webseite als Spam Schleuder: der Google Conditional Hack
Update (15. Juni): Just Pfingsten wurden wieder zahlreiche Sites «umgebaut». Diesmal (in den mir bekannten Fällen) über Veränderungen der DB (über SQL-Injection). Dasselbe Ergebnis, aber ein anderer Angriffsvektor.
Update (30. Januar 2012): In der Zwischenzeit hatten wir über zwanzig betroffene Sites zwischen den Fingern. Noël hat unseren aktuellen Wissensstand in einem weiterenPost zusammengefasst: A Study in … Viagra
Hi,
interessanter ist, dass viele Angriffe via der Extension phpMyAdmin abliefen. War diese bei eurem Kunden installiert?
Bei uns ist der Zugriff schon lange eingeschraenkt auf diese und andere BE Ext.
Gruesse
Die Extension «phpMyAdmin» war nicht installiert, wurde von Angreifer aber installiert als er mal drin war.
wiedermal typisch namics. wird angegriffen (wohl nicht als einzige), gibt es zu (vermutlich als einzige firma dieser grösse) und publiziert/teilt die lösung. das muss euch erstmal jemand nachmachen, mit dieser strategie seid ihr allen andern weit voraus. bravo.
Wow, Respekt vor dieser transparenten Kommunikation. Zu einem «Lehrblätz» stehen und daraus lernen bringt einem selbst und im Idealfall die Informierten weiter.
Wie schnell und einfach war es die unerwünschten Google-Treffer wieder entfernen zu lassen?
@dario. Die Google-Treffer sind noch immer da, aber nach einer Woche schon massiv (ca. 80%) reduziert. Zudem ist Viagra (und Co) kaum mehr in den Trefferzitaten sichtbar. Wir haben mit uns gerungen ein Delisting zu erwirken, wählten dann aber den Weg mit «gutem Content» zu überschreiben. Diesen Weg würde ich weiterhin empfehlen. Duplizierte Seiten sind schwierig im Index zu löschen, doch ein funktionierender 404 tut seinen Job über Zeit: https://stuker.com/2006/03/wie-verschwinde.html . Zudem wird einkommender Traffic ohne vorhandene Zielseite auf die Homepage umgeleitet wird.
Hallo Namics
Wir kämpfen seit einiger Zeit mit dem gleichen Problem und sind zu den gleichen Massnahmen gekommen.
Im Moment schreibt der Angreifer noch in die typo3conf/temp_*-Dateien, sprich wir konnten die ursprüngliche Ursache anscheinend noch nicht beseitigen. Welche Extensions waren bei Euch schlussendlich die Schwachstellen?
Gruss
Markus
Hallo Markus. Ich rufe lieber an, als dass wir hier Kommentar Pingpong machen. In den mir bekannten Fällen waren es «hausgemachte» Extensions. Suche im Access-Log mal nach SQL-Fragmenten wie SELECT oder UNION…
Zu 5a) und 5b) werden wir in einer der nächsten t3manager Versionen eine Lösung anbieten um über solche Änderungen im 24/7 E-Mail Report informiert zu werden.
Es sollte noch vermerkt werden, dass TYPO3 in der Version 4.1 schon seit 2008 nicht mehr offiziell supportet wird, d.h, es werden keine Security Patches etc. für diese veraltete Version zur Verfügung gestellt.
Aktuelle, supportete Versionen mit aktuellen Patches einzusetzen ist neben einem vernünftigen Passwordmanagement immer noch der beste Schutz gegen Angreifer
Hey Jürg,
spannend ist das die Angriffe sehr unterschiedlich aufgebaut sind, aber offensichtlich ähnlich gelagert waren.
Bei uns war ebenfalls eine Seite betroffen (wie lange der Angriff zurückliegt ließ sich leider nicht rekonstruieren, entdeckt und dem Security Team mitgeteilt haben wir es bereits Mitte April) aber dort wurden alle Änderungen in einer include.php ausgeführt und per base64_decode verschlüsselt. Diese wurde dann sehr simpel in der index.php included. Ergebnis (Links bei passendem useragent im oberen Bereich) war das gleiche.
Aja, mal wieder «Hut ab» für eure Informationspolitik und Danke für den Artikel!
Grüße aus Hamburg
Felix
ps: Wärst du bereit mir einige Hintergrund Infos zukommen zu lassen wie es zu dem Hack kommen konnte? Ich würde mich da gerne etwas zu austauschen!
Hallo Felix. Gerne full disclosure, wollte nur keine Nachmachanleitung auf den Blog stellen. Melde Dich direkt bei mir…
Sehr geehrter Herr Stuker, vielen Dank für die wertvollen Informationen, die ich durch diesen Blogeintrag und dessen Kommentaren und durch Sie persönlich bekommen konnte. Mit freundlichem Gruß, Udo Kunze
Hi,
wie hoch dürfte der Aufwand sein, eine Webseite von dem Schadcode zu befreien, also eine angegriffene Site wieder funktionstüchtig zu machen?
Merci Josef
@Joseph.
Je nachdem wir stark die Site umgebaut wurde und wie gut/schlecht die Ausgangslage (Version, Plugin etc.) ist. Hier noch ein zweiter Post mit mehr Details.
Ca. 2-4 Tage einer erfahrenen Person kann aber locker auch mehr sein wenn PlugIns und Content angepasst werden muss.