Es ist schon abgefahren. Da betreue ich gerade mal seit einem halben Jahr eine TYPO3-Installation. Nun hat mich der Pharma Hack bereits ein zweites mal heimgesucht. Bisher konnte ich den schadhaften Code zwar immer erfolgreich aufspüren, aber ich muss mir mal überlegen, was ich in Zukunft machen kann um das zu verhindern. Aber noch habe ich gar keinen Plan, wie der Code da überhaupt reinkam.
Was ist der “Pharma Hack”?
Kurz gefasst ist der Pharma Hack ein Stück Schadsoftware, dass auf den Webserver gespielt wird. Dort werden dann Code-Snippets eingeschleust, die Links zu Pharma-Seiten ausspielen, auf denen diese Potenzpillchen verscherbelt werden. Wenn man ein wenig googelt findet man schnell heraus, dass der Pharma-Hack nicht nur TYPO3, sondern auch WordPress, Joomla! und andere CMS befällt. In beiden Fällen waren bei mir unterschiedliche Varianten eingeschleust:
Die eine Variante hat den Quellcode nur für Suchmaschinen-Bots manipuliert. Das war übel, denn hier hatte ich, als ich mit dem Browser die Seite aufrief, gar keinen Anhaltspunkt was denn los sein könnte. In den Suchmaschinen wurde aber in den Ergebnissen statt der normalen Meta-Beschreibung Links und Text zu diesen ominösen Pillendrehern eingespielt. Da halfen mir die Google Webmaster-Tools, mit denen ich die Seite “wie durch den Google-Bot” aufrufen konnte.
Im zweiten Fall hat der Code direkt den Fliesstext auf der Seite manipuliert. Aber nicht immer, sondern scheinbar nur zufällig. Er hatte Textteile, also einzelne Wortgruppen, mit Text und Links zu den Potenz-Webseiten ersetzt.
Wie habe ich den Hack aufgespürt?
Das aufspüren des Codes war bei ersten mal noch recht aufwändig. Ich habe ein wenig rumgegoogelt und dann ein paar Anhaltspuntke gefunden. Im Grunde lief es aber in beiden Fällen gleich: in der /typo3conf/localconf.php
wurde eine Datei mit dem PHP-Befehl require_once()
aufgerufen, die da nicht hingehörte. In beiden Fällen war es so, dass die Datei mit den Schadcode in einem Unterordner einer TYPO3-Extension lag und so auf den ersten Blick unscheinbar war und für einen Laien nicht direkt erkennbar ist.
Bei mir hieß die geladene Datei in beiden Fällen ext_fpdf.php
. Die Datei hatte als letztes Bearbeitungsdatum das Datum der anderen Dateien in diesem Ordner – daher war sie über diesen Weg nicht zu erkennen. Auch das Änderungsdatum der localconf.php
gab keinen direkten Hinweis, dass diese Datei kürzlich verändert wurde.
Wenn ich mir den Rest der localconf.php
aber anschaue, stehen hier sonst keine weiteren require_once()
-Aufrufe drin. Deshalb solltest du hier skeptisch sein, wenn dort so etwas auftaucht.
Im zweiten Schritt habe ich mir dann die jeweilige Datei angeschaut, die dort geladen wurde. Und wenn die so anfängt:
Error_Reporting(0); $xDFTZagjwNgi="lRhrU9s48K/H9Z0tJjWCAIU+CDPMwO+w445DFMcfAkPT2DoHchOKy+V8lA9tTI7bleRHEsJwtGBrX1rtWz4+STi3eTpnsc1Dzzkzj4zd4xOvQ816+pjMfyXzB3KTZU/pDFbp9FtylZH7RsOaXmWTp8n3ZP44mVoGvTg+6XrMtHY6thNS33Zt3iBnnDGHb ... ; preg_replace(...); return; |
dann ist etwas gewaltig faul. Denn hier wird die Fehlerausgabe in PHP deaktiviert, eine Variable definiert und diese in einer nächsten Funktion “entschlüsselt”. Beim ersten mal habe ich mir noch die Mühe gemacht, die Variable, die in Wahrheit eine Funktion ist, über mehrere Stufen zu entschlüsseln. Sie ist teilweise über preg_replace(),
(Suchen und Ersetzen von Strings), aber auch teilweise mit base64-En- bzw. De-Coding verschlüsselt.
Aus Sicherheitsgründen habe ich hier natürlich nicht den vollständigen Code der schadhaften PHP-Datei eingefügt.
Wie habe ich den Code entfernt?
Zuerst habe ich ganz einfach den require_one()
-Befehl aus der localconf.php
entfernt. Somit wird die PHP-Datei mit dem Schadcode erst mal nicht geladen. Die ext_fpdf.php
-Datei habe ich dannach vom Server gelöscht, aber mir eine Kopie lokal auf den Rechner gespeichert – man weiss ja nie, ob man die noch einmal für einen Blog-Beitrag oder so gebrauchen will ;-)
Was kann man gegen zukünftige Angriffe tun?
Ich habe beim ersten Angriff die Dateiberechtigungen geändert. Ich weiß nicht, wie weit der Kenntnisstand meines Vorgängers war, aber sämtliche Ordner und Dateien in der TYPO3-Installation hatten die Berechtigungsstufe 777. Da bedeutet, jeder darf Dateien lesen, ausführen und schreiben. Und das ist eigentlich ein No-Go. Also änderte ich die Dateiberechtigungen auf 755 was bedeutet, dass nur der Besitzer Dateien erzeugen / (über-) schreiben darf, jeder aber Dateien lesen und ausführen kann. Das hat scheinbar nicht geholfen.
Daher werde ich jetzt das Admin-Passwort für den FTP-Server ändern in der Hoffnung, dass dann niemand mehr ran kommt. Es ist mir eh ein Dorn im Auge und sicherheitstechnisch auch ein kleiner Super-GAU, dass das SQL-Datenbak- und FTP-Admin-Passwort identisch sind.
Bist oder warst du auch schon vom Pharma-Hack betroffen? Wie hast du den Code ausfindig gemacht und entfernt? Hast du eine Möglichkeit gefunden, das erfolgreich zu unterbinden? Erzähl es mir!