Sysinternals procesmonitor kan je dit mee detecteren echter niet geautomatiseerd in link hieronder meer uitleg en automatisering tips. Maar menig antimalware platform echter pakt dit ook op het is niet een geavanceerde aanval vector. Beheerders dealen hier al mee ver voor 2010

https://posts.specterops.io/automating-dll-hijack-discovery-81c4295904b0

Dát is flauwe kul. Dat er een mogelijkheid tot corruptie bestaat betekent nog niet dat die corruptie meteen overal een feit is.

Analogie: dat de mogelijkheid bestaat om als voetganger op een zebrapad te worden aangereden betekent niet dat elke overstekende voetganger ook werkelijk aangereden wordt.

Zoals je over DLL's schrijft doet vermoeden dat je eigenlijk geen idee hebt wat voor functie ze hebben en wat er precies gebeurt. De CPU van een computer voert machine-instructies uit. Die instructies zitten in uitvoerbare programmabestanden, op Windows bestanden met de extensie ".exe". Nou bestaat er heel veel van dat soort code die door vele programma's gebruikt wordt. Bijvoorbeeld de code waarmee een programma met het besturingssysteem communiceert, zoals wat nodig is om een bestand te kunnen lezen of schrijven, of om netwerkverkeer te kunnen doen, of om allerlei aangekoppelde hardware te kunnen gebruiken. Maar ook code om bijvoorbeeld jpeg-bestanden (afbeeldingen) te kunnen lezen, of om mp3-bestanden (audio) af te kunnen spelen, of om encryptie-algoritmes toe te passen, is van die code die door vele programma's gebruikt wordt. Die wordt dan niet allemaal in elk ".exe"-bestand dat het nodig heeft opnieuw opgenomen, maar in plaats daarvan in een zogenaamde library, een bestand dat een bibliotheek met nuttige functies is. Op Windows heet dat een dll (dynamic link library). Een dll bevat dus net als een exe-bestand programmacode, maar dan code die door vele programma's gebruikt kan worden en daarom apart is gezet in een dll-bestand dat door al die andere programma's tijdens de uitvoering geladen kan worden.

Dat heeft niet alleen maar nadelen voor de beveiliging, dat heeft ook voordelen. Als er bijvoorbeeld een kwetsbaarheid zit in code om een jpg-bestand te ontcijferen, dan hoeft alleen maar die dll vervangen te worden door een gerepareerde versie en alle programma's die de dll gebruiken zijn in een klap niet meer kwetsbaar, zonder dat al die programma's door een nieuwe versie vervangen moeten worden.

Bestanden kunnen vervangen worden door wie er voldoende rechten voor heeft, ook dll's. Maar om een systeem-dll te vervangen moet je wel systeemrechten hebben. Ook zijn er mogelijkheden om te beïnvloeden waar een dll die geladen moet worden precies gezocht wordt op het systeem. Er zijn daardoor inderdaad mogelijkheden om nare dingen aan te richten. Maar bedenk wel dat je systeem al gecompromitteerd moet zijn om dit te kunnen doen. Het is nogal wiedes dat een aanvaller die al binnen is op je systeem daar vervelende dingen kan doen, net zo goed als een inbreker die al in je huis is makkelijk bij je spullen kan. Maar het is echt niet zo dat iedereen op de wereld zonder enige beperking op alle computers van de wereld bestanden kan gaan vervangen. Ze moeten eerst binnen zien te komen, en daarna pas kunnen ze dit soort dingen doen.

De tegenmaatregelen zijn wat je sowieso al moet doen: je systeem up-to-date houden; niet zomaar alle software die je ergens op het web vindt uitvoeren op je computer maar zorgvuldig en terughoudend zijn in wat je installeert en waar je het vandaan haalt; antivirussoftware draaien; niet bij elke pop-up die je niet begrijpt maar op "ok" klikken om ervan af te zijn. Al die adviezen waarvan ik aanneem dat je die regelmatig op allerlei plaatsen tegenkomt en waarvan ik hoop dat je ze serieus neemt.

