[win32] DLL exploit. Hoe loadlibrary dan te gebruiken?

[leuk_he]

Eerst een stuk je van het verhaal.

http://webwereld.nl/nieuw...m=website&utm_campaign=ww

Na veel verwarring onder IT-professionals over hoe een eerste workaround van Microsoft werkte, heeft de Windows-maker een zogenaamde ‘fix it’-tool uitgegeven. Die werk alleen in combinatie met de eerdere workaround. De ‘fix it’-tool zorgt ervoor dat er geen DLL’s geladen kunnen worden van WebDAV of SMB shares. Dat zijn namelijk de meest waarschijnlijke richtingen waar aanvallen vandaan komen.

de bug zelf:

http://blog.metasploit.co...-dll-hijacking-flaws.html

This vulnerability is triggered when a vulnerable file type is opened from within a directory controlled by the attacker. This directory can be a USB drive, an extracted archive, or a remote network share. In most cases, the user will have to browse to the directory and then open the target file type for this exploit to work. The file opened by the user can be completely harmless, the flaw is that the application launched to handle the file type will inadvertently load a DLL from the working directory.

In practice, this flaw can be exploited by sending the target user a link to a network share containing a file they perceive as safe. iTunes, which was affected by this flaw until last week, is associated with a number of media file types, and each of these would result in a specific DLL being loaded from the same directory as the opened file. The user would be presented with a link in the form of \\server\movies\ and a number of media files would be present in this directory. If the user tries to open any of these files, iTunes would search the remote directory for one or more DLLs and then load these DLLs into the process. If the attacker supplied a malicious DLL containing malware or shellcode, its game over for the user.

Wil dit zeggen dat elk programma dat LoadLibrary gebruikt kwetsbaar is?

If the string specifies a full path, the function searches only that path for the module.

If the string specifies a relative path or a module name without a path, the function uses a standard search strategy to find the module; for more information, see the Remarks.
.....
Do not use the SearchPath function to retrieve a path to a DLL for a subsequent LoadLibrary call. The SearchPath function uses a different search order than LoadLibrary and it does not use safe process search mode unless this is explicitly enabled by calling SetSearchPathMode with BASE_SEARCH_PATH_ENABLE_SAFE_SEARCHMODE. Therefore, SearchPath is likely to first search the user’s current working directory for the specified DLL. If an attacker has copied a malicious version of a DLL into the current working directory, the path retrieved by SearchPath will point to the malicious DLL, which LoadLibrary will then load.

Do not make assumptions about the operating system version based on a LoadLibrary call that searches for a DLL. If the application is running in an environment where the DLL is legitimately not present but a malicious version of the DLL is in the search path, the malicious version of the DLL may be loaded. Instead, use the recommended techniques described in Getting the System Version.

( Ik denk hier vooral aan sites die ed2k links (eMule) aanbieden. maar in feite maakt dat voor de discussie niks uit)

Je kunt als programmeur niet het hele path opgeven toch? Want dat wordt bepaald gedurende installatie. Het is toch standaard dat je DLL in de directory neerzet waar de main executable staan? Of als je systeem libraries wilt gebruiken die verschillend zijn in verschillende Windows versies dan laat je het toch per definitie door windows uitzoeken? En niet alle DLL's zijn altijd beschikbaar in alle OS versions, dit is soms juist knap beroerd gedocumenteerd. (voorbeeld ICMP.dll)

Wie weet een link hoe je dit als programmeur kunt vinden en oplossen.

PS, Ik denk dat dit taal onafhangelijk is, alle programma's die als reactie op een openen van een file een loadlibrary doen kunnen wellicht kwetsbaar zijn?

[Sebazzz]

Ik heb het niet geprobeerd, maar .NET applicaties laden op dezelfde manier ook assemblies en kunnen mogelijk gevoelig hiervoor zijn. Overigens is dit niet zo als de applicatie is geconfigureerd om strong named assemblies te laden.

[_js_]

Je zou de current working directory tijdelijk aan kunnen passen voordat je dlls gaat inladen, bijvoorbeel naar de map waar je programma in staat. Als het goed is is je programma geïnstalleerd in een map waar niet zomaar dlls bij kunnen worden geplaatst, en ook in de windows mappen kunnen geen dlls worden geplaatst, ook de path environment variabele bevat standaard geen mappeen waar users bestanden kunnen neerzetten.

http://msdn.microsoft.com/en-us/library/ms682586(VS.85).aspx geeft aan welke paden en in welke volgorde deze worden doorzocht.

[Anoniem: 50683]

leuk_he schreef op donderdag 02 september 2010 @ 12:13:
Je kunt als programmeur niet het hele path opgeven toch?

