Dipl.-Inform. Carsten Eilers

Wenn man die im Dezember entdeckte, aber erst im Januar wirklich bekannt gewordene 0-Day-Schwachstelle im Internet Explorer mitzählt gibt es dieses Jahr bereits 7 0-Day-Schwachstellen:

Die Adobe-Reader-Schwachstellen im Überblick

12. Februar: Adobe untersucht einen Angriff

Den ersten Bericht über die neuen 0-Day-Schwachstellen gab es am 12. Februar: Adobe gab in einer knappen Meldung im Blog des Adobe Product Security Incident Response Team bekannt, dass man einen Bericht über einen 0-Day-Exploit für Adobe Reader und Acrobat XI untersucht, der "in the wild" gefunden wurde.

Auslöser wahr eine Meldung des Sicherheitsunternehmens FireEye, dass "in the wild" eine PDF-Datei entdeckt hat, über die eine 0-Day-Schwachstelle im Adobe Reader 9.5.3, 10.1.5 und 11.0.1 ausgenutzt wird. Weitere Details über die Schwachstelle will FireEye erst später veröffentlichen.

13. Februar: Adobe veröffentlicht ein Security Advisory

Am 13. Februar hatte Adobe den Exploit so weit untersucht, dass man ein Security Advisory für Adobe Reader und Acrobat veröffentlichen konnte. Es gibt zwei Schwachstellen (CVE-2013-0640 und CVE-2013-0641) und beide erlauben das Ausführen beliebigen Codes.

Laut ThreatPost gelingt dem gefundenen Exploit der Ausbruch aus der mit dem Adobe Reader X eingeführten Sandbox. Angeblich zum ersten Mal, aber da wäre ich mir nicht so sicher. Nur zur Erinnerung: Berichte über einen Exploit, der aus der Sandbox des Adobe Readers X ausbricht, gab es bereits im November 2012. Den Vorfall untersucht Adobe seitdem, bisher ohne irgend ein veröffentlichtes Ergebnis. Weder wurde die Existenz einer Schwachstelle bestätigt noch dementiert. Das wird wohl eine Geschichte mit einem märchenhaften Ende: "Und wenn sie nicht gestorben sind, untersuchen sie die Schwachstelle noch heute".

FireEye hat sich entschlossen, doch einige Details zu veröffentlichen, aber nicht zu den Schwachstellen selbst, sondern zum Exploit allgemein. So werden die Versionsnummern des Adobe Reader genannt, für die Shellcode angepasst werden kann, es gibt Hinweise wie der Exploit ASLR und DEP umgeht und was er danach anstellt: Eine Backdoor installieren. Wer hätte das gedacht?

Übrigens fehlen im Exploit diesmal die fast schon obligatorischen Hinweise auf die "üblichen Verdächtigen": Statt chinesischer gibt es diesmal italienische Spuren, und zwar in Form von Variablennamen im JavaScript-Code.

14. Februar: Adobe nennt einen Workaround

Am 14. Februar hat Adobe das Security Advisory aktualisiert und einen Workaround vorgeschlagen: Benutzer von Adobe Reader XI und Acrobat XI für Windows können den Protected View aktivieren, alle anderen haben Pech gehabt.
Adobe empfiehlt zwar, den Protected View nur für "Files from potentially unsafe locations" zu aktivieren, ich würde dann aber auf Nummer Sicher gehen und ihn für alle Dateien einschalten.

Denken Sie auch daran, dass es keine Garantie dafür gibt, dass die Cyberkriminellen nicht auch einen Weg finden, um die Einschränkungen des Protected View zu umgehen und ihren Schadcode trotzdem auszuführen. Mal abgesehen davon, dass Protected View nur ein zweifelhafter Schutz ist: Damit wird zwar ein Read-Only-Modus aktiviert, entscheidet sich ein Benutzer aber, die Ausführung enthaltenen Codes zu zu lassen, ist der Schutz dahin. Mit Social Engineering dafür zu sorgen, dass ein Benutzer Schutzmaßnahmen ausschaltet, ist für die Cyberkriminellen inzwischen eine der leichtesten Übungen.

