Dipl.-Inform. Carsten Eilers

Erst mal muss der Angreifer eine vom jeweiligen Programm zu öffnende Datei und eine vom jeweiligen Programm verwendete Bibliothek in einem Verzeichnis speichern, auf das der Benutzer zugreifen kann. Das kann im Fall der neuen Angriffe auch ein SMB- oder WebDAV-Laufwerk sein. Beim klassischen DLL Preloading wurde die Schwachstelle lokal zur Privilegieneskalation ausgenutzt, indem einem mit höheren Benutzerrechten laufenden Programm eine Datei samt präparierter Bibliothek in einem lokalen Laufwerk untergeschoben wurde. Im folgenden soll es aber nur noch um Angriffe aus der Ferne gehen.

Als Faustformel kann dann die Regel "Ist ein Programm mit einer Extension verknüpft, so dass ein Klick auf eine entsprechende Datei das Programm startet, kann darüber auch (halb)automatisch Schadcode eingeschleust werden." dienen. Dann reicht es, wenn eine HTML-Seite einen Link zu einer entsprechenden Datei enthält, den der Benutzer anklickt. Je nach Programm müssen evtl. auch mehr oder weniger viele Warnungen weggeklickt oder Hinweise bestätigt werden. Programme, in denen die Dateien manuell geöffnet werden müssen, erlauben zwar auch das Einschleusen von Code, es ist aber etwas mehr Social Engineering nötig: Der Benutzer muss dazu gebracht werden, mit dem betroffenen Programm eine Datei z.B. von einem präparierten Netzwerklaufwerk zu laden.

Ein weiterer Angriffsvektor sind Archiv-Dateien, die sowohl Datei als auch präparierte Bibliothek enthalten und z.B. per Mail oder Instant Messaging verbreitet werden können. Dabei ist zwar wieder etwas Social Engineering nötig, aber das ist ja eigentlich noch nie ein größeres Problem gewesen.

ACROS hat mögliche Angriffsvektoren mit populären Programmen untersucht und eine vollständige Analyse veröffentlicht, außerdem gibt es einige Demos. Das ganze ist natürlich eine Momentaufnahme, da die Schwachstellen in den Programmen nach und nach (hoffentlich) behoben werden. Zumindest Microsoft hat bereits angekündigt, die Schwachstellen in den eigenen Programmen beheben zu wollen, und einige andere Hersteller haben bereits Updates veröffentlicht.

Ist die Schwachstelle "wurmfähig"?

Die Schwachstellen können auch von Würmern zur Verbreitung genutzt werden. ACROS weist auf Symantecs Analyse von Stuxnet hin, der u.a. Binary Planting zur Verbreitung ausnutzt. Angesichts der Vielzahl betroffener Programme ist es durchaus möglich, dass ein Wurm auch das Binary Planting in sein Repertoire aufnimmt. Dabei täuscht die Vielzahl betroffener Programme aber eine größere Gefahr vor, als tatsächlich gegeben ist: Ein Wurm wird sich i.A. auf populäre Programme beschränken. Wer will schon ein Botnet von einem Schädling aufbauen lassen, der nur eine Handvoll von Rechner überhaupt infizieren kann? Wenn man davon aus geht, dass die Schwachstellen in den populären Programm auch am zügigsten behoben wird, sinkt die Gefahr für einen großen Wurmausbruch weiter. Ungünstig ist in dem Zusammenhang, dass der Internet Explorer in allen Versionen unter dem immer noch weit verbreiteten Windows XP keine Warnung ausgibt, bevor er einem bösartigen Link auf einer Webseite folgt.

Gegenmaßnahmen für Entwickler

Microsoft hat bereits vor einiger Zeit ausführlich erklärt, wie Bibliotheken richtig geladen werden. Gerade diese Ausführlichkeit ist aber evtl. der Auslöser des jetzigen Problems, wie F-Secure meint:

"The documentation for LoadLibrary has about 1100 words, the page describing it in more detail has 1000 words, and the [*] page that tells you how to really get it right has 900 more. That's around 3000 words, or ten times the length of this post. You just gotta love LoadLibrary!"
[*] oben verlinkte, CE

Inzwischen hat Microsoft eine weitere Anleitung veröffentlicht, die auch die Suche nach unsicheren Suchpfaden beschreibt. Wenn möglich, sollte zum Laden von Bibliotheken immer der vollständige Pfad verwendet werden.