Er zaten oorspronkelijk wel enorme denkfouten in het mechanisme waarmee DLL's geladen worden!
Een programma laadt een DLL niet met een volledige padnaam, maar door alleen de filenaam op te geven (zonder
directories dus) en dan gaat het systeem die file voor je "zoeken".
Daarbij werd ooit het volgende systeem gehanteerd:
1. huidige directory
2. installatiedirectory van het programma
3. centrale locatie voor systeem DLL's.

Dat is natuurlijk hardstikke onveilig, want dan kan een DLL die door iemand in je werkdirectory wordt neergezet ineens
worden meegenomen bij de uitvoering van al je programma's! Maar dat werd op een gegeven moment wel bekend en
toen is dat mechanisme wel aangepast zodat alleen stap 2 en 3 nog gebruikt worden.
Dat is nog steeds niet veilig als je programma geinstalleerd staat in een directory waar je zelf mag schrijven. Sommige
applicaties maken hun programma directory schrijfbaar. Dat is ook iets uit de oudheid, tegenwoordig wordt in dat soort
gevallen de variabele data in een aparte directory ProgramData gezet in plaats van onder Program Files.
Maar goed wellicht zijn er nog verkeerd geconfigureerde systemen en/of programma's.
Eigenlijk is het beter als programma's de "eigen DLL's" ook op een systeemlocatie installeren, zoals dat bijvoorbeeld in
Linux gebeurt. Die locaties houd je dan dicht voor iedere gebruiker en dan is de kans op malafide DLL's een stuk
kleiner. Maar goed daar gaat dan weer even overheen voor iederen het daar over eens is en op is overgestapt.

Dank voor de uitleg.

Hier nog enkele posts over dit onderwerp:

https://portableapps.com/news/2017-03-13--mitigating-dll-hijacks-with-the-portableapps-com-platform

https://www.wietzebeukema.nl/blog/hijacking-dlls-in-windows

Hier worden heel bekende programmas genoemd die gevoelig zijn voor dit probleem. Toch wel heel zorgwekkend.
Mogelijk dat inmiddels die programmas tegen die gevoeligheid zijn aangepast.
Maar ik vond ook communicatie waarbij de getipte software-ontwikkelaars het probleem willens en wetens negeerden.
Toch niet geruststellend.

PS:
Ik meen te begrijpen dat portable software (in een map onder een Download-map en/of op een andere drive/map dan C:/Program Files) de grootste kans op dll-hijacking heeft?
Dan zou het dus beter zijn om een gewenst programma in Program Files (X86) te installeren en niet te kiezen voor de portable oplossing (PortableApps heeft maatregelen genomen tegen dit risiko, zie bovenstaande link)?

Quote:

Maar ik vond ook communicatie waarbij de getipte software-ontwikkelaars het probleem willens en wetens negeerden.
Toch niet geruststellend.


https://borncity.com/win/2020/04/16/dll-hijacking-vulnerabilities-in-nirsoft-tools/


Blog van Nirsoft over anti-virus-fouten en misbruik van zijn tools (maar geen info over dll-hijacking gevoeligheid van zijn tools):

https://blog.nirsoft.net/category/antivirus-issues/

https://blog.nirsoft.net/category/internet-scams/

In de eerste melding wordt verwezen naar SPYDLL, dat moet zijn DLLSPY.

Zie volgende link:
https://www.cyberark.com/resources/threat-research-blog/dllspy-tighten-your-defense-by-discovering-dll-hijacking-easily

Hieruit blijkt dat het probleem door het Software-establishment wordt genegeerd.

Hier is er meer over te lezen:
https://borncity.com/win/2020/04/16/dll-hijacking-vulnerabilities-in-nirsoft-tools/