Mein Vorschlag für einen Workaround funktioniert für alle Systeme und ganz unabhängig von der Version des Adobe Readers: Löschen Sie den Adobe Reader, und sie sind alle Probleme damit auf einen Schlag los. Es gibt ja genug Alternativen, die zwar auch alle von Zeit zu Zeit Schwachstellen enthalten, dafür aber viel weniger im Fokus der Cyberkriminellen stehen. Solange die sich auf Java-Plugin, Adobe Reader und Flash Player konzentrieren, sind sie mit einem anderen PDF-Reader deutlich weniger Angriffen ausgesetzt. Und selbst wenn sich die Cyberkriminellen irgendwann auch auf andere PDF-Reader konzentrieren, dürften die deutlich sicherer sein, da sie weniger Funktionen und damit mit ziemlicher Sicherheit auch weniger Schwachstellen enthalten als die digitalisierte eierlegende Wollmilchsau Adobe Reader.

Ebenfalls am 14. Februar hat Symantec die Entdeckungen von FireEye bestätigt. Und Sophos hat berichtet, dass die PDF-Datei mit dem Exploit nach dessen Ausführung eine harmlose PDF-Datei lädt, um den Angriff zu verschleiern.

Laut @msftsecresponse, Microsofts Security Response Team, schützt auch das Enhanced Mitigation Experience Toolkit (EMET) 3.5 Tech Preview vor einer Ausnutzung der Schwachstellen durch den Exploit. Leider wurde diese Version noch nicht offiziell veröffentlicht, und die aktuelle Version 3.0 schützt nicht vor der Ausnutzung von CVE-2013-0640. Die Frage ist, ob man sich vorerst mit einem nur zur Hälfte unbrauchbar gemachten Exploit zufrieden geben will oder nicht. Die Installation eines anderen PDF-Readers ist meines Erachtens einfacher und sicherer.

15. Februar: Eine weitere Analyse

Am 15. Februar gab es nichts Neues von Adobe, dafür hat McAfee eine Analyse des Exploits veröffentlicht. Dabei werden die Schwachstellen auch näher eingegrenzt:

1. Im ersten Schritt werden in AcroForm.api einige Informationen ausgespäht, um mit Hilfe von Return-Oriented Programming (ROP) alle benötigten Befehle zusammen zu stellen. Der Exploit verwendet nämlich keinen herkömmlichen Shellcode, sondern missbraucht nur vorhandenen Code. Schutzprogramme, die nach Shellcode suchen, scheitern in diesem Fall: Alles, was sie finden, sind einige Adressen in einem legitimen Modul. Über ROP wird eine im Exploit enthaltene DLL entschlüsselt, installiert und geladen. Diese erste DLL installiert weitere DLLs und bereitet den Ausbruch aus der Sandbox vor.
2. Im zweiten Schritt wird dann Schadcode in den Broker-Process eingeschleust, womit der Ausbruch aus der Sandbox auch schon gelungen ist, da der Broker mit höheren Rechten läuft.

Auch für McAfee ist dies der erste erfolgreiche Ausbruch aus der Adobe-Reader-Sandbox, aber da wäre ich mir wie schon erwähnt nicht so sicher.

McAfee empfiehlt übrigens als Workaround außer dem Einschalten des Protected View auch das Ausschalten von JavaScript.

16. Februar: Adobe kündigt ein Update an

Am 16. Februar hat Adobe angekündigt, dass Updates für alle betroffenen Adobe Reader und Acrobat Versionen in der laufenden Woche ab dem 18. Februar erscheinen sollen. Da bin ich ja mal gespannt, ob das was wird. Es wäre ja nicht das erste Mal, dass ein Notfallpatch eine neue Lücke aufreißt oder die vorhandene nicht richtig schließt. Vor allem Oracle hat ja schon des öfteren gezeigt, wie man es nicht macht.

Carsten Eilers