Eine Möglichkeit, die Schwachstelle in den eigenen Programmen zu verhindern, nennt David LeBlanc: Für das Laden der Bibliotheken wird das aktuelle Arbeitsverzeichnis durch ein bekannt sicheres Verzeichnis, z.B. c:\windows\system32 ersetzt, nach dem Laden wird das vorherige Arbeitsverzeichnis wieder hergestellt. Der Vorteil dieses Ansatzes: Lädt die geladene Bibliothek ihrerseits weitere Bibliotheken nach, tut sie das mit einem sicheren aktuellen Arbeitsverzeichnis, unabhängig davon, ob sie selbst eine Schutzfunktion enthält oder nicht.

Im Fall der EXE-Dateien gibt es keine brauchbare Lösung für die Verwendung von Suchpfaden, da es keine ähnliche Funktion wie SetDllDirectory() für das Laden von EXE-Dateien gibt. Microsoft empfiehlt, beim Aufruf ausführbarer Dateien mit Funktionen wie ShellExecute() und CreateProcess() immer den vollständigen Pfad zur Datei zu verwenden.

Gegenmaßnahmen für Anwender

Für Benutzer hat Microsoft das schon in der vorherigen Folge erwähnte Tool sowie eine zusätzliche Anleitung mit FixIt-Tool bereitgestellt. Ein neuer Registry-Key, CWDIllegalInDllSearch, erlaubt es, die Suchreihenfolge zu manipulieren. Das FixIt-Tool legt den Key automatisch an und setzt ihn auf einen mittleren Wert von "2". Eine zu strenge Einstellung führt zu Problemen mit manchen Programmen. Ggf. kann für problematische Programme über einen Registry-Key eine Ausnahmeregel definiert werden. Der nötige Key für Googles Chrome sieht z.B. so aus:

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\chrome.exe

Dazu legt man einen DWORD-Wert CWDIllegalInDllSearch mit dem Wert "0" an. Alle möglichen Einstellungen werden im Security Research & Defense Blog beschrieben.

Unabhängig von Microsofts Tool und auch zusätzlich kann der Zugriff auf WebDAV-Server komplett ausgeschaltet (wenn WebDAV nicht benötigt wird) oder auf vertrauenswürdige Server beschränkt werden. Ausgehende SMB-Zugriffe sollten in der Firewall abgeblockt werden, i.A. möchte man nicht mit SMB auf das Internet zugreifen. Im Fall der unsicheren Suchpfade für EXE-Dateien sind dies auch die einzigen möglichen Gegenmaßnahmen, Microsofts Lösung ändert nur die Suchreihenfolge für das Laden von Bibliotheken.

Ist Ihr Rechner angreifbar?

ACROS hat einen "Online Binary Planting Exposure Test" bereitgestellt, mit dem Sie prüfen können, ob ihre Gegenmaßnahmen erfolgreich sind. Sicherheitshalber und prinzipiell sollte dieser Test (ebenso wie alle anderen Onlinetests auf das Vorhandensein von Schwachstellen) mit einem Testsystem ausprobiert werden. Es besteht immer die Gefahr, dass dabei Schadcode eingeschleust wird, worauf auch ACROS hinweist. Selbst wenn Sie ACROS vertrauen, besteht immer noch die Möglichkeit, dass während der unverschlüsselten Übertragung Schadcode eingefügt wird oder der Server von ACROS kompromittiert wurde. Egal wie unwahrscheinlich das ist - Sicherheit geht vor.

Zur Zeit verwendet der Test eine in der Exploit DB veröffentlichte Schwachstelle im Windows Address Book bzw. in Microsoft Windows Contacts, bei dem manuell ein URI mit dem Windows Explorer geöffnet werden muss. Wenn diese Schwachstelle behoben wird, will ACROS den Test an eine andere, offene Schwachstelle anpassen, solange eine vorhanden ist.

Soviel vorerst zum Binary Planting. Wenn es neue Entwicklungen gibt, werde ich darauf in einem weiterem Text eingehen. In der nächsten Folge geht es um den sicheren Einsatz von HTTPS und Cookies.

Carsten Eilers

Übersicht über alle Artikel zum Thema

Standpunkt: Der Suchpfad ins Unglück

"Binary Planting" - Unsichere Suchpfade führen ins Verderben

Binary Planting - Welche Angriffe sind möglich und wie verhindert man sie?

Binary Planting frei Haus und mehr