DLL Hijacking

aus Wikipedia, der freien Enzyklopädie
Wechseln zu: Navigation, Suche

DLL Hijacking (auch Binary Planting oder Remote Binary Planting) bezeichnet das Laden einer DLL aus den vom Betriebssystem angegebenen Pfaden, sofern in dem lokalen Verzeichnis des Programms diese nicht zu finden ist. Eine DLL wird unter Windows standardmäßig als erstes in dem Ordner gesucht, in welchem das Programm zu finden ist, sofern keine vollständige Pfadangabe zu der DLL gegeben ist. Viele sehen dieses Verhalten als eine Sicherheitslücke, die bei vielen Programmen unter Microsoft Windows zu finden sei, da einer Applikation so Schadcode durch eine präparierte DLL-Datei untergeschoben werden kann, sofern die Programmierung es zulässt. Das Laden einer DLL ohne vollständige Pfadangabe kann aber auch einen sinnvollen Hintergrund haben. So kann eine sogenannte Proxy-DLL, eine DLL, welche die gleichen Möglichkeiten bietet, wie die DLL, welche geladen werden soll, dazu dienen, eine Applikation sicherer zu machen, indem sie die Parameter einer Funktion darauf überprüft, ob diese zu keinem Programmabsturz führen, wie es bei einer unsicheren systemeigenen DLL sein könnte. Außerdem erlaubt dieses Systemverhalten einem Entwickler eine DLL-Datei mit beliebigen Namen zu laden, ohne sich darum Sorgen zu machen, dass eventuell eine DLL mit dem Namen im Betriebssystem-Ordner vorhanden ist und diese unbekannte DLL geladen wird, anstatt der DLL, die vom Entwickler mitgeliefert wird.

Funktionsweise[Bearbeiten]

DLLs werden in Windows über die WinAPI-Funktion LoadLibrary*[1] geladen. DLL Hijacking kann auftreten, wenn eine Anwendung keinen vollständig qualifizierten Pfad zum Laden einer externen DLL verwendet. In diesem Fall wird die zu ladende Datei anhand der von Dynamic-Link Library Search Order[2] spezifizierten Suchreihenfolge geladen: Dabei wird die Datei standardmäßig zuerst im Programmverzeichnis, dann in Systemverzeichnissen, dann im Arbeitsverzeichnis und zuletzt in den von der Umgebungsvariable PATH angegebenen Verzeichnissen gesucht. Eine „lokale“ DLL-Datei wird geladen und deren Code ausgeführt, falls diese DLL im Verzeichnis einer zu öffnenden Datendatei liegt und wenn die folgenden Bedingungen erfüllt sind: Die Anwendung (EXE-Datei) versucht, die Erweiterung (DLL-Datei) über die PATH-Variable zu laden und wechselt beim Öffnen vom Arbeitsverzeichnis in das Verzeichnis der Datendatei.[3]

Dieses Prinzip ist vergleichbar mit dem Verhalten der Kommando Console unter Windows. Gibt man dort den Befehl cmd.exe ein wird die Datei cmd.exe zu erst in dem ausgewählten Pfad gesucht, wenn das System dort nicht fündig wurde werden in den Pfaden der Umgebungsvariable nach der Datei gesucht.

Wie am 8. September 2010 bekannt wurde,[4] sind neben der beschriebenen API-Funktion weitere Funktionen von diesem, nur auf der englischen MSDN-Webseite, offiziell dokumentierten Verhalten[1] betroffen. Es handelt sich dabei um die Funktionen CreateProcess*, ShellExecute*, WinExec, LoadModule, _spawn*p* und _exec*p*,[4] die EXE-Dateien ausführen bzw. Prozesse starten. Die Funktionsweise entspricht der oben genannten, wobei sich die einzelnen Suchreihenfolgen unterscheiden.

Am 24. November 2013 veröffentlichte Stefan Kanthak, dass beim Aufruf von Batch-Skripts über CreateProcess* resp. ShellExecute* ein im Arbeitsverzeichnis stehendes Programm cmd.exe ausgeführt wird. [5]

Diese seit mindestens Windows NT 4.0 existierende Lücke hat Microsoft erst am 8. April 2014 mit dem Sicherheitsupdate MS14-019 geschlossen.[6]

Zeitlicher Ablauf[Bearbeiten]

