/dev/null - Overig

DLL-hijacking, detektie, tegenmaatregelen?

22-09-2022, 13:56 door Anoniem, 13 reacties
DLL-files zijn algemene hulpfiles, die door programmas aangeroepen kunnen worden.

Recent kwam ik op internet een uitleg tegen over crimineel hacken, waarbij IT-criminelen pogen de legitieme DLL-files te vervangen door aangepaste DLL-files.
Om later de echte hack te kunnen uitvoeren.

Dit kan vooral doordat de programmeurs van legitieme software niet goed programmeren waar de DLL-files opgehaald moeten worden. Als dit wel goed geprogrammeerd wordt in een software-programma, kan via dat programma geen hack uitgevoerd worden.
Het barst klaarblijkelijk van legitieme/goed-bedoelde software die die dll-gevoeligheid hebben.
Ook Linux_OS heeft van dit soort hulp-files, en is dus gevoelig voor dit soort IT-criminaliteit.

Als dit zo erg is als ik op internet lees, is elke PC, met wat voor OS dan ook, voorzien van korrupte hulp-files. En hebben hackers altijd toegang tot elke PC.
MS negeert meldingen over dit probleem in hun eigen OS-software.
Ook brillante makers (eenlingen) van specifiek software (o.a. hulpprogrammas) maken dit soort hijack-dll fouten, en lossen dit bij terugmelding niet op.

Er is wel een test-programma, SPYDLL, dat de gevoeligheid van een programma kan resten. Dit programma werkt echter alleen op 32-bit programmas. En je moet SPYDLL naar het programma verwijzen waar je een vermoeden van hebt. Dus een scan van je PC, zoals met een virus-scanner, doet ie niet. Met andere woorden, je vind een gekorrumpeerde situatie niet zomaar.

Weet iemand of er een efficient detektie-programma is voor dll-hijacking? En wat mogelijke preventie is?
Reacties (13)
22-09-2022, 18:03 door Anoniem
Door Anoniem: DLL-files zijn algemene hulpfiles, die door programmas aangeroepen kunnen worden.

Recent kwam ik op internet een uitleg tegen over crimineel hacken, waarbij IT-criminelen pogen de legitieme DLL-files te vervangen door aangepaste DLL-files.
Om later de echte hack te kunnen uitvoeren.

Dit kan vooral doordat de programmeurs van legitieme software niet goed programmeren waar de DLL-files opgehaald moeten worden. Als dit wel goed geprogrammeerd wordt in een software-programma, kan via dat programma geen hack uitgevoerd worden.
Het barst klaarblijkelijk van legitieme/goed-bedoelde software die die dll-gevoeligheid hebben.
Ook Linux_OS heeft van dit soort hulp-files, en is dus gevoelig voor dit soort IT-criminaliteit.

Als dit zo erg is als ik op internet lees, is elke PC, met wat voor OS dan ook, voorzien van korrupte hulp-files. En hebben hackers altijd toegang tot elke PC.
MS negeert meldingen over dit probleem in hun eigen OS-software.
Ook brillante makers (eenlingen) van specifiek software (o.a. hulpprogrammas) maken dit soort hijack-dll fouten, en lossen dit bij terugmelding niet op.

Er is wel een test-programma, SPYDLL, dat de gevoeligheid van een programma kan resten. Dit programma werkt echter alleen op 32-bit programmas. En je moet SPYDLL naar het programma verwijzen waar je een vermoeden van hebt. Dus een scan van je PC, zoals met een virus-scanner, doet ie niet. Met andere woorden, je vind een gekorrumpeerde situatie niet zomaar.

Weet iemand of er een efficient detektie-programma is voor dll-hijacking? En wat mogelijke preventie is?
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
23-09-2022, 11:46 door Anoniem
Door Anoniem: Als dit zo erg is als ik op internet lees, is elke PC, met wat voor OS dan ook, voorzien van korrupte hulp-files. En hebben hackers altijd toegang tot elke PC.
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.
23-09-2022, 16:47 door Anoniem
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.
23-09-2022, 22:26 door Anoniem
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)?
24-09-2022, 13:37 door Anoniem
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/
24-09-2022, 22:51 door Anoniem
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.
28-09-2022, 01:23 door Anoniem
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
28-09-2022, 17:02 door Erik van Straten
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).

Les 1 (een noodzakelijke voorwaarde voor de volgende lessen): Patch (ook) privilige escalation kwetsbaarheden ASAP en werk zoveel mogelijk als ordinary user (niet als root of als lid van de Administrators groep: UAC is schijnveiligheid).

