imported>InternetArchiveBot: InternetArchiveBot hat 1 Archivlink(s) ergänzt und 0 Link(s) als defekt/tot markiert.) #IABot (v2.0.9.5

2024-11-21T08:59:01Z

InternetArchiveBot hat 1 Archivlink(s) ergänzt und 0 Link(s) als defekt/tot markiert.) #IABot (v2.0.9.5

Neue Seite

'''DLL Hijacking''' (auch '''Binary Planting''' oder '''Remote Binary Planting''') bezeichnet das Laden einer [[Dynamic Link Library|DLL]] aus einem vom Programmentwickler nicht vorgesehenen Pfad. Sofern keine vollständige Pfadangabe zu der DLL gegeben ist, wird unter Windows standardmäßig zuerst in dem Ordner gesucht, in welchem das Programm selbst liegt. Viele sehen dieses Verhalten als eine [[Sicherheitslücke (Software)|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 ==
DLLs werden in [[Microsoft Windows|Windows]] zur Laufzeit von Programmen explizit über die [[WinAPI]]-Funktionen <code>LoadLibrary</code><ref name="MSDN LoadLibrary">{{Internetquelle |autor=Microsoft |url=https://msdn.microsoft.com/en-us/library/ms684175.aspx |titel=LoadLibrary Function (Windows) |datum=2010-09-23 |zugriff=2010-09-29}}</ref> und <code>LoadLibraryEx</code><ref name="MSDN LoadLibraryEx">{{Internetquelle |autor=Microsoft |url=https://msdn.microsoft.com/en-us/library/ms684179.aspx |titel=LoadLibraryEx Function (Windows) |datum=2017-08-19 |zugriff=2017-08-19}}</ref> geladen;<ref name="MSDN Run-Time Dynamic Linking">{{Internetquelle |autor=Microsoft |url=https://msdn.microsoft.com/en-us/library/ms685090.aspx |titel=Run-Time Dynamic Linking |datum=2017-08-19 |zugriff=2017-08-19}}</ref> beim Laden von Programmen und DLLs werden statisch gelinkte DLLs von Windows’ Modullader implizit geladen.<ref name="MSDN Load-Time Dynamic Linking">{{Internetquelle |autor=Microsoft |url=https://msdn.microsoft.com/en-us/library/ms684184.aspx |titel=Load-Time Dynamic Linking |datum=2017-08-19 |zugriff=2017-08-19}}</ref>
Wenn dabei kein vollständig qualifizierter [[Pfadname|Pfad]] zur DLL angegeben wird, ist DLL Hijacking in beiden Fällen möglich.
Die zu ladende Datei wird dann anhand der von ''Dynamic-Link Library Search Order''<ref>{{Internetquelle |autor=Microsoft |url=https://msdn.microsoft.com/en-us/library/ms682586.aspx |titel=Dynamic-Link Library Search Order |datum=2010-09-23 |zugriff=2010-08-29}}</ref> spezifizierten Suchreihenfolge geladen, wobei die Datei standardmäßig zuerst im Programmverzeichnis, dann in Systemverzeichnissen, dann im [[Arbeitsverzeichnis]] und zuletzt in den von der [[Umgebungsvariable#Vordefinierte Umgebungsvariablen (Windows)|Umgebungsvariable]] <code>PATH</code> angegebenen Verzeichnissen gesucht wird.
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) oder eine von dieser verwendete DLL versucht, die Erweiterung (DLL-Datei) über die <code>PATH</code>-Variable zu laden und wechselt beim Öffnen vom Arbeitsverzeichnis in das Verzeichnis der Datendatei.<ref name="zdnet">{{Internetquelle |autor=Christoph H. Hochstätter |url=http://www.zdnet.de/sicherheits_analysen_remote_binary_planting_die_unpatchbare_luecke_in_windows_story-39001544-41536850-1.htm |titel=Remote Binary Planting: Die unpatchbare Lücke in Windows |datum=2010-08-27 |zugriff=2010-09-18}}</ref>

Dieses Prinzip ist vergleichbar mit dem Verhalten des „Ausführen“-Dialogs oder der Eingabeaufforderung unter Windows. Gibt man dort den Befehl <code>cmd.exe</code> ein, wird die Datei <code>cmd.exe</code> zuerst in dem ausgewählten Pfad gesucht; wenn das System dort nicht fündig wurde, wird in den Pfaden der Umgebungsvariable nach der Datei gesucht.

Wie am 8. September 2010 bekannt wurde,<ref name="acrosexe">{{Internetquelle |autor=ACROS |url=http://blog.acrossecurity.com/2010/09/binary-planting-goes-exe.html |titel=ACROS Security Blog: Binary Planting Goes "EXE" |datum=2010-09-08 |zugriff=2010-09-29}}</ref> sind neben der beschriebenen API-Funktion weitere Funktionen von diesem, nur auf der englischen MSDN-Webseite, offiziell dokumentierten Verhalten<ref name="MSDN LoadLibrary" /> betroffen. Es handelt sich dabei um die Funktionen <code>CreateProcess*</code>, <code>ShellExecute*</code>, <code>WinExec</code>, <code>LoadModule</code>, <code>_spawn*p*</code> und <code>_exec*p*</code>,<ref name="acrosexe" /> die [[EXE]]-Dateien ausführen bzw. [[Prozess (Informatik)|Prozesse]] starten. Die Funktionsweise entspricht der oben genannten, wobei sich die einzelnen Suchreihenfolgen unterscheiden.

Am 24. November 2013 veröffentlichte Stefan Kanthak<ref>{{Internetquelle |autor=Stefan Kanthak |url=https://skanthak.homepage.t-online.de/sentinel.html |titel=Exploit and Vulnerability Detector |zugriff=2017-08-18}}</ref>, dass beim Aufruf von [[Stapelverarbeitung|Batch]]-Skripts über <code>CreateProcess*</code> resp. <code>ShellExecute*</code> ein im Arbeitsverzeichnis stehendes Programm <code>cmd.exe</code> ausgeführt wird.<ref>{{Internetquelle |autor=Stefan Kanthak |url=http://seclists.org/fulldisclosure/2013/Nov/185 |titel=Defense in depth -- the Microsoft way (part 14): incomplete, misleading and dangerous documentation |datum=2013-11-13 |zugriff=2014-09-27}}</ref>
Diese seit mindestens [[Microsoft Windows NT 4.0|Windows NT 4.0]] existierende Sicherheitslücke hat Microsoft erst am 8. April 2014 mit dem Sicherheitsupdate MS14-019 geschlossen.<ref>{{Internetquelle |url=https://technet.microsoft.com/library/security/ms14-019 |titel=Microsoft Security Bulletin MS14-019 – Kritisch |datum=2014-04-08 |zugriff=2014-09-27}}</ref>

== Zeitlicher Ablauf ==
Binary Planting wurde im Jahr 2000 erstmals beschrieben.<ref>{{Internetquelle |autor=Georgi Guninski |url=http://www.securityfocus.com/bid/1699/discuss |titel=Microsoft Windows DLL Search Path Weakness |datum=2000-09-18 |zugriff=2010-09-18 |archiv-url=https://web.archive.org/web/20110708034307/http://www.securityfocus.com/bid/1699/discuss |archiv-datum=2011-07-08 |offline=ja |archiv-bot=2024-11-21 08:59:01 InternetArchiveBot }}</ref>
Am 18. August 2010 wurde dieses Problem in iTunes von ACROS entdeckt und publiziert.<ref>{{Internetquelle |autor=ACROS |url=http://www.acrossecurity.com/aspr/ASPR-2010-08-18-1-PUB.txt |titel=ACROS Security Problem Report #2010-08-18-1 |datum=2010-08-18 |zugriff=2010-09-18}}</ref> Es kam zu einer medialen Verbreitung der Sicherheitslücke. Microsoft hat am 23. August 2010 eine Sicherheitsempfehlung zu diesem Problem herausgegeben.<ref name="ms2269637">{{Internetquelle |autor= |url=https://docs.microsoft.com/en-us/security-updates/securityadvisories/2010/2269637 |titel=Nicht sicheres Laden einer Bibliothek kann Remotecodeausführung ermöglichen (2269637) |werk= |hrsg= |datum=2010-08-23 |zugriff=2010-08-29 |sprache=}}</ref> Das Nachladen von DLLs aus dem Arbeitsverzeichnis gehört zum Design des Betriebssystems.<ref name="golem24">{{Internetquelle |url=http://www.golem.de/1008/77437.html |titel=Binary Planting: Windows-Sicherheitslücke betrifft dutzende Anwendungen |datum=2010-08-24 |zugriff=2010-08-29}}</ref> Zum sicheren Laden von externen Bibliotheken hat Microsoft eine Empfehlung verfasst.<ref>{{Internetquelle |url=https://msdn.microsoft.com/en-us/library/ff919712.aspx |titel=Dynamic-Link Library Security |zugriff=2010-08-29}}</ref>

== Verbreitung ==
Erste Schätzungen gingen von etwa 200 betroffenen Programmen aus.<ref>{{Internetquelle |url=http://www.theregister.co.uk/2010/08/20/windows_code_execution_vuln/ |titel=Researcher: Code-execution bug affects 200 Windows apps |datum=2010-08-20 |zugriff=2010-08-29}}</ref> 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<ref>{{Internetquelle |url=http://www.exploit-db.com/dll-hijacking-vulnerable-applications/ |titel=DLL Hijacking – Vulnerable Applications |datum=2010-08-25 |zugriff=2010-08-29 |archiv-url=https://web.archive.org/web/20100830141311/http://www.exploit-db.com/dll-hijacking-vulnerable-applications/ |archiv-datum=2010-08-30 |offline=ja |archiv-bot=2023-12-08 10:04:00 InternetArchiveBot }}</ref> zusammenfasst. Eine inoffizielle Liste wird von Corelan Team geführt.<ref name="corelan">{{Internetquelle |url=http://www.corelan.be:8800/index.php/2010/08/25/dll-hijacking-kb-2269637-the-unofficial-list/ |titel=DLL Hijacking (KB 2269637) – the unofficial list |zugriff=2010-08-29 |offline=ja |archiv-url=https://web.archive.org/web/20100828132433/http://www.corelan.be:8800/index.php/2010/08/25/dll-hijacking-kb-2269637-the-unofficial-list/ |archiv-datum=2010-08-28 }}</ref> Unter den betroffenen Programmen sind [[Mozilla Firefox|Firefox]], [[Opera (Browser)|Opera]], [[Microsoft PowerPoint]], [[µTorrent]] und [[VLC media player|VLC]] zu finden.<ref name="corelan" />

== Gegenmaßnahmen ==
Eine vollständige Lösung des Problems kann nur durch die Entwickler der Anwendungen in Form von [[Softwareaktualisierung|Sicherheitsupdates]] geliefert werden.<ref name="golem24" /> Als vorübergehende Lösung kann aus dem Microsoft Download Center ein Update installiert werden, welches einen neuen [[Windows-Registrierungsdatenbank|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 Freiheit, DLL aus dem Arbeitsverzeichnis zu laden, beschränkt oder unterbunden werden,<ref>{{Internetquelle |url=https://support.microsoft.com/kb/2264107/de |titel=Ein neuer Registrierungseintrag „CWDIllegalInDllSearch“ zum Steuern des DLL-Suchpfadalgorithmus ist verfügbar |datum=2010-08-27 |zugriff=2010-08-29}}</ref> was aber zu Problemen bei Programmen führt, die sich auf das Funktionsprinzip von LoadLibrary und anderen betroffenen Funktionen korrekt stützen.<ref>{{Internetquelle |url=http://www.golem.de/1008/77546.html |titel=Binary Planting: Microsofts Workaround lässt einzelne Anwendungen ausfallen |datum=2010-08-28 |zugriff=2010-08-29}}</ref> Daneben empfiehlt Microsoft, den Webclient-Dienst abzuschalten und die TCP-Ports [[Server Message Block|139 und 445]] in der Firewall zu blockieren.<ref name="ms2269637" /> Dies verhindert den Zugriff auf Netzwerkfreigaben und WebDAV-Verzeichnisse.

== Einzelnachweise ==
<references />

[[Kategorie:Sicherheitslücke]]

DLL Hijacking - Versionsgeschichte

imported>InternetArchiveBot: InternetArchiveBot hat 1 Archivlink(s) ergänzt und 0 Link(s) als defekt/tot markiert.) #IABot (v2.0.9.5