Binary Planting wurde im Jahr 2000 erstmals beschrieben.[7] Am 18. August 2010 wurde dieses Problem in iTunes von ACROS entdeckt und publiziert.[8] Es kam zu einer medialen Verbreitung der Sicherheitslücke. Microsoft hat am 23. August 2010 eine Sicherheitsempfehlung zu diesem Problem herausgegeben.[9] Das Nachladen von DLLs aus dem Arbeitsverzeichnis gehört zum Design des Betriebssystems.[10] Zum sicheren Laden von externen Bibliotheken hat Microsoft eine Empfehlung verfasst.[11]

Verbreitung[Bearbeiten]

Erste Schätzungen gingen von etwa 200 betroffenen Programmen aus.[12] Innerhalb weniger Tage stieg die Anzahl an gefundenen Sicherheitslücken so stark an, dass die Exploit-Datenbank exploit-db.com keinen eigenen Eintrag für jeden Exploit mehr erstellt, sondern diese gesammelt in einer Liste[13] zusammenfasst. Eine inoffizielle Liste wird von Corelan Team geführt.[14] Unter den betroffenen Programmen sind Firefox, Opera, Microsoft PowerPoint, µTorrent und VLC zu finden.[14]

Gegenmaßnahmen[Bearbeiten]

Eine vollständige Lösung des Problems kann nur durch die Entwickler der Anwendungen in Form von Sicherheitsupdates geliefert werden.[10] Als vorübergehende Lösung kann aus dem Microsoft Download Center ein Update installiert werden, welches einen neuen Registrierungseintrag im Betriebssystem auswertbar macht. Mit den anschließend einzufügenden Einträgen kann im gesamten System aber auch individuell für einzelne Anwendungen die Freiheiten, DLL aus dem Arbeitsverzeichnis zu laden, beschränkt oder unterbunden werden,[15] welcher aber zu Problemen bei Programmen führt, die sich auf dem Funktionsprinzip von LoadLibrary und anderen betroffenen Funktionen korrekt stützen.[16] Daneben empfiehlt Microsoft den Webclient-Dienst abzuschalten und die TCP-Ports 139 und 445 in der Firewall zu blockieren.[9] Dies verhindert den Zugriff auf Netzwerkfreigaben und WebDAV-Verzeichnisse.

Einzelnachweise[Bearbeiten]

  1. a b Microsoft: LoadLibrary Function (Windows). 23. September 2010, abgerufen am 29. September 2010.
  2. Microsoft: Dynamic-Link Library Search Order. 23. September 2010, abgerufen am 29. August 2010.
  3. Christoph H. Hochstätter: Remote Binary Planting: Die unpatchbare Lücke in Windows. 27. August 2010, abgerufen am 18. September 2010.
  4. a b ACROS: ACROS Security Blog: Binary Planting Goes "EXE". 8. September 2010, abgerufen am 29. September 2010.
  5. Stefan Kanthak: Defense in depth -- the Microsoft way (part 14): incomplete, misleading and dangerous documentation. 13. November 2013, abgerufen am 27. September 2014.
  6. Microsoft Security Bulletin MS14-019 – Kritisch. 8. April 2014, abgerufen am 27. September 2014.
  7. Georgi Guninski: Microsoft Windows DLL Search Path Weakness. 18. September 2000, abgerufen am 18. September 2010.
  8. ACROS: ACROS Security Problem Report #2010-08-18-1. 18. August 2010, abgerufen am 18. September 2010.
  9. a b Nicht sicheres Laden einer Bibliothek kann Remotecodeausführung ermöglichen (2269637). 23. August 2010, abgerufen am 29. August 2010.
  10. a b Binary Planting: Windows-Sicherheitslücke betrifft dutzende Anwendungen. 24. August 2010, abgerufen am 29. August 2010.
  11. Dynamic-Link Library Security. Abgerufen am 29. August 2010.
  12. Researcher: Code-execution bug affects 200 Windows apps. 20. August 2010, abgerufen am 29. August 2010.
  13. DLL Hijacking – Vulnerable Applications. 25. August 2010, abgerufen am 29. August 2010.
  14. a b DLL Hijacking (KB 2269637) – the unofficial list. Abgerufen am 29. August 2010.
  15. Ein neuer Registrierungseintrag „CWDIllegalInDllSearch“ zum Steuern des DLL-Suchpfadalgorithmus ist verfügbar. 27. August 2010, abgerufen am 29. August 2010.
  16. Binary Planting: Microsofts Workaround lässt einzelne Anwendungen ausfallen. 28. August 2010, abgerufen am 29. August 2010.