Nee, het valt allemaal wel mee. Wat wel een issue is, is de eindeloze Windows bashing.

Dat klopt, het wordt niet voor niks DLL HELL genoemd.

Het probleem begon met de introductie van de 'Registry' waar alle systeem variabelen bewaard zouden worden. Maar omdat er ook een update-scheme noodzakelijk was, werd er toegestaan om relatieve paden te definiëren. Dit i.c.m. de path-variabele maakt het vrij onmogelijk om malicious DLL's te blokkeren. Tenzij elke DLL wordt gescand op een signed-signature, zoals is opgelost in .NET.

"Take OceanLotus/APT32, who at the end of 2019 have been observed to use a legitimate rekeywiz.exe alongside a malicious duser.dll [10, 11]. In this case, the malware embedded the legitimate software and dropped it to disk, adopting the ‘bring your own LOLbin’ approach (another way of achieving the same would have been to copy the legitimate executable from the \system32\ folder, assuming the executable hasn’t been patched yet)."

informatie uit de bron lijkt dat dus tegen te spreken. en laten we het verder op de inhoud houden a.u.b.

en hier een read die ook een voorbeeld geeft:

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

waarom valt het dan wel mee? ik begrijp dat niet. ik begrijp wel de codes die ik op github vinden kan...

Wat ook niet mee helpt is dat MS en Exploit-db deze issues niet meer accepteren / publiceren. Ik geloof dat bij MS wellicht nog acceptatie plaats vind als DLL hijacking voorkomt bij het openen/parsen van een document. Geen idee hoe de .so tegenhanger in moderne Linux distributies / applicaties vatbaar is voor soortgelijke aanvallen.

Een ander ding binnen Windows zijn de unquoted services en soortgelijke "simpele" aanvalsvectors. Het helpt enigzins dat in W10 veel third-party services onder minimale privileges draaien.

Tja, ook een fraaie security-methode: je ogen sluiten en net doen alsof het niet bestaat.

Er is ook al sinds 2010 een oplossing voor: CWDIllegalInDllSearch
https://docs.microsoft.com/en-us/security-updates/SecurityAdvisories/2010/2269637?redirectedfrom=MSDN
Nadeel is dat sommige legacy hiermee niet overweg kan en dus je applicaties kunnen omvallen.

Ik heb deze registry key eigenlijk aangepast bij geen enkele klant. De durven het risico niet aan, en er vinden maar weinig aanvallen mee.

Het is dus een geaccepteerd risico, maar wel een risico.

'C://windows /system32" (met de extra spatie != CWD. check de VB script van originele post eens uit.

Wat is dat nou weer voor onzin, het is helemaal geen risico! Systemen die door die registry key omvallen in productie
(en niet in test) dat kom je niet tegen en dat ene hobbyprogramma wat er een probleem mee heeft dat moet je door
de leverancier laten aanpassen of anders dumpen.

Ik heb de betreffende blogpost geschreven, goed om te zien dat het ook hier een discussie heeft aangezwengeld.

Een paar dingen die in dit topic worden besproken:
Er zijn verschillende vormen van DLL hijacking; de variant die in de blogpost wordt besproken is de 'zwakste' variant. Je kunt ~300 ondertekende Windows-executables willekeurige code laten uitvoeren, maar de voorwaarde is wel dat je deze executables naar een speciale map (buiten system32) kopieert. Hiermee kun je doorgaans geen privilege escalation of persistentie bereiken, maar wel 'execution'. Waarom een kwaadaardige DLL via een vertrouwde .exe uitvoeren beter is dan een kwaadaardige .exe uitvoeren, is dat sommige AV-software dit mogelijk minder snel oppikt, en met name in bedrijfsomgevingen beperkingen (zoals bijv. AppLocker) zou kunnen omzeilen.

De reden dat dit niet is 'opgelost' is dat het een hardnekkig probleem is dat redelijk diep in het DLL-model is ingebakken. By design laden veel .EXEs hun DLLs van hun huidige pad in, en voor verschillende redenen (backwards compatibility / performance / legacy tools / etc.) wordt vaak de legitimiteit van die DLLs niet gecheckt. Microsoft zou overigens anno 2020 wel iets meer z'n best kunnen doen om DLLs te checken, naar mijn bescheiden mening.

De beschreven truc in het tweede deel van de post betreft UAC-omzeiling, wat lijkt op (maar niet hetzelfde is als) privilege escalation. Als je Windows 10 in een niet-bedrijfsomgeving hebt geinstalleerd, dus bijvoorbeeld thuis, is het account wat je gebruikt meestal ook meteen het administrator account. Als een .exe iets wil doen waar extra privileges voor nodig zijn, krijg je normaal gesproken het UAC-scherm dat vraagt om bevestiging. Hoewel soms irritant, voorkomt dit Windows XP-achtige toestanden waarin ieder proces kan doen en laten wat het wil. Een kwaadaardige macro kan bijvoorbeeld niet zomaar allerlei systeembestanden of registersleutels aanpassen zonder dat jij (=de administrator) dit expliciet toelaat.
De truc in de blogpost laat zien dat als de uitvoerende gebruiker tevens administrator is, je UAC kunt omzeilen, en alsnog extra privileges kan krijgen. Voor malware betekent dit dat je zonder interactie van de gebruiker je bijna alles op een systeem kunt veranderen, zolang je de gebruiker maar zover krijgt jouw initiele code uit te voeren (bijvoorbeeld via een kwaadaardige macro).
In bedrijfsomgevingen is dit doorgaans beter opgezet, en is de uitvoerende gebruiker meestal niet automatisch ook administrator. Dit betekent dat je een ander account (met administratorprivileges) die UAC-toestemming moet geven. Om deze reden is het dus geen privilege escalation: als je een 'gewone' gebruiker bent, kun je niet opeens administrator worden.