Les 2: Start nooit een programma in een map waarin bestanden (kunnen) staan die daar eerder en/of onbedoeld zijn gedownload, of daar door anderen kunnen zijn achtergelaten (netwerkschijf), of die daar door kwaadaardige software of via een security-bug kunnen zijn geplaatst (bekend als "binary planting"). Nb. het kan hierbij ook gaan om niet kwaadaardige DLL's doch met een bekende kwetsbaarheid.

Daaruit volgt les 3: Zorg ervoor dat alle uitvoerbare programma's, DLL's en degelijke uitsluitend in mappen staan waarin geen enkele ordinary user schrijfrechten heeft (Microsoft zondigt hiertegen met o.a. onedrive.exe). Andersom: laat verkenner "systeembestanden" tonen en zorg ervoor dat er nooit DLL's e.d. in mappen staan waar ordinary users (non-admins) "werken" en dus schrijfrechten hebben.

En les 4: Zorg ervoor dat programma's nooit in CWD naar hulpbestanden (DLL's e.d.) zoeken (tenzij dat toevallig dezelfde map is als de program directory en er dáárom in die map wordt gezocht; als je je aan de andere lessen houdt, hoort dat geen probleem te zijn).

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
LET OP: dit is niet bedoeld om een discussie uit te lokken waarom Linux op dit punt (of in het algemeen) beter zou zijn dan Windows!
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:
DLL Spoofing
The DLL spoof is one of the most insidious spoofs in Windows NT.
[...]
The problematic case is when the algorithm checks the Working Directory for the DLL file.

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:
HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\
(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.
28-09-2022, 17:14 door Anoniem
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
29-09-2022, 01:59 door Anoniem
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.
30-09-2022, 12:31 door Erik van Straten
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)
Door Anoniem: Erik van Straten, dank voor de uitgebreide uitleg. Ik zal het nog een paar keer moeten lezen.
Misschien helpt een iets andere uitleg.

Nb. ik schrijf achter directories en registry keys zoveel mogelijk een \ om verwarring met bestanden en name/value paren te voorkómen. Het is m.i. een blunder dat die er niet altijd achter staat (en dat geldt ook voor de / in Linux e.d.). Helaas slikken veel programma's zo'n trailing backslash (Linux: slash) niet.

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):
C:\Users\Henk\Downloads\leesme.rtf
C:\Users\Henk\Downloads\mapi32.dll
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.

Terzijde, voor de nerds onder ons: met procmon64 zag ik dat wordpad.exe wel degelijk checkt of mapi32.dll bestaat in CWD (ook met "CWDIllegalInDLLSearch = 0xFFFFFFFF" - als een stomme programmeur het wil kan deze gewoon code laden uit CWD). Als die file bestaat dan worden daar de file-attributes van opgevraagd - maar er wordt niets uit de file zelf gelezen (en er wordt niet naar andere DLL's dan mapi32.dll gekeken). Als je in Wordpad vervolgens op menu "File -> Send in email" klikt, wordt mapi32.dll geladen uit C:\Windows\SysWOW64\ en/of uit C:\Windows\System32\. Zo te zien nog steeds safe, maar wel opmerkelijk.

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:
..\inkscape
• 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:
C:\Users\Henk\Downloads\leesme.rtf
C:\Users\Henk\Downloads\mapi32.dll
C:\Users\Henk\Downloads\write.exe
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:
C:\Users\Henk\Downloads > write leesme.rtf
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.

(*) Off topic: voor het eerst van mijn leven zag ik reclame op de frontpage van google.com: "New! Meet the latest Fitbit smartwatches". Ik ben niet tegen reclame, maar dit viel mij wel op.

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:
C:\Windows\System32 > cd \1337
C:\1337 > dir
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:
C:\1337 > workfolders
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.
(**) De meeste Windows files hebben (lekker verwarrend) een detached (losgekoppelde) elders opgeslagen Authenticode signature. Met bijv. de commandline tool "sigcheck.exe" van Sysinternals (zie boven) kun je die signature checken.
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".

Door Anoniem: 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.
Ik ga proberen daar binnenkort tijd voor vrij te maken.
30-09-2022, 13:37 door Anoniem
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.
30-09-2022, 15:12 door Anoniem
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...
Reageren
Ondersteunde bbcodes
Bold: [b]bold text[/b]
Italic: [i]italic text[/i]
Underline: [u]underlined text[/u]
Quote: [quote]quoted text[/quote]
URL: [url]https://www.security.nl[/url]
Config: [config]config text[/config]
Code: [code]code text[/code]

Je bent niet en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.