Dipl.-Inform. Carsten Eilers

Als am Donnerstag die ersten Meldungen über die Warnung im Web auftauchten prüfte ich php.net über Virustotal. Das Ergebnis: Nur Google wollte dort etwas Schädliches entdeckt haben. Also wohl ein Fehlalarm. Gut für ein paar dumme Witze, aber ansonsten uninteressant. Auch bei php.net selbst ging man von einem False Positive aus und versuchte, die Falschmeldung durch Google korrigieren zu lassen.

Angeblich hatte Google Schadcode in der Datei http://static.php.net/www.php.net/userprefs.js gefunden, die aber bei der Prüfung durch die php.net-Administratoren keinen fremden Code enthielt. Gleichzeitig gab es aber Meldungen über verdächtigen getarnten Code darin.

Zeitweilige Manipulationen

Des Rätsels Lösung war eine (zumindest für mich) neue Taktik der Cyberkriminellen zum Verbergen ihrer Manipulationen: Über einen rsync-cron-Job wurde die Datei zeitweise gegen eine präparierte Version ausgetauscht, so dass mal die kompromittierte und mal die harmlose Version ausgeliefert wurde. Während Googles Crawler irgend wann eine manipulierte Seite präsentiert worden war, erwischten die php.net-Administratoren bei ihrer Prüfung eine saubere Version. Und das war dann natürlich ein deutlicher Hinweis auf einen False Positive.

Normalerweise haben die Cyberkriminellen ihren Code, wenn überhaupt, über eine "Referer-Weiche" getarnt: Besuchern, die von einer Suchmaschinen kamen, wurde der Schadcode untergeschoben, alle anderen bekamen die sauberen Seiten zu sehen. Dadurch sollte verhindert werden, dass regelmäßige Besucher und die Betreiber der Website, die sie aus ihren Bookmarks aufrufen, eine Manipulation bemerken. Den Schadcode immer nur zeitweise auszuliefern ist zumindest für mich neu. Besonders nützlich scheint die Taktik auch nicht zu sein, denn zumindest der Google Crawler bekam den Schadcode ja zu sehen.

Ein paar weitere Details

Die php.net-Administratoren haben schnell und korrekt reagiert und inzwischen einige weitere Informationen geliefert: Zwei Server wurden kompromittiert, und zwar der Host für www.php.net, static.php.net und git.php.net sowie der Host für bugs.php.net. Wie die Kompromittierung statt gefunden hat, ist bisher unbekannt (oder wurde zumindest noch nicht veröffentlicht). Die Server wurden ausgetauscht, und da die Angreifer evtl. Zugriff auf die privaten Schlüssel der SSL-Zertifikate hatten wurden diese zurückgezogen und durch neue ersetzt. Auch die Passwörter der php.net-Benutzer sollen zurückgesetzt werden.
Der Code für die Drive-by-Infektion wurde vom 22. bis 24. Oktober 2013 an eine unbekannte Anzahl Besucher der Website (laut php.net "a small percentage") ausgeliefert. Die Sourcecode-Tarballs und das Git-Repository von PHP wurden nicht manipuliert.

Weitere Informationen werden bei Bedarf über Twitter verbreitet: @official_php.

Was wurde installiert?

Die Barracuda Labs haben generell das Vorhandensein von Schadsoftware bestätigt und eine PCAP-Datei des Angriffs veröffentlicht.

Laut Fabio Assolini vom Kaspersky Lab führt der eingeschleuste Code zum Magnitude Exploit Kit, von dem der Trojaner "Tepfer" installiert wurde.

Von den Trustwave SpiderLabs gibt es eine Analyse, laut der ein SWF-Exploit, also Code zum Ausnutzen einer Schwachstelle im Flash Player, zum Einsatz kam. Außerdem wurden eine PE-Datei mit Shellcode und ein Exploit für eine Schwachstelle im Internet Explorer (CVE-2013-2551) verwendet.

Dem Bericht der Websense Security Labs zu Folge wurde der Schadcode nur einmal pro System ausgeliefert, und auch das nur, wenn Referer und UA-String den erwarteten Werten entsprachen. Das verwendete Magnitude Exploit Kit enthält Exploits für Adobe- und Java-Plattformen (womit wohl eher Anwendungen gemeint sind) und installiert demnach herkömmliche Ransomware.

Da Trojaner und Ransomware komplett unterschiedliche Schadsoftware-Klassen sind ist es möglich, dass verschiedene Arten von Schadsoftware verbreitet werden. Es gibt auch Spekulationen, dass es sich um einen Wasserloch-Angriff handelt und darüber gezielt PHP-Entwicklern Schadcode untergeschoben werden soll. Dann könnte es sich um regional beschränkte Angriffe handeln: Besuchern aus bestimmten Regionen wird ein Trojaner unter geschoben, anderen "nur" Ransomware.

Der PHP-Code ist sicher?

Eine erste Prüfung der MD5-Checksummen hat ergeben, dass es keine Hinweise auf eine Kompromittierung des PHP-Codes gibt. Das wird stimmen, zumal eine hoffentlich gründlichere Prüfung dieses Ergebnis bestätigt hat. Hashwerte wie MD5 sind aber zum Erkennen von Manipulationen ungeeignet, falls der Angreifer auch den Hashwert manipulieren kann, zum Beispiel weil Datei und Hashwert auf dem gleichen Server gespeichert sind. Denn dann kann er einfach den vorhandenen Hashwert durch den der manipulierten Datei austauschen. Vor solchen Angriffen schützen nur digitale Signaturen, bei denen nicht nur die Integrität der Datei sondern auch der Urheber der Signatur geprüft werden können.

Carsten Eilers