Hoe kun je dit voorkomen? Ten eerste raad ik aan UAC-beveiliging op het hoogste niveau te zetten, wat deze specifieke truc voorkomt. Ten tweede is het altijd raadzaam (ook op je thuiscomputer) om niet standaard alles vanaf een administratoraccount uit te voeren.

Kijk eens naar de presentatie van xoreaxeaxeax (blackhat 2018). Privilege-escalation mogelijk via de CPU.

@Wietze

maar je hebt minstens 35 geschikte c://windows/system32 binaries gevonden op std win 10 die je kunt gebruiken (desnoods direct kopieren) in een c://windows /system32 directory en matchen met een .DLL van jezelf (dat is wat je VB script doet) die bijv een cmd.exe opstarten (zoals je laat zien in screenshots op je blog), maar net zo goed malware kunnen droppen. het is dus kinderlijk eenvoudig op de huis tuin en keuken win10 dit te doen. van wat ik zo zie kan dat dus ook vanuit een excel / word macro dan gebeuren? als dat zo is, dan hoeft er maar een geprepareerde excel sheet gestuurd te worden naar een windows beheerder (denk UM even) die het niet zo nauw neemt en std administrator is. klopt dat?

Dat is juist, als je dit dus doortrekt kunnen de potentiele gevolgen groot zijn.
Microsoft redeneert echter dat in jouw voorbeeld de 'echte' fouten die begaan worden, zijn (1) het downloaden/openen van de kwaadaardige bijlage; (2) het activeren van de macro; (3) het gebruiken van een adminstratoraccount hiervoor. Zie ook https://docs.microsoft.com/en-us/archive/blogs/e7/update-on-uac . Het lijkt erop dat UAC door hen wordt beschouwd als een extra beschermingslaag die ellende kan voorkomen, maar niet per se 100% waterdicht is.

geen persoonlijke kritiek, maar ik vind de gestelde microsoft redenering iets te gemakkelijk dan:

1) maar dus tegelijkertijd, voor de thuisgebruiker, die std dus administrator is en per ongeluk ooit eens die macros aangezet heeft toen die een documentje eens kreeg, die is eigenlijk 'het bokje' dus?

2a) als we allemaal wisten welke documenten of mails nu wel of niet verdacht waren van te voren, tja dan ...

2b) de UM IT dienst is niet een uitzonderlijke rare IT dienst (vergeleken bij bedrijven en scholen bijv) en daar werd dat toch wel weer gedaan, dan beheerders std administrator zijn en natuurlijk ook wel eens excel sheets openen...

Het fundamentele probleem is dus dan toch eerder dat DLL hijacking nog steeds vrij eenvoudig is uit te voeren bij MS gedistribueerde binaries in system32.

Beide gelijk. Soms wordt MS net even te makkelijk door de wringer gehaald, maar je moet voor de (onderbouwde) zaken zeker niet de ogen sluiten. MS is zeker niet ideaal maar Linux heeft met de desktop zeker ook zijn tekortkomingen (vele gelukkig te ondervangen). Alhoewel ik prima met Linux uit de voeten kan, heeft de MS omgeving wel degelijk een aantal goede softwarepakketten waar Linux omgevingen niet aan kunnen tippen. Andersom ook, maar veel minder.

Een stabiel en veilig OS bouwen is niet gemakkelijk. Bij het ontwerp wordt je soms ingehaald door zaken die per ongeluk niet afgedekt zijn, of nooit aan gedacht. Het corrigeren is dan een monsterklus. Maar dit had dus wel kunnen gebeuren met de overgang naar W10. Of zou dit een te grote impact hebben op de backwardscompability ? Denk het wel.

Tja en dan de security, in de praktijk is het niet alleen hindernissen opwerpen voor ongenode gasten, maar regelmatig ook voor jezelf. Door deze gaten, wordt alles steeds complexer met het pleisterwerk en configuratie. Bijna tot op het niveau dat het niet meer leuk is.

Dat moet deze zijn:
https://i.blackhat.com/us-18/Thu-August-9/us-18-Domas-God-Mode-Unlocked-Hardware-Backdoors-In-x86-CPUs.pdf

In een woord: indrukwekkend. Dit is zeer de moeite waard om eens door te nemen, ook als je lang niet alles wat er gebeurt precies kan volgen. Dit is een heel fraaie beschrijving van hoe met intelligent detective-werk in combinatie met gerichte brute kracht-tests een heel kleine speld in een reusachtige hooiberg gevonden wordt.