De Israëli, Nir Sofer, komt zelf uit de MS-keuken, vandaar.
Hij zal ook wel weten hoe MS te hacken valt.
Veel van zijn tooltjes vereisen admin rechten
Dat is al voldoende risico op zich.

luntrus

Ik heb zowel Nir Sofer als Günter Born hoog zitten, maar in dit geval slaat m.i. Günter de plank mis.

Je kunt bij DLL-hijacking twee scenario's onderscheiden waar we m.i. zorgvuldig onderscheid tussen moeten maken:

1) CWD: het scenario dat een programma ook in de "Current Working Directory" (CWD) zoekt naar een DLL, die daar vindt, laadt en er code in uitvoert;

2) Program directory / PATH: het scenario dat een programma een DLL gebruikt uit de directory waarin het programma zelf staat, of uit een directory in de PATH omgevingsvariabele, of uit default map speciaal bedoeld voor libraries.

Als in scenario 2 een kwaadaardige DLL uit de program directory wordt geladen (dit lijkt te zijn wat Günter Born beschrijft), dan is dat geen kwetsbaarheid, maar falende cyberhygiëne.

Voorbeeld: als je een programma start in een default "download" directory, ben je stom bezig (dit geldt, naast voor Windows, net zo goed voor Linux, BSD etc).

Niet omdat dit de CWD is, maar omdat dit de directory is met vaak een onoverzichtelijke hoop oude bestanden én waar de executable in staat, en dus de map waarin dat programma zoekt naar "begeleidende" bestanden zoals DLL's (daarbij kan het overigens ook om configuratiefiles gaan waarmee een programma op het verkeerde been kan worden gezet).





Is het dan fool proof? Nee, absoluut niet. Malware die jij onbedoeld start mag nog steeds alles wat jij mag. Je beperkt zo wel een aantal risico's. Het is zo lastiger om jouw hele systeem te compromitteren en "opruimen" na een incident is meestal minder werk. Het is vooral erger proberen te voorkómen.

Toelichting CWD, program directory en PATH
Wat je moet weten is dat de meeste besturingssystemen, voor elk programma dat gestart wordt (om precies te zijn elke instantie van een programma), een administratieve tabel aanmaken met daarin onder meer de "Current Working Directory" (CWD). Als het programma start, "erft" het de CWD van het parent proces.

Daarna kan het programma diens eigen CWD (in die tabel) wijzigen, bijvoorbeeld door de CWD van de laatste run uit een configuratiefile te halen, ofwel als gevolg van een handmatige gebruikershandeling, ofwel omdat de programmeur dat een goed idee vond (zoals een "Documents" of "Downloads" map).

Linux voorbeeld
Als je in /home/ik/ het programma /bin/cat start, geldt:

/bin/ is de program directory
/home/ik/ is de CWD

Door dat laatste werkt `/bin/cat test.txt` (als /home/ik/test.txt bestaat).

En als /bin, zoals gebruikelijk, in het zoekpad staat, werkt ook: `cat test.txt`.

Het zou heel stom zijn als `cat` in de CWD zou zoeken naar configuratiebestanden, DLL's, helpbestanden etcetera. Als je dan `/bin/cat` start, zou dat onvoorspelbare gevolgen kunnen hebben (scenario 1 hierboven).

Wat onverstandig gevonden wordt, om twee redenen, is . (CWD) opnemen in het zoekpad "PATH" (als ik me niet vergis was dit nog wel het geval in de eerste SunOS versies waar ik mee werkte, later hernoemd in Solaris). Want als je deze vooraan het zoekpad zet:

