Bugs, Bugs, Bugs

Die schlechte Nachricht für den sicherheitsbewussten Admin ist, dass praktisch jede HTML Rendering Engine (Webkit, Gecko, Microsoft HTML Rendering Engine und so weiter) Lücken aufweist, die sich für Exploits eignen. Wenn es die E-Mail mit Schadcode an den Scannern vorbei auf den Rechner des Opfers schafft, kann man auf diese Weise vermutlich auch Code ausführen. Genauso lassen sich gezielt Attachments herstellen, die auf eine Lücke in einem dazu passenden Anwendungsprogramm abzielen, zum Beispiel Adobe Reader, Open Office oder Microsoft Office.

Viele werden nun denken, dass so etwas nicht klappen kann, weil fast jedes Unternehmen seine E-Mails nach Schadcode scannt oder Attachments komplett filtert. Hier kommt das Organigramm eines Unternehmens aus der Google-Suche zum Tragen. Mit solchen Informationen lassen sich gezielt E-Mails anfertigen, die möglicherweise ungescannt die normalen Kontrollen passieren, weil der Scanner denkt, es handle sich um eine legitime E-Mail ( Abbildung 5 ).

Abbildung 5: Fake-Mail, um einen E-Mail-Scanner auszutricksen.

PDF-Reader

Natürlich eignen sich auch viele andere Dokumentenformate für ähnliche Angriffe, aber der PDF-Reader von Adobe hat immer wieder durch Lücken von sich reden gemacht, für die es Exploits gab. Außerdem ist es ziemlich wahrscheinlich, dass der Reader auf einem Bürorechner installiert ist, denn er ist mehr oder weniger der De-facto-Standard. Außerdem lässt sich Javascript in ein PDF-Dokument einbetten ( Abbildung 6 ), das der Reader per Default ausführt – auch wenn man den Javascript-Support ausschalten kann [11] .

Abbildung 6: Beispiel eines PDF-Dokuments mit eingebettetem Javascript.

Didier Stevens hat ein Tool namens »make-pdf-javascript.py« geschrieben, das beliebigen Javascript-Code in ein PDF einbettet [12] . Dieses Programm unternimmt keine Anstrengungen, den Code zu verschleiern, was andere, ähnliche Tools aber machen.