Het wordt steeds gekker! Acros zegt dat ze al 127 applicaties hebben gevonden die kwetsbaar zijn voor het laden van EXE files uit de CWD.

Wel jammer dat onze eigen Bitwiper niet met de eer van deze ontdekking is gaan strijken.

Aanvulling op het artikel van de Redactie: de registerwaarde "CWDIllegalInEXESearch" bestaat nog helemaal niet, maar in navolging van CWDIllegalInDLLSearch heb ik aan Microsoft voorgesteld zo'n registerwaarde te gaan ondersteunen.

Hoewel ik zo snel geen remote exploits verwacht *AANVULLING*: die zijn kennelijk wel mogelijk (zie http://seclists.org/bugtraq/2010/Sep/61), liggen combinatie aanvallen of social engineering wel erg voor de hand. Microsoft moet hier snel wat aan doen, d.w.z. in elk geval de mogelijkheid scheppen dat beheerders hun PC's kunnen beschermen!

Zo'n nieuwe registerwaarde is verre van perfect, maar belangrijker dan bij DLL's, want voor DLL's geldt volgens http://support.microsoft.com/kb/2264107 de volgende zoekvolgorde:

1. The directory from which the application loaded
2. The system directory
3. The 16-bit system directory
4. The Windows directory
5. The current working directory (CWD)
6. The directories that are listed in the PATH environment variable

Volgens http://blog.acrossecurity.com/2010/09/binary-planting-goes-exe.html is de zoekvolgorde voor EXE bestanden echter:

1. The directory from which the application loaded
2. Current working directory
3. 32-bit System directory (Windows\System32)
4. 16-bit System directory (Windows\System)
5. Windows directory (Windows)
6. Directories in the PATH environment variable

Wat betekent dit? Stel een willekeurig programma start "cmd.exe" op, dus niet expliciet "C:\Windows\System32\cmd.exe". Tenzij dat willekeurige programma in C:\Windows\System32 staat zal eerst in de application directory van dat programma gekeken worden (maar de kans dat daar ook een cmd.exe staat is klein), waarna in de current working directory van dat programma gekeken zal worden. Meer details wil ik hier op dit moment nog niet over kwijt.

Ik had daar een lijstje gevonden ergens, geen idee of het van nut is hier.

http://www.corelan.be:8800/index.php/2010/08/25/dll-hijacking-kb-2269637-the-unofficial-list/

MS TechNet zelf:

http://blogs.technet.com/b/srd/archive/2010/08/31/an-update-on-the-dll-preloading-remote-attack-vector.aspx

MS Support Nederlands:

http://support.microsoft.com/kb/2264107

Have fun :s

Leuk dat je aan me denkt, maar ik vind dit vooral zorgelijk. Sowieso ben ik niet zo van "eer", ik probeer net als veel anderen op dit forum mensen te helpen hun PC veiliger te maken, en heb er totaal geen moeite mee om daarbij Microsoft onder druk te zetten, immers we (ik in elk geval) betalen voor die meuk!

Het zat er overigens wel in dat zoiets zou gebeuren, ik moet hier ook maar eens induiken. Dat er zoveel programma's zijn die exe files naladen verbaast me wel (die 127 volgens Across die je noemde).

Mocht Microsoft net zo'n registervariabele maken als voor DLL's dan vermoed ik dat mijn tip hier: http://www.security.nl/artikel/34260/1/Problemen_na_DLL-lek-patch_KB2264107_en_CWDIllegalInDllSearch%3DFFFFFFFF.html (dus iets in App Paths zetten) ook goed zal werken voor applicaties die dan ineens niet meer werken. Daarmee bedoel ik die apps die CWD instellen op een map met aanvullende exe files, en er dan vanuit gaan dat ze zo'n exe -zonder een absoluut pad te specificeren- kunnen starten (vergelijkbaar met waarom Outlook bij mij sommige DLL's niet meer kon vinden).

Overigens kan die tip van mij volgens Microsoft helemaal niet werken voor DLL's! In http://msdn.microsoft.com/en-us/library/ms682586%28v=VS.85%29.aspx staat: "App Paths key is not used when computing the DLL search path" maar een snel onderzoekje op XPSP3 laat zien dat zo'n registerwaarde wel wordt gechecked (anders zou Outlook het echt niet meer doen bij mij). Ook heb ik ergens gelezen (ik weet even niet meer waar) dat dit pad geen spaties zou mogen bevatten (en je dus 8.3 namen zou moeten gebruiken) maar gek genoeg zie ik op een XPSP3 PC met Office 2007 erop het omgekeerde! In het Path zitten wel spaties maar juist niet in de Default value:

Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\excel.exe
met de volgende values daaronder (alle 4 van type REG_SZ):
(Default)=C:\PROGRA~1\MICROS~2\Office12\EXCEL.EXE
Path=C:\Program Files\Microsoft Office\Office12\
SaveURL=1
useURL=1

De logica hiervan ontgaat me volledig, iemand?

(wegens lengte opgesplitst in 2 bijdragen).

Ik speel nu met de gedachte om, zolang Microsoft zo'n registerwaarde als CWDIllegalInEXESearch niet ondersteunt, te kijken of je "EXE Hijacking" exploits kunt voorkomen door (vergelijkbaar aan bovenstaande subkey excel.exe), subkeys aan te maken voor potentieel kwetsbare programma's. Voor CMD.exe zou je dan moeten aanmaken:

Key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\cmd.exe
Value: (Default)=C:\Windows\System32\cmd.exe

Ik ga daar vanavond wat mee testen, dus kijken of je daarmee verhindert dat malware met de naam "cmd.exe" in de een of andere downloadmap wordt gestart als dat toevallig de CWD is, i.p.v. de bedoelde cmd.exe van Microsoft (daarbij zal ik ook kijken naar het effect van spaties, natuurlijk belangrijk bij exe files onder "C:\Program Files\").

Let op: volgens http://msdn.microsoft.com/en-us/library/ee872121%28VS.85%29.aspx lijkt het zinloos (maar MS documentatie klopt niet altijd) om iets met de value "Path" i.p.v. "(Default)" onder zo'n subkey te doen. M.b.t. de value Path schrijft Microsoft: De reden waarom het waarschijnlijk zinloos is om met juist met die value Path te experimenteren: kennelijk (zie beide lijstjes in de bijdrage van Erik van Straten) worden "Directories in the PATH environment variable" pas op het allerlaatste moment gecheckt, en dat geldt zo te zien zowel voor DLL als voor EXE searches!

Bizar als je dit met Unix/Linux systemen vergelijkt, waarvan users al eeuwen gewaarschuwd worden om niet "." in hun "path" op te nemen. Wat Microsoft hier doet is de meest gevaarlijke optie: "." als eerste evalueren en PATH op het laatst :(

Ik zie trouwens in de laatstgenoemde webpage dat Win7 gebruikers die geen admin rechten hebben, voor zichzelf "prive", vergelijkbare "App Paths" instellingen kunnen aanmaken onder HKCU (d.w.z. mits je regedit mag starten van de plaatselijke BOFH ;)

go bitwiper ! go !
make MS smell!!

Ik ben nog druk aan het onderzoeken, maar vond een interessante optie (bron: http://www.howtofixcomputers.com/forums/xp-networking/prevent-windows-explorer-dll-searching-unc-home-folder-220406.html) die ik meteen wil noemen!

In http://support.microsoft.com/kb/905890 beschrijft Microsoft een optionele registerwaarde (deze bestaat niet op m'n XPSP3 systeem):

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\
Value: SafeProcessSearchMode = 1 (type REG_DWORD)
In KB905890 stelt Microsoft dat je voor W2K3 en XP een hotfix nodig hebt om SafeProcessSearchMode te ondersteunen (onder XP SP2 zou het alleen om Kernel32.dll gaan, zie de webpage welke DLL's het voor W2K3 betreft).

Echter ik heb op m'n XPSP3 een Kernel32.dll van veel latere datum dan 17-Dec-2005, daarin kan ik de (Unicode) tekst "SafeProcessSearchMode" terugvinden! Het is gebruikelijk dat hotfixes uiteindelijk in servicepacks (en latere patches) worden meegenomen, zeker als het om optionele registerwaarden gaat kan dit natuurlijk nooit kwaad.

Update 2010-09-12 23:56 - Voorlopige resultaten (XPSP3) van m'n onderzoek naar SafeProcessSearchMode=1
(1) In tegenstelling tot wat http://support.microsoft.com/kb/905890 doet vermoeden aan de hand van de opmerking "A program that does not have a Start in property searches for DLL files in the current working folder first, and then the folders that are specified in the system path" heeft deze registerwaarde (in elk geval onder XPSP3) geen effect op de zoekvolgorde van DLL's.

(2) De claim in http://support.microsoft.com/kb/905890 "When the value of this registry entry is set to "1," the computer first searches the folders that are specified in the system path, and then searches the current working folder" is geheel onjuist (PATH komt altijd op de laatste plaats).

Ik heb de invloed van SafeProcessSearchMode=1 op de WinAPI calls "CreateProcess" en "ShellExecute" onderzocht. Terwijl ik Process Monitor van SysInternals laat draaien probeer ik een niet bestaand programma "pipo.exe" op te starten (HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\pipo.exe bestaat ook niet). Resultaten:

CreateProcess: hier heeft SafeProcessSearchMode=1 wel invloed op, de zoekvolgorde wordt:
1. Application directory
2. C:\Windows\System32\
3. C:\Windows\System\
4. C:\Windows\
5. CWD
6. PATH
LET OP: er lijkt NIET in App Paths (HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\pipo.exe) te worden gezocht!

ShellExecute: hier heeft SafeProcessSearchMode=1 geen invloed op, de zoekvolgorde blijft:
1. HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\pipo.exe
2. CWD
3. C:\Windows\System32\
4. C:\Windows\System\
5. C:\Windows\
6. PATH
LET OP: er wordt NIET in de Application Directory gezocht!

CMD.EXE lijkt geen van de standaard WinAPI calls te gebruiken en zoekt als volgt als ik pipo.exe + enter intik:
1. CWD (dat is de drive en map waar de "commandprompt" actief is)
2. PATH
3. Melding dat pipo.exe niet gevonden is
LET OP: ook "App Paths" lijkt hierbij te worden genegeerd! CMD lijkt hier het klassieke DOS (of zelfs CP/M ;) gedrag te vertonen. Zoals in http://blog.acrossecurity.com/2010/09/binary-planting-goes-exe.html staat aangegeven is dat vermoedelijk nooit gewijzigd om bergen bestaande batchfiles niet te slopen. Gewone gebruikers zullen CMD.EXE natuurlijk zelden of nooit gebruiken; de "DOT-issue" is echter des te gevaarlijker voor admins die in user-writable directories onbedoeld een trojan starten!

Explorer.exe lijkt gebruik te maken van ShellExecute voor het starten van processen. SafeProcessSearchMode lijkt hier dan ook geen enkele invloed op te hebben. Echter door het zetten van "App Paths" lijken mogelijke exploits wel te kunnen worden voorkomen.

Voorlopige conclusie: zolang er geen fix verschijnt van Microsoft vermoed ik dat PC's redelijk beschermd kunnen worden tegen EXE-hijacking attacks door SafeProcessSearchMode=1 te zetten, en door gangbare executables die, zonder absolute pad-aanduiding, vanuit andere processen (waaronder Explorer dus je desktop) worden gestart, zoveel mogelijk App Paths entries aan te maken (welke precies is een ander verhaal). Duidelijk is dat dit een ingewikkeld probleem is...

Ik googlede nog even naar SafeProcessSearchMode binary planting en vond deze: http://seclists.org/bugtraq/2010/Sep/71.

M.b.t. opmerking 1 daarin betreffende "SafeProcessSearchMode": zoals je hierboven kunt lezen heeft dat alleen zin voor programma's die CreateProcess (en mogelijk WinExec of LoadModule) gebruiken om andere executables te starten (welke dat allemaal zijn heb ik geen idee van).

Echter Explorer wordt door elke Windows user gebruikt, en die negeert SafeProcessSearchMode. M.a.w. "SafeProcessSearchMode" is geen volwaardig equivalent voor "SafeDLLSearchPath" (n.b. SafeDLLSearchPath hoef je in XPSP2 en later nergens te zetten, als deze registerwaarde niet bestaat doet Windows alsof deze wel bestaat en de waarde 1 heeft, waarmee eerst in enkele andere mappen en dan pas in CWD naar DLL's gezocht wordt).

Bovendien lossen SafeProcessSearchMode en SafeDLLSearchPath het fundamentele probleem niet op als het gezochte bestand niet in de mappen voorkomt die eerder dan CWD worden doorzocht (als er vervolgens malware met dezelfde naam in CWD gevonden wordt, ben je het haasje).

M.b.t. opmerking 2 in die bugtraq post betreffende "StartRunNoHomePath" (zie http://support.microsoft.com/kb/264061): dat had ik al eerder onderzocht, deze instelling heeft uitsluitend effect op programma's die je opstart via "Start | Run" (NL: Start | Uitvoeren), niet als je Explorer op andere wijze programma's laat starten. Het effect ervan kun je simpel zelf testen, kopieer bijv. notepad.exe naar %HOMEDRIVE%%HOMEPATH% en hernoem deze in cmd.exe, en kopieer calc.exe naar %USERPROFILE%\Desktop en hernoem ook deze in cmd.exe. Daarna experimenteer je met beide onderstaande registerwaardes en "Start|Run|cmd" (je moet wel even uit+inloggen na het wijzigen van de registerwaarde), in het eerste geval start notepad, in het tweede calculator:

StartRunNoHomePath=0 (of registerwaarde ontbreekt): Explorer kijkt na Start|Run eerst in CWD (voor Explorer is dit by default %HOMEDRIVE%%HOMEPATH%), en dan in C:\Windows\System32 etc.

StartRunNoHomePath=1: Explorer kijkt na Start|Run eerst in %USERPROFILE%\Desktop (doet dat in plaats van in CWD), en dan in C:\Windows\System32 etc.

Dat laatste is uit security oogpunt mogelijk nog slechter dan de default situatie (denk maar aan de Safari Carpet Bomb issue waarbij door het slechts bezoeken van een website met Safari er ongemerkt bestanden op je desktop konden worden gegooid). De registerwaarde StartRunNoHomePath is dan ook alleen gemaakt om vertragingen te voorkomen indien %HOMEDRIVE%%HOMEPATH% op een netwerkdrive is gemount.

M.b.t. opmerking 3: voor gebruikers die als admins inloggen (schrijfrechten onder C:\Windows, C:\Windows\System32, C:\Program Files etc.) is Binary Planting een potentieel veel grotere issue dan voor gebruikers die als non-admins werken, maar daar valt bar weinig tegen te doen. Immers die mappen zijn "well known locations", als een aanvaller daarin bestanden kan droppen heb je echt een serieus probleem.

Mij gaat het vooral om de mensen die secure werken (als non-admin dus), ook die kunnen eenvoudig slachtoffer worden van deze binary planting attacks. Normaal gesproken wil je (als BOFH ;) niet dat zij gedownloade uitvoerbare bestanden kunnen starten, zeker niet als dat onbedoeld gebeurt (en het dus waarschijnlijk om malware gaat).

PS ik heb dit weekend ook even wat met SRP gespeeld (Software Restriction Policies, zie http://www.mechbgon.com/srp/), maar dat leverde vooral veel problemen op. Bijv. snelkoppelingen op je desktop en onder het start menu zijn in principe ook executable files, en het is erg lastig als die het ook ineens niet meer doen...

Hè wat heerlijk! Alles is weer de schuld van Microsoft, waar het ook vandaan komt. Ik voel me weer helemaal thuis hier.

Respect to Bitwiper & Erik van Straten! :-)