a) Als er ook een kwaadaardig programma `/home/ik/cat' bestaat, dan zal dat programma worden uitgevoerd als jij, in /home/ik/, uitvoert: `cat test.txt`;

b) Als het correcte programma `/bin/cat` via het zoekpad zoekt naar "hulpbestanden", dan kunnen deze ook in CWD gevonden worden en potentieel kwaadaardig zijn.

Scenario 2 is dat je /bin/cat kopieert naar /home/ik/, start met `./cat test.txt` en dat `cat` in de program directory (niet in CWD - hier toevallig hetzelfde) zoekt naar hulpbestanden. Dat kun je de maker van `cat` nauwelijks verwijten.

Nauwelijks: de makers zouden van elke statische file die zij inlezen een cryptografische hash in het programma kunnen hard-coden en daarop checken bij inladen. Maar bij dynamische files (configuratie- maar ook third party- zoals updated openssl libraries) wordt dat een lastig verhaal. Zie les 2.

Historie
Even graven in mijn geheugen...

Op 2 juni 1998 sloeg Steve Sutton van Trusted Systems Services, in opdracht van de NSA, een bestand genaamd "NSAGuidePlus.pdf" op dat je vanuit deze pagina nog kunt downloaden: https://packetstormsecurity.com/files/12426/NSAGuidePlus.PDF.html.

Onderaan pagina 105 vind je tekst beginnend met:

In 2010 zag Microsoft eindelijk in dat zoeken naar DLL's in CWD tot allerlei risico's leidt, vooral als CWD een netwerkshare (of WEBDAV map) is waar meerdere users schrijfrechten in hebben. Microsoft heeft toen een patch uitgebracht (van ntdll.dll) waarin een nieuw registry name-value paar werd geïntroduceerd: "CWDIllegalInDllSearch". In https://isc.sans.edu/forums/diary/DLL+hijacking+vulnerabilities/9445/ beschrijft Bojan Zdrnja de pachtes maar nog niet die registerwaarde, in de comments daaronder schrijf ik daarover.

Huidige situatie in Windows
In "mijn" Windows 10 bestaat de value-name "CWDIllegalInDllSearch" niet onder de key:
(Let op de spatie tussen "Session" en "Manager").

Ik heb het niet getest, maar ik ga ervan uit dat deze "virtueel" bestaat en de waarde 0xFFFFFFFF heeft. Aanvankelijk leidde die waarde tot zeer veel problemen doordat programmeurs benodigde DLL's in CWD trachtten te vinden (zie de comments onder het Sans artikel uit 2010).

De file ntdll.dll bevat overigens nog steeds de string "CWDIllegalInDllSearch" (in een soort Unicode, tussen elke twee ASCII karakters een nul-byte), zo te zien kun je de default waarde dus overrulen (ik zou deze nooit op 0 willen hebben).

Zelfs in 2019 bestond er, naar verluidt, nog software waarvoor je die waarde wel op nul moest zetten (nooit doen, bel de programmeur): https://forums.veeam.com/veeam-backup-replication-f2/using-cwdillegalindllsearch-causes-issue-possible-fix-t57593.html.

Erger, deze is van 2 juni 2022: https://knowledge.autodesk.com/support/autocad/troubleshooting/caas/sfdcarticles/sfdcarticles/AutoACD-ACA-and-MEP-installation-fails-on-contentpackui-dll.html.

Als CWDIllegalInDllSearch de waarde op 0 heeft, en programma's voor Windows wel in CWD naar o.a. DLL's zoeken (dus niet zelf CWD uitsluiten - tenzij dat toevallig de program directory of een map in PATH is), dan zijn dat onveilige programma's - waar mijn lessen niet tegen werken. Ik heb ook dit niet zelf gecheckt, maar dit lijkt niet de situatie waarin Günter Born de programma's van Nir Sofer heeft getest.

Als ik een keer wat meer tijd heb, zal ik uitzoeken waar Windows mee werkt als CWDIllegalInDllSearch niet bestaat (maar veel zin heb ik niet, ik ben steeds meer Windows-moe).

P.S. Ik heb een stuk over veilig downloaden (Windows) geschreven maar dat werd te lang en is wat off topic. Als daar interesse voor bestaat, en/of voor Windows voorbeelden, wil ik dat wel plaatsen.

Dank aan Erik,

Ik hoop dat velen deze posting van 17:02 u. heden goed op zich willen laten inwerken en de "wormendozen" weten te mijden.

luntrus

Hier de topic-starter.

Erik van Straten, dank voor de uitgebreide uitleg. Ik zal het nog een paar keer moeten lezen.

Ik denk dat een uitleg over veilig downloaden en uitvoeren/bekijken van die bestanden (installer/portable/info-pdf) van iemand met uw kennis wel heel nuttig zal zijn.

CWDIllegalInDLLSearch toch nodig
Microsoft stelt mij opnieuw teleur: als de registernaam "CWDIllegalInDLLSearch" niet bestaat in de registersleutel "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\" (1 spatie tussen Session en Manager) dan kunnen onveilig geprogrammeerde programma's ook in de "Current Working Directory" (CWD) naar DLL's en dergelijke zoeken - namelijk als ze zo'n DLL niet op andere, logische, plaatsen kunnen vinden.

En standaard bestaat "CWDIllegalInDLLSearch" niet in Windows 10. Mijn advies is om deze toe te voegen (type DWORD) met waarde 0xFFFFFFFF, maar zoals ik in mijn vorige bijdrage schreef zijn sommige programma's zo slecht geprogrammeerd dat ze dan niet meer werken.

Nb. na het toevoegen van die value-name of het wijzigen van de waarde ervan, moest ik wel elke keer Windows helemaal opnieuw opstarten om het gewenste effect te krijgen.

Ernstige kwetsbaarheid?
Is het een drama dat CWDIllegalInDLLSearch niet bestaat en onveilig geprogrammeerde programma's tot DLL hijacking kunnen leiden? Niet als je netjes werkt, geen domme dingen doet, en in Verkenner (Explorer) "hidden" en "system files" zichtbaar maakt evenals bestandsextensies (of een programma zoals Total Commander gebruikt waarin je dat doet). Zie ook onderaan deze post.

Is dit een vulnerability in de ogen van Microsoft? Nee, omdat zij er waarschijnlijk vanuit gaat dat je in de eerste plaats moet voorkómen dat je kwaadaardige uitvoerbare code op je schijf zet.

Is het een risico? Ja, want je kunt misleid worden, vooral als je een rommeltje van je systeem maakt (uitvoerbare bestanden in jouw mappen, d.w.z. waar je schrijfrechten hebt, laat staan).

Eén van de redenen daarvoor is dat als een programma DLL's laadt, Windows niet kijkt of het "Mark of the Web" (MotW, zie https://security.nl/posting/647385) gezet is op die DLL's (voor zover MotW überhaupt een betrouwbaar systeem is). Je krijgt dus nooit een waarschuwing als een DLL, gedownload vanaf internet, zo'n MotW heeft en door een programma geladen en uitgevoerd wordt.

Echter, zoals ik verderop laat zien, "CWDIllegalInDLLSearch=0xFFFFFFFF" voorkomt niet al dit soort problemen.

Alternatieve uitleg (Windows)
Misschien helpt een iets andere uitleg.


Stel je de volgende situatie voor:
• Jouw Windows gebruikersnaam is Henk;

• Er staat geen Word op jouw systeem, of je hebt hersteld dat *.RTF files in WordPad openen;
(effectief in "C:\Windows\System32\Write.exe", maar die start door met "C:\Program Files (x86)\Windows NT\Accessories\wordpad.exe" - althans onder Windows 10; of dit in W11 nog zo is, weet ik niet)

• De volgende bestanden bestaan (eventueel naast een hoop andere meuk):
waarbij "mapi32.dll" malware bevat.

1) CWD: als je op die "leesme.rtf" dubbelklikt en write.exe of wordpad.exe zou mapi32.dll laden en code daarin uitvoeren, dan is sprake van DLL hijacking. In mijn W10 wordt die mapi32.dll niet geladen, ongeacht of CWDIllegalInDLLSearch de waarde 0xFFFFFFFF heeft, of 0, of niet bestaat. Dus Write en Wordpad lijken veilig geprogrammeerd.


Er zijn programma's die wel kwetsbaar zijn voor DLL hijacking, zoals InkScape (ook de laatste versie, met een installer helaas zonder digitale handtekening). Met een oude versie (0.92.4) kon ik dit mooi demonstreren, door c:\test\ te maken, de geïnstalleerde inscape.exe daar naartoe te kopiëren, de map c:\test\work\ te maken en daar alle geïnstalleerde DLL's naartoe te kopiëren. Als ik nu, in c:\test\work\ opstart:
• zonder "CWDIllegalInDLLSearch": Inkscape werkt;
• met "CWDIllegalInDLLSearch=0xFFFFFFFF": foutmelding.

Bij de laatste versie van InkScape is dit lastiger te zien vanwege een andere map-indeling na installatie. In beide gevallen krijg je daarmee foutmeldingen bij zo'n experiment, maar verschillende. Ook kan ik met procmon64 zien dat, zonder "CWDIllegalInDLLSearch", wel degelijk DLL's geladen worden uit CWD (terwijl inkscape.exe uit een andere map is gestart).

Maar nadat je zo'n programma hebt geïnstalleerd, zal deze, normaal gesproken, de benodigde DLL's eerst zoeken en vinden in de "program directory" en submappen daarvan, en daarom daar niet naar zoeken in CWD. Wat wel kan is dat een programma een "optionele" DLL probeert te laden die bijv. t.g.v. een custom install niet op de schijf is terechtgekomen. Zonder CWDIllegalInDLLSearch=0xFFFFFFFF zal dan ook in CWD worden gezocht; een potentieel risico.

2) Program directory / PATH (met "program directory" bedoel ik de map waarin de executable staat). In scenario 1 werd er geen kwaadaardige code uit mapi32.dll uitgevoerd, maar wat gebeurt er als je tevens "write.exe" uit "c:\windows\system32\" kopieert naar "C:\Users\Henk\Downloads\" en die kopie opstart? Het resultaat na kopiëren is:
waarbij "mapi32.dll" nog steeds malware bevat.

Als je in die situatie op het onderste bestand "write.exe" dubbelklikt (met het plan om daarna "leesme.rtf" vanuit wordpad te openen) of vanuit een command prompt in C:\Users\Henk\Downloads\ uitvoert:
dan moet je niet gek opkijken als kwaadaardige code in "mapi32.dll" (of andere DLL's als je die ook in die map zet) wordt uitgevoerd.

Reden: het is verwacht gedrag dat programma's in de map waarin ze zelf staan (de "program directory") zoeken naar DLL's.

Concreet griezelig voorbeeld
Om DLL hijacking uit te kunnen leggen heb ik gisteravond een tijdje met "Proces Monitor" (https://learn.microsoft.com/en-us/sysinternals/downloads/) gezocht naar executables van o.a. Windows met DLL hijacking kwetsbaarheid, en zo meerdere opmerkelijke zaken ontdekt. Van het onderstaande zat ik te dubben of ik het kon publiceren, maar vanochtend heb ik gegoogled (*) naar "workfolders.exe" vulnerability en zag dat anderen dit eerder al hebben gepubliceerd.


Ik ga ervan uit dat Microsoft dit geen kwetsbaarheid vindt, maar het zit er wel tegenaan en laat zien dat je ook met Windows boordmiddelen scenario 1 kunt demonstreren, als volgt.

a) Maak een nieuwe map, bijvoorbeeld C:\1337\

b) Kopieer C:\Windows\System32\calc.exe naar C:\1337\

c) Hernoem (in C:\1337\) calc.exe in control.exe

d) Geef control.exe in C:\1337\ het attribuut hidden (onzichtbaar)

e) Start een command prompt (cmd.exe) en voer uit:
Constateer dat de directory leeg is (niet echt, want control.exe staat er in, te zien met "dir /a"). Sluit het venster nog niet.

Open https://youtu.be/dQw4w9WgXcQ, skip de reclames en voer uit in de command prompt:
Tadaa... calculator start 8-)

What just happened? C:\Windows\System32\WorkFolders.exe kijkt in CWD of control.exe bestaat, en zo ja, start deze. Ik heb geen idee waarom.

Is dit een kwetsbaarheid? Niet meer dan dat je op je desktop een batchfile of snelkoppeling neerzet die je "Veilig.bat" of "KanGeenKwaad.lnk" noemt waarmee "C:\1337\control.exe" wordt gestart. Als iemand (jijzelf, onbedoeld, of iemand anders) dat bestand door een kwaadaardige control.exe heeft vervangen, heb je een probleem als je daarna jouw batchfile of snelkoppeling uitvoert.

Wel is het zo dat "workfolders.exe" met een digitale handtekening (Authenticode) is ondertekend (**) en dus onder een andere naam als "malware" zou kunnen worden gedownload, wellicht om voor minder (ernstige) waarschuwingen te zorgen.
Als test heb ik de neppe control.exe (feitelijk calc.exe) voorzien van een MotW en daarna "Workfolders.exe" gestart. Tot mijn verrassing kwam Windows met een waarschuwing dat control.exe vanaf internet kwam. Dat viel dan weer mee! Maar als iemand control.exe op je schijf kan zetten, bestaat de kans dat daarbij die MotW verwijderd kan worden.

Beste oplossing
Laat nooit "uitvoerbare" potentieel kwaadaardige code slingeren (en zorg dat je ze kunt zien). Let op: zeer veel bestandssoorten moet je als "uitvoerbaar" beschouwen (ook bijv. .chm files, postscript files, drivers, ocx files, hta files, scripts natuurlijk etcetera). Cyberhygiëne dus!

Voor nog meer duidelijkheid kun je ook "SuperHidden" bestandsextensies zichtbaar maken, waaronder .lnk (nadeel is dat je in start menu e.d. ook al die .lnk extensies ziet). Zie https://security.nl/posting/39055, https://www.techguy.org/threads/show-super-hidden-file-extensions.384336/ en https://ss64.com/nt/superhidden.html.

En voor meer (niet alle) zekerheid kun je "CWDIllegalInDLLSearch" aanmaken (DWORD) en op 0xFFFFFFFF zetten (met het risico op niet werkende stomme programma's). Zie ook https://msrc-blog.microsoft.com/2010/08/31/an-update-on-the-dll-preloading-remote-attack-vector/ of zoek op internet naar "CWDIllegalInDLLSearch".

Ik ga proberen daar binnenkort tijd voor vrij te maken.

Quote Erik van Straten
En standaard bestaat "CWDIllegalInDLLSearch" niet in Windows 10. Mijn advies is om deze toe te voegen (type DWORD) met waarde 0xFFFFFFFF, maar zoals ik in mijn vorige bijdrage schreef zijn sommige programma's zo slecht geprogrammeerd dat ze dan niet meer werken.


Naar aanleiding van uw opmerking eens gezocht op "CWDIllegalInDLLSearch", en veel identieke adviezen gevonden. Het is wel heel gek dat MS dat niet uitvoert/regelt.

Ik vond een reg-patch die uw advies heel gemakkelijk uitvoert (dat soort dingen zijn wel heel gevaarlijk!!)

Dank voor uw uitleg en advies.

Nou dat er programma's zijn die dan niet meer werken dat zou kunnen voor hobbysoftware maar in een zakelijke
omgeving waar ik die setting meteen heb aangebracht toen die beschikbaar kwam ben ik nooit tegen een probleem
aangelopen.

Wel tegen dat probleem dat de programmadirectory schrijfbaar moet zijn voor iedereen. En dus zelfs met die setting
een systeem nog kwetsbaar is. Maar dan moet je wel gerichter zoeken als hacker...