Zover ik weet wel, je kan zeggen:
+ LoadLibrary('algemenedll.d') => Windows gaat voor je zoeken.
+ LoadLibrary('c:\windows\system32\algemenedll.d') => window zoekt niet voor je.

De diverse paden van windows kun je weer aan windows zelf vragen.

Eigen meegeleverde DLL's zou je kunnen runnen via opvragen van het path van je executable (ook weer opvraagbaar) en daar de dll achterplakken.

Op deze manier ben je niet meer afhankelijk van searchpaden indien je geen folder opgeeft voor het laden van je dll. Of deze manier gewenst is, is weer een ander verhaal.

[ Voor 6% gewijzigd door Anoniem: 50683 op 02-09-2010 14:23 ]

[leuk_he]

Anoniem: 50683 schreef op donderdag 02 september 2010 @ 14:21:
[...]
Zover ik weet wel, je kan zeggen:
+ LoadLibrary('algemenedll.d') => Windows gaat voor je zoeken.
+ LoadLibrary('c:\windows\system32\algemenedll.d') => window zoekt niet voor je.

Ik bedoel, al die paden kun je als programmeur toch niet bepalen?
-Of een DLL in system, system32 of nog exotischer plek staat wordt door het OS bepaald. Dat is toch niet gedocumteerd voor alle DLL's?
-Als je dll's van externe partijen gebruikt (directx) dan weet je toch al helemaal niet waar die staan?

Over de huidge directory veranderen zegt de doc van loadlibrary

quote: http://msdn.microsoft.com.../ms684175%28VS.85%29.aspx

The search path can be altered using the SetDllDirectory function. This solution is recommended instead of using SetCurrentDirectory or hard-coding the full path to the DLL.

Dat bedoelde ik met "niet hard-coden" van programmuer.

(en je komt uiteaard zondermeer inde knoei met dll's die geladen worden door dependencies)

[ Voor 6% gewijzigd door leuk_he op 02-09-2010 14:43 ]

[MSalters]

"Er zijn misschien wel honderd kwestbare applicaties" - en dan weet je al genoeg. Er zijn tienduizenden Windows apps. Normale programma's hebben dit probleem dus niet. De oorzaak is simpel: LoadLibrary kijkt eerst in de directory waar je EXE staat. Het grootste deel van de applicaties laadt z'n DLLs uit die directory, en loopt daardoor geen risico.

Als iTunes dus z'n DLLs daar had neergezet, dan had LoadLibrary nooit naar de Current Working Directory gekeken. Ik vermoed echter dat iTunes ook op Windows de PATH variable gebruikt om DLLs te vinden (Mac achtergrond van developers). De PATH directories worden op Windows pas na de CWD gecheckt.

[Soultaker]

leuk_he schreef op donderdag 02 september 2010 @ 12:13:
Wil dit zeggen dat elk programma dat LoadLibrary gebruikt kwetsbaar is?

Wat ik er van begrijp is dat LoadLibrary() zelf wel veilig is, maar niet als het pad naar de DLL bepaald wordt met SearchPath (waarna het gevonden pad weer aan LoadLibrary() gegeven wordt) want SearchPath() zoekt (in tegenstelling tot LoadLibrary()) ook in de huidige directory.

Ik denk dat een groot deel van de applicaties helemaal niet handmatig libraries laadt, en van de applicaties die het wel doen zal het grootste deel niet SearchPath gebruiken, dus ik denk dat het in de praktijk wel meevalt. Zoals MSalters ook aangeeft zijn er natuurlijk gigantisch veel Windows applicaties dus er zullen er best nog wat meer vulnerable zijn, maar toch...

edit:
Het is iets subtieler. Volgens deze informatie zoekt ook LoadLibrary in de huidige directory, dus dat zou alle applicaties die DLLs zoeken binnen het PATH vulnerable maken.

[ Voor 11% gewijzigd door Soultaker op 02-09-2010 17:02 ]

[leuk_he]

MSalters schreef op donderdag 02 september 2010 @ 16:42:
simpel: LoadLibrary kijkt eerst in de directory waar je EXE staat. Het grootste deel van de applicaties laadt z'n DLLs uit die directory, en loopt daardoor geen risico.

Als iTunes dus z'n DLLs daar had neergezet, dan had LoadLibrary nooit naar de Current Working Directory gekeken. Ik vermoed echter dat iTunes ook op Windows de PATH variable gebruikt

Met je eerste punt heb je gelijk. Dus alleen applicaties die dll's halen uit mogelijk andere directory's zijn kwetsbaar. Onder andere applicaties die plugin's ondersteunen door te kijken of een bepaalde dll bestaat, en die worden opgestart door op een bestands-associatie te klikken.