Windows bevat acht jaar oude kwetsbaarheid, Microsoft werkt nog niet aan patch

Windows bevat al acht jaar een kwetsbaarheid die actief misbruikt wordt. Dat hebben beveiligingsonderzoekers van Trend Micro ontdekt. Microsoft heeft echter nog geen oplossing gemaakt en geeft daaraan ook niet direct prioriteit.

De kwetsbaarheid in kwestie laat aanvallers verborgen malafide commando's uitvoeren op machines van slachtoffers, schrijft Trend Zero Day Initiative op zijn blog. Concreet worden hiervoor .lnk-shortcutbestanden gebruikt, die lijken te verwijzen naar legitieme bestanden. In werkelijkheid bevatten ze extra instructies om malware te downloaden of uit te voeren. Normaal gesproken zou zoiets zichtbaar zijn, maar Noord-Koreaanse aanvallers hebben volgens Trend Micro megabytes aan witte ruimte toegevoegd aan de command-line arguments. Daardoor is de aanval niet zichtbaar voor gebruikers.

Vermoedelijk wordt de aanval al sinds 2017 gebruikt. De onderzoekers hebben naar eigen zeggen krap duizend malafide .lnk-bestanden gevonden, maar vermoeden dat er nog veel meer in het wild rondzwerven. De onderzoekers zeggen verder dat zeker elf door staten gesponsorde groeperingen de kwetsbaarheid misbruikt hebben. Hun doelwitten bestaan uit organisaties in branches als overheid, financiële dienstverlening, telecommunicatie, defensie en de energiesector in Noord-Amerika, Europa, Azië, Zuid-Amerika en Australië.

Trend Micro heeft Microsoft in september 2024 op de hoogte gesteld van het probleem. "Microsoft heeft de ernst als laag geclassificeerd en gaat dit niet in de nabije toekomst patchen." Dat is voor het bedrijf reden geweest om het probleem publiekelijk te delen. Volgens de onderzoekers vormt de kwetsbaarheid 'een significant risico voor de vertrouwelijkheid, integriteit en beschikbaarheid van data die beheerd worden door overheden, kritieke infrastructuren en private organisaties wereldwijd'.

Microsoft bevestigt tegenover The Register dat de kwetsbaarheid gemeld is. Daar noemt het bedrijf het een gebruikersinterfaceprobleem. "Hoewel de UI-ervaring in het rapport volgens onze richtlijnen voor ernstclassificatie niet voldoet aan onze criteria om direct opgepakt te worden, zullen we overwegen om dit in een toekomstige featurerelease aan te pakken", aldus de woordvoerder. De woordvoerder adviseert gebruikers verder om voorzichtig te zijn met het downloaden van bestanden van onbekende bronnen.

Reacties (90)

[cooLopke]

Ik heb zelf inderdaad al gedownloade bestanden bij diverse gebruikers gezien met zulke shortcut bestanden die 1GB groot zijn, waardoor het lijkt alsof het een volwaardig bestand is. Dat zou dan een gedownloade film moeten zijn, maar dat is dan een shortcut (snelkoppeling). Als je bij de eigenschappen van het .ink bestand gaat kijken zie je achter de shortcut (snelkoppeling) programmacode (script) staan in plaats van de gebruikelijke locatie van het bestand bv. C:\users\documents\film.mp4

[Reactie gewijzigd door cooLopke op 20 maart 2025 10:22]

[Raven]

Dat klinkt bekend, vroeg me al af wat dat de laatste tijd toch was, films waarvan de bestanden qua grootte kloppen, maar een shortcut extensie.hebben. ESET Smart Security Premium werd niet getriggerd overigens.

[BUR]

Ik snap niet dat standaard de extensies van bestanden uit staan in Windows verkenner. Dan zie je minder makkelijk wat voor bestand het is. Met als gevolg dat een bestand met deze hack aangelikt wordt?

[cyspoz]

Een .lnk van megabytes zou ook wel verdacht moeten zijn. Normaal maar bytes tot maximaal een kilobyte groot.

[b12e]

In een paar kilobyte kan je anders ook al wel het een en ander verstoppen.

Ik vermoed dat de witruimte niet hard gecodeerd in de .lnk bestanden zitten (en dus effectief megabytes ruimte in beslag nemen), maar eerder met een programmatisch trucje (while (true) ) witruimte toevoegen.

En of je .lnk nu 1 of 5 kilobyte groot is, dat gaat geen argwaan wekken.

[Reptile209]

Ik denk dat die bak met witruimte juist bedoeld is om de echte code te verstoppen voor het oog. De parser van de .lnk slaat het over, maar een gebruiker die de link bekijkt ziet niets. Dus (met _ als witruimte):

run explorer.exe /formatharddrive
run explorer.exe __________________________________________________ /formatharddrive

Bij de tweede is - in een beperkt boxje of mouseover waarin je de link target staat - een stuk moeilijker om de 'malicious' code te zien.

[R4gnax]

Het is nog een tikkie erger dan dat. De carriage return en line feed karakters zijn ook valide witruimte in de COMMAND_LINE_PARAMETERS payload van een .lnk file.

Maar omdat de UI enkel een single-line textbox is, wordt de weergegeven waarde in dat veld op dat moment afgekapt bij de eerste new line. Hierdoor kun je, zelfs als je CTRL+A select all oid zou gebruiken niet de volle waarde v/h veld te zien krijgen.

MS zou dit heel eenvoudig op kunnen lossen door Windows aan te passen en de shortcut editor UI directer aan te laten sluiten op de daadwerkelijke data structuur van een .lnk file. Maak er twee velden van: een simpele single-line textbox voor de target executable (waar voor het handige ook een file picker aan gekoppeld kan worden) en een multi-line textarea voor de extra argumenten.

[Reactie gewijzigd door R4gnax op 20 maart 2025 12:10]

[naaitsab]

Dat is de GUI patchen. Dat gaat natuurlijk niet werken tegen A mensen die blind van alles openen (lees het merendeel van de gebruikers) en B mensen die "via de achterkant" bestanden modificeren.

Mijn inziens is een betere fix om de file interpreter van Windows dusdanig aan te passen dat deze de juiste invoer validatie uitvoert. Dan komt dat los te staan van wat er in het bestand staat c.q. mee gerommeld is. Combinatie van deze optie en wat je aanhaalt is uiteraard de mooiste manier. Ook zou een AV elk LNK-bestand die meer dan een paar KB is al direct als verdacht moeten flaggen. Dat is namelijk onmogelijk tenzij er padding is toegevoegd om het bestand kunstmatig te vergroten.

[Robtimus]

Het ligt eraan hoe je aan de .lnk file komt. Over het algemeen worden die niet handmatig gedownload maar via een installer geplaatst. Maar als dat het geval is dan is de installer zelf natuurlijk al onveilig, waarom zou je dan nog een .lnk file gebruiken voor de aanval?

Dan blijft inderdaad over dat de .lnk file direct gedownload wordt (of per email binnenkomt). Dan ben je wat mij betreft al niet slim bezig.

[Mastermind]

Hmm ik vind het wel fijn om te weten dat virusscanners dit nog niet detecteren. Je moet natuurlijk nooit malafide installers draaien, maar sommige mensen installeren bijvoorbeeld NoSteam games omdat ze het spel ook offline willen kunnen spelen. Daar wordt vaak een link op het bureaublad geplaatst die inderdaad dan malafide zou kunnen zijn.

[R4gnax]

Hmm ik vind het wel fijn om te weten dat virusscanners dit nog niet detecteren. Je moet natuurlijk nooit malafide installers draaien, maar sommige mensen installeren bijvoorbeeld NoSteam games omdat ze het spel ook offline willen kunnen spelen. Daar wordt vaak een link op het bureaublad geplaatst die inderdaad dan malafide zou kunnen zijn.

Als die gepirate versies voorzien zijn van daadwerkelijke installers, dan is het veel makkelijker om daar de malafide payload in te steken dan in een .lnk file.

Een geinfecteerde .lnk is eigenlijk alleen relevant in situaties waar je zo'n ding via email toegestuurd krijgt of op andere wijze direct naar je systeem downloadt. En in die gevallen ben je in principe al beschermd doordat er een 'mark of the web' aan toegevoegd is dat schreeuwt dat je heel, heel erg zeker van je zaak moet zijn om dit file uit te voeren, aangezien je het van het internet gedownload hebt.

[Mastermind]

Wat ik bedoel is dat in installers virusscanners wel vaak trojans of virussen kunnen detecteren. Een manier om dit te omzeilen is dus een malafide .lnk file maken.

[jspsrsnws]

Wauw, off topic, maar wat gaaf die vlieg in/op je avatar.

[StackMySwitchUp]

Je kunt ook een lnk file genereren, met een slim scriptje kun je dan die whitespaces toevoegen. Waarschijnlijk is zo'n file in een zipje superklein, dus dat is ook nog een mogelijkheid

[R4gnax]

Het enige wat zo'n .lnk file toestaat is code uit te voeren met de lokale gebruikersrechten.
Als je, om dat .lnk file te genereren een script wilt draaien, dan zal dat script draaien met ...?
Juist: de lokale gebruikersrechten.

Dus waarom dan nog een .lnk file aanmaken?

[jeroen79]

Als je de gebruiker er op laat klikken heb je al iets draaien op de PC.
Met gewone gebruikersrechten kun je bijvoorbeeld al iets downloaden via internet.
Bijvoorbeeld iets dat een andere exploit gebruikt om adminrechten te krijgen.

Vaak is de gebruiker ook local admin.
Op bijvoorbeeld privé PC's is er vaak geen apart admin account, dat is maar moeilijk.
Als je dan iets met admin rechten wil doen dan hoef je alleen nog maar de gebruiker te verleiden om in de UAC op 'ja' te klikken.

[R4gnax]

Als je de gebruiker er op laat klikken heb je al iets draaien op de PC.

Als je een script wilt laten draaien om de .lnk on-the-fly aan te laten maken waar de gebruiker op zou moeten gaan klikken, dan heb je dus al de mogelijkheid om iets te laten draaien met de lokale gebruikersrechten...

[87Dave]

Het ligt eraan hoe je aan de .lnk file komt. Over het algemeen worden die niet handmatig gedownload maar via een installer geplaatst.

Men kan bijrvoorbeeld een gezipt iets doorsturen/laten downloaden. Dan uitgepakt is er de lnk met link naar wat men verwacht met bedenkelijke instructies erbij. Met daarnaast een folder met hetgeen wat men verwachte.

In die folder kunnen dan perfect legitieme files of programma's zitten. Zelfs digitaal ondertekende exe's door vertrouwde bedrijven zoals MS zelf zodat er niets als verdacht opvalt. Je kan zelfs via argumenten die vertrouwde executable dingen laten doen. En de gebruiker ook nog laten toestaan het als administrator te doen, want ze gaan in het venster zien dat die door een vertrouwde partij ondertekent is en dus het probleem niet zien.

De meeste gebruikers gaan het nooit doorhebben.

[Alfa1970]

Waarom zou een malafide persoon of org zoveel extra moeite doen?
Als ze de gebruiker al dusdanig ver hebben dat die een zip download en een executable in die zip uitpakt en installeert, dan is de truck via de .lnk volledig overbodig. De malafide code is immers al op het systeem, en is er geen noodzaak meer om andere trucks toe te passen om de malware uitgevoerd te krijgen want de gebruiker heeft de installer gebruikt.
Voor mensen die nog steeds vertrouwen hebben in een anti-virus oplossing: Word wakker.
Malware producenten lopen rondjes om de a/v leveranciers. Het moet al iets super obvious zijn voordat een a/v leverancier het opmerkt, als het beperkt wordt ingezet dan is de kans dat een a/v leverancier het vind klein tot niet bestaand al naar gelang de impact van de malware en de zichtbaarheid ervan.
Ik bedoel, Trend Micro heeft een redelijk goede research afdeling die veel dingen heel snel vinden, maar zelfs zij hebben er dus 8 jaar over gedaan om dit probleem te vinden.
A/v is leuk, het werkt voor dingen die al bekend zijn, en zelfs dan in zeer beperkte mate, want regelmatig worden pattern bestanden opgeschoond en patronen voor malware verwijderd om de impact van de a/v oplossing op het systeem te verminderen tot een aanvaardbare impact. A/v leveranciers vertellen over het algemeen welke patterns verwijdert worden. Koud kunstje voor een malware maker om juist opnieuw zo'n oude truck uit de doos te halen voor hergebruik.

[Mastermind]

Omdat de manier met vele spaties en daarachter programmacode kennelijk niet gedetecteerd wordt door virusscanners, en malafide code in een .exe wel. Windows Defender verwijdert zo'n bestand (bijvoorbeeld een crack) meestal direct.

[Alfa1970]

Als de zip op het systeem staat is de code er al, en heeft de a/v het niet gedetecteerd.
En dat is op zich enorm simpel.
Want virusscanners zijn ingesteld om slechts een klein deel van een bestand te scannen omdat het anders te veel tijd en resources kost. Geen enkele virusscanner scant elk bestand compleet.
Daarom werkt de truck met spaties, maar dat werkt ook met gewone executable bestanden.
McAfee a/v scanners bijvoorbeeld scannen alleen de eerste megabyte van een bestand.
Als je malafide code start op 1 MB + 1 byte, dan zal de scanner het niet eens bekijken.
Andere merken hebben andere waardes, maar allemaal hebben ze deze eigenschap.

[Kastermaster]

Klopt. Maar zeg nu zelf, hoeveel gebruikers letten daarop?

[cyspoz]

De gemiddelde gebruiker niet inderdaad, maar voor Proxies en andere beveiliging tools zou het eenvoudig te blokken moeten zijn.

[scribly3]

Wellicht de mensen die de tijd nemen om de contents van die .lnk te bekijken. Want deze bug treft alleen hen

[kozue]

De standaard instelling van Windows is om bestandsextensies te verbergen. Die gebruikers weten dus helemaal niet eens dat het om een .lnk bestand gaat. Het ding heet film.mp4.lnk en in explorer ziet het er uit als film.mp4. Dat verbergen van extensies heb ik altijd al een groot security probleem gevonden en MS heeft er nooit wat aan gedaan. Ze vinden het belangrijker om bestandsnamen er iets minder technisch uit te laten zien, of iets dergelijks…

[R4gnax]

De standaard instelling van Windows is om bestandsextensies te verbergen. Die gebruikers weten dus helemaal niet eens dat het om een .lnk bestand gaat.

PEBKAC.
.lnk bestanden hebben - buiten weergave in het startmenu - altijd een badge in de onderhoek over het icoon liggen met een pijltje er in. Dat zijn gebruikers die niet geinstrueerd zijn om te begrijpen wat dat pijltje betekent.

[GeroldM]

Mijn standaard instelling als ik met Explorer moet werken is: 'Details'. Geen pijltje zichtbaar in het zeer kleine icoontje van die 'view'.

Waarom 'Details'? Omdat elke andere view me meteen kribbig maakt. Dus maak ik veel liever gebruik van een echt bestandsbeheer programma (Directory Opus) in 'double pane'-stand en de 'details' view in die software.

Toont niet alleen meer details dan Explorer, geeft meteen aan wat het type van het bestand is, ook al is dt in Explorer uitgeschakeld. En is ook ingesteld om het aantal bytes te tonen, niet afgerond naar Kb, Mb of Gb.

Dan valt elke file met onverwachte bestandsgroote juist sneller door op. Maakt het ook makkelijk om te zien of iets met een bestand is uitgehaald. Heb je een bepaalde file op meerdere plaatsen in je computer staan, allemaal met hetzelfde versue nummer, maar er is er eentje die groter/kleiner is dan de rest...dan is dat al meteen verdacht. Zulke ongein zie je niet eens met afgeronde bestandsgrootte weergave, want een bestand van 24 kb kun je een bestand tussen 23.800 bytes en 25.500 bytes verwachten. Hoe groter het bestand, des te groter de afwijking met afrondingen.

Microsoft's keuze om standaard geen extensies weer te geven, is een hele slechte keuze. Zou zelfs zo ver willen gaan dat je daardoor Microsoft niet als serieuze bouwer van besturingsystemen zou mogen beschouwen. En dan gooien ze daar bovenop ook nog eens de idioterie van nogal slechte weergave van afgeronde bestandsgroottes.

Maar ja, gebruikers zijn al zo vaak door Microsoft in hun knieholte getrapt en daarna in het gezicht gespuugt, dat ze die 2 zeer verkeerde keuzes van Microsoft maar zijn gaan accepteren. Wat er weer voor zorgde dat Microsoft zich alsmaar arroganter en schaamtelozer begon te gedragen en we daardoor 'reclame-zuil' Windows 11 door de strot geduwd hebben gekregen.

Zo had ik ooit een hagelnieuwe laptop (Lenovo Ideapad 3) met W11 S editie erop aangeschaft. Bij de 1e opstart kwam er een keuzescherm om de S editie om te zetten naar W11 Home edite. Dat meteen gedaan. na 2 jaar blijft het ding klagen dat het niet up-to-date meer is. Ga ik kijken in de Windows Update settings, staat er met grote letters dat Windows up-to-date is. En direct daaronder, in normale tekst, dat Windows belangrijke Windows updates mist. Wat is het nou?

Dus een maand terug een W11 Pro licentie aangeschaft. Wou ook een nieuwe drive kopen om daar dan W11 Pro op te zetten. 'Leven gebeurde' en kwam er dus niets van. Dus die licentie maar gebruikt om mijn huidige W11 Home om te zetten naar W11 Pro. Al maanden niets meer geinstalleerd op dit ding, Windows in de gebruikelijke 'wel-niet' update status.

Na activatie is W11 Home inderdaad naar W11 Pro omgezet. De volgende morgen was de machine geherstart, en het draaide de 24H2 kernel, had CoPilot en was nu dus wel degelijk geheel geupdated. Waarom was het onmogelijk om W11 Home teupdaten, terwijl het voor W11 Pro een fluitje van een cent was?

Is dat het eerste kenmerk dat aangeeft dat Microsoft zich nu ook als "class-ist" is gaan gedragen?

Nee, na het uitbrengen van W11 heeft Microsoft zich niet meer van een goede kant laten zien.

[R4gnax]

Mijn standaard instelling als ik met Explorer moet werken is: 'Details'. Geen pijltje zichtbaar in het zeer kleine icoontje van die 'view'.

Ik krijg hier in Explorer (Win 10) gewoon nog overlay pijltjes over .lnk files in 'details' modus hoor.
Dat zou dan iets zijn wat Microsoft oliedom in Windows 11 aangepast zou hebben.

[Reactie gewijzigd door R4gnax op 21 maart 2025 20:12]

[Bux666]

Als je de extensies niet laat zien, zou film.mp4 dus niet moeten kunnen (want zonder extensie is het film) en kan je dus weten dat er een 2e extensie achter zit die wel verborgen is.

[kozue]

Dat weet ik, maar de doorsnee gebruiker valt dat echt niet op. Die heeft het bestand al met extensie ergens op een website of een email zien staan en “weet” dat ie filmp.mp4 heet. Dus bij zo’n extensie gaan er geen alarmbellen meer af, ondanks dat andere bestanden in de map geen extensies laten zien.
Voor jou en mij is het makkelijker te onderscheiden, maar dat maakt het nog niet minder een designfout.

[Qwerty-273]

De witruimte is ook maar beperkt nodig, het is voldoende om de hexcodes van een nieuwe regel toe te voegen aan het lnk-bestand volgens het artikel van Trend Micro. Dat is al genoeg om iets toe te voegen dat je niet meer via de GUI van Windows kan zien (als je naar de eigenschappen van de snelkoppeling kijkt). Dat je vervolgens een grote lap code daar kan plaatsen, dat kan wel aantikken.

Het wordt uitgevoerd onder de rechten van de gebruiker, dus als je meer fancy dingen wilt doen zal je daar eerst nog wat privileged escalation moeten toepassen. Het is natuurlijk wel voldoende om iets te downloaden en/of te uploaden in een hele basis setting.

[Bender]

Standaard laat Windows geen bestandsextensies zien (welke ik altijd weer aanzet), dus de normale gebruiker weet niet wat voor extensie het is.

[Die_ene_gast]

Juist, ga dat maar aan Gerrie van HR uitleggen, veel succes.

[R4gnax]

Als Gerrie van HR dat niet kan begrijpen, dan mag Gerrie van HR van de wet (GDPR/AVG) niet met persoonsgegevens werken. En is Gerrie niet meer van HR.

(En sorry hoor; maar competent HR-personeel is niet dom. Ze moeten heel veel kennis hebben van allerlei bedrijfsprocessen en vooral: nuances in wetgeving zoals dat op hun vakgebied van toepassing is.)

[Reactie gewijzigd door R4gnax op 20 maart 2025 12:21]

[lariekoek]

Vind het knap gevonden...
Zit zelf al lang in tech en had nooit bedacht dat ze een complexe file structuur hadden voor een dergelijk eenvoudige toepassing.
https://learn.microsoft.c...be-452a-8101-b9a2ec49978c

Naar de spec, de zin en onzin ervan, sanity checken en bekijken is blijkbaar toch nodig, al vind microsoft van niet.
Je zou in ieder geval denken dat een virusscanner ze wel kan monitoren als anderzijds 'binary file'.

Denk dat dit meer mensen verrast en overal tussendoor geglipt is voor lange tijd.

[Reactie gewijzigd door lariekoek op 20 maart 2025 12:56]

[The Zep Man]

De woordvoerder adviseert gebruikers verder om voorzichtig te zijn met het downloaden van bestanden van onbekende bronnen.

Wat het zakelijke risico verder verkleint is dat het enkel .lnk bestanden betreft. Er is geen reden om die te delen, dus die kan je gewoon aan de poort (op servers waar zichtbaar en op beheerde endpoints uit onbetrouwbare bronnen) blokkeren.

Je zou ook een script kunnen delen dat de eerste drie lijnen iets legitiem doet en pas vanaf lijn 5001 iets naars doet. Een gewone gebruiker zou dat ook niet snel opmerken, want wie controleert nu een script of .lnk-bestand?

[Die_ene_gast]

Tjah, je kan ook zeggen dat je nooit meer hoeft te updaten als je een computer nooit meer aanzet.
Is dat de oplossing voor veiligheidsproblemen?

In mijn voorbeeld nemen we even aan dat die management cores ook niet bestaan.

[RobIII]

Ik vind dit eigenlijk wel een gevalletje It rather involved being on the other side of this airtight hatchway
Er zijn talloze manieren om iets te verstoppen, dat maakt het niet meteen iets dat op stel en sprong gepatched moet worden. Ook wil ik dit niet direct een kwetsbaarheid noemen. Het is (soort van) gewenst gedrag*, slim ge(mis)bruikt. Maar je moet als aanvaller dus eerst al een snelkoppeling bij die gebruiker zien te krijgen en die gebruiker dan óók nog eens overhalen die snelkoppeling te klikken. Dat kan met andere bestanden ook / net zo goed.

* In de zin dat witruimte is toegstaan als commandline argument.

[Reactie gewijzigd door RobIII op 20 maart 2025 10:00]

[The Zep Man]

Niet helemaal mee eens:

Not every code injection bug is a security hole.

Het voorkomen van code-injectie is één laag van beveiliging. Het voorkomen van privilege escalation is een andere laag van beveiliging. Een goede beveiliging kent meerdere lagen. Een doorbroken laag is zeker een probleem, want andere lagen zijn (ook) niet perfect. Waar nu geen kwetsbaarheid is voor een tweede laag zal die er morgen wel zijn. Hou er ook rekening mee dat niet alle kwetsbaarheden bekend zijn. Je kan dus niet stellen dat een mogelijkheid tot code-injectie geen beveiligingsprobleem is zonder te stellen dat binnen andere relevante beveiligingslagen geen kwetsbaarheden aanwezig zijn.

Verder gaat het aangehaalde stukje over een gebruiker in een omgeving die inderdaad eigen code kan/mag uitvoeren ("the easy way"). Dit gaat niet over een buitenstaander die specifieke code wil uitvoeren op een platform waar die zelf geen toegang tot heeft.

Wel ben ik het eens met dat dit niet iets is dat met hoge prioriteit opgelost hoeft te worden door Microsoft. Dit kan ook op tussenservers (blokkeer .lnk-bestanden) en op beheerde endpoints (blokkeer .lnk-bestanden uit onbetrouwbare bronnen) opgelost worden. Qua dat zijn .lnk-bestanden vergelijkbaar met scripts, waarbij je vaak iets soortgelijks wilt doen.

[Reactie gewijzigd door The Zep Man op 20 maart 2025 11:04]

[kozue]

Dit is wel degelijk een kwetsbaarheid. Er lijkt me geen legitieme reden te zijn om code in een bestandstype te hebben dat bedoeld is als shortcut naar een ander bestand. Ik werk al zo’n 20 jaar niet meer met Windows, maar van wat ik me herinner is dit de MS tegenhanger van de symlink onder *nix gebaseerde OS’en. Code daarin uit kunnen voeren is dus wel degelijk een security probleem en gelijk aan code uitvoeren die verstopt is in andere non-code bestandstypes zoals plaatjes of audio.

[RobIII]

Het gaat hier om commandline arguments als: "/foo/bar/baz.exe <10.000 spaties>; format c: /q /y" zoals ik het lees. Daarbij is een snelknoppeling niet echt een symlink. Windows kent 't concept symlink ook. Een snelkoppeling is een bestand met metadata dat verwijst naar een ander bestand of map en een symlink is een verwijzing op bestandssysteemniveau waardoor een bestand of map op een andere locatie lijkt te bestaan en gedraagt zich net als het originele bestand of de originele map.

[aikebah]

Windows kent tegenwoordig de symlink ook, maar .lnk is wel degelijk van oudsher de tegenhanger op windows voor een symlink die windows ook nog altijd gebruikt bij het aanmaken van een alternatieve koppeling naar een locatie in de verkenner ('snelkoppeling maken') waarbij je command-line moet gaan leren om een symlink zelf aan te gaan leggen.

[RobIII]

"Tegenwoordig" sinds 2007/Vista ja

Verder is er een wezenlijk verschil tussen symlinks en snelkoppelingen. Een applicatie zal niet doorhebben dat iets een symlink is (tenzij er specifiek naar gekeken wordt) waarbij een snelkoppeling een "gewoon" bestand is en een applicatie zal een snelkoppeling niet volgen (tenzij er specifiek naar gekeken wordt).

Dat Microsoft nooit de moeite heeft genomen om een UI te maken om symlink functionaliteit te ontsluiten in explorer is een ander verhaal.

[Reactie gewijzigd door RobIII op 21 maart 2025 12:22]

[Commendatore]

Oneens. De meeste reguliere gebruikers zullen zich hier niet goed tegen kunnen verdedigen, omdat dit enige kennis over de werking van zo’n .lnk vereist. Daarnaast is er geen enkele goede reden waarom dit in een .lnk-bestand toegelaten zou moeten zijn. (Het zou ten allen tijde transparant moeten zijn wat zo’n bestand doet, iets dat waarschijnlijk ook niet zo moeilijk te realiseren is.)

Vanuit technisch perspectief is er misschien geen probleem, maar als je de menselijke factor erbij betrekt, dan is dat er wel.

[pieterdevries]

Ik zie deze .lnk bestanden vaak bij het downloaden van Linux ISO's. Ze hebben dan de normale naam met extra extensie er achter, Fedora41.iso.lnk bijvoorbeeld, aangezien standaard bestandsextensies niet worden weergegeven in Windows. Dus als iemand dan zo'n foute file download en probeert te openen, dan word de code uitgevoerd.

[SunnieNL]

Waar haal jij dan die linux iso's vandaan??
Want als je ze bij de standaard download plek haalt (de website van de distri) dan krijg je toch niet zulke bestanden?

[pieterdevries]

Ik heb het over de spreekwoordelijke Linux ISO's, van het soort dat je via programma's als Sonarr en dergelijke binnen haalt ;-)

[Stephanus]

Dit zou toch heel goed te detecteren moeten zijn door malware scanners. Trend Micro geeft aan dan hun tools het doen. Iemand getest hoe dit voor andere tools is, zoals standaard Defender?

[chaozz]

Exact mijn gedachte. De 'fix' voor Microsoft is dan ervoor zorgen dat Windows Defender dit ook detecteert.

[Z80]

In NT4 was een .lnk file al te misbruiken. En alle virusscanners pakken de .lnk file standaard al mee.
Niets nieuws onder de zon. Alleen wil MS er niet aan om dit "probleem" aan te pakken.

[SprockerJock]

Ik meen mij te herinneren dat dit gemeld was na Stuxnet. I know I know, dat was een ander lnk exploit. Maar toen werd er ook gemeld dat je gewoon je code in de lnk zelf kan zetten. Dat is al 14 jaar geleden.

[amigob2]

Je moet dus wel al toegang hebben tot de PC om dit te kunnen doen.
Is dat misschien de reden dat Microsoft niet zo een haast maakt

[Seal64]

Nou ja, niet helemaal natuurlijk. Je kunt ook een gebruiker verleiden om dat bestand te downloaden en uit te voeren, wat helemaal niet zo moeilijk is aangezien de gemiddelde gebruiker gewoon overal op klikt en alles gelooft. Hoeveel van die data security nieuwsbrieven, e-learnings en workshops worden er jaarlijks gegeven die er allemaal op rammen dat je geen bestanden in verdachte mailtjes moet openen? Maar het gebeurt dagelijks.

Maar uiteindelijk is dat inderdaad wel een vector die je gewoon niet dichtgetimmerd gaat krijgen, no matter what you do. Je kunt allicht wel scannen op .lnk bestanden van meer als een kB, maar gegarandeerd dat je dan binnen een paar dagen iemand te pakken heeft die een legitieme reden heeft om zulke grote bestanden te hebben die dan weer gaat mopperen.

[Verwijderd]

Nou ja, niet helemaal natuurlijk. Je kunt ook een gebruiker verleiden om dat bestand te downloaden en uit te voeren, wat helemaal niet zo moeilijk is aangezien de gemiddelde gebruiker gewoon overal op klikt en alles gelooft.

Dat klopt maar daar is ook geen kruid tegen gewassen. Als ze je gewoon een .exe bestand sturen en laten uitvoeren dan is ook alle security op je machine voor jan met de korte achternaam.
De gemiddelde leek is nog altijd de zwakste schakel in de security chain.
Overigens is dat ook de reden dat user account control niet werkt. Iedereen die geen tweaker is klikt toch gewoon altijd op toestaan. Ik zet dat altijd uit op alle machines die ik onderhoud want het is alleen irritant maar lost niets op.

[downtime]

Maar in elk normaal bedrijf zullen .exe bestanden in een email al geblokkeerd zijn en heb je je gebruikers al geleerd om geen .exe bestanden van het internet te downloaden. Bovendien kun je het uitvoeren van "vreemde" .exe bestanden sowieso blokkeren en zal elke browser ervoor waarschuwen en elke virusscanner erop aanslaan. Het risico is nu juist dat malafide partijen nu een nieuwe manier hebben gevonden om al die beveiligingen toch te omzeilen.

[Seal64]

Klopt, en dan kom je ook een beetje in het gebied van "if you think you've idiot-proofed everything, the universe comes up with a better idiot". Wij hebben testmails gehad vanuit corporate die overduidelijk phishingmails moesten voorstellen, waar medewerkers niet alleen op de overduidelijk neppe link klikten, maar vervolgens ook nog het complete contactformulier erachter hadden ingevuld. En we hebben halfjaarlijks van dat soort e-learnings, dus die werken niet. Mensen klikken toch wel, hoeveel waarschuwingen je er ook op zet.

Dat zal ook gelijk de reden zijn waarom MS zich hier niet zo druk om maakt - PEBCAC fouten zijn niet te voorkomen.

[TheVivaldi]

Dat is zeker waar. Het enige wat ik me in dit geval kan voorstellen, is dat MS een manier verzint om de manier waarop .lnk-bestanden worden gemaakt te veranderen, zodat het voor virusscanners makkelijker wordt om malafide bestanden te onderscheppen. Maar dat zal wel aardig wat werk vereisen.

[R4gnax]

Maar in elk normaal bedrijf zullen .exe bestanden in een email al geblokkeerd zijn.

In elk normaal bedrijf zullen .lnk bestanden in een email ook al geblokkeerd zijn.
Want die hebben ook geen enkele legitieme bedrijfs-toepassing waarin niet al via een URL te voorzien is.

[Reactie gewijzigd door R4gnax op 20 maart 2025 12:24]

[Verwijderd]

Maar in elk normaal bedrijf zullen .exe bestanden in een email al geblokkeerd zijn en heb je je gebruikers al geleerd om geen .exe bestanden van het internet te downloaden.

In bedrijven wel maar bij je grootmoeder niet

[Die_ene_gast]

Met dat argument kan je wel je virusscanner verwijderen. Gewoon je gebruikers vertellen dat ze niets meer mogen doen op de apparaten.

[SunnieNL]

Stop hem in een op dit moment zeer gewenste film in de torrent... Geef het de naam van de film.
Of in een torrent van software en noem het install.lnk
Stuur hem op in een zipfile
Neem de .lnk op in een Word document of PDF

zoveel mogelijkheden om hem op een pc te krijgen zonder zelf fysiek toegang te hebben.

[amigob2]

dat kun je ook met een exxecutable

[SunnieNL]

Maar die vallen wel sneller op, zowel door de mens als door een virusscanner.
Die laatste laat .lnk bestanden vaak links liggen zodat de gebruiker niet te veel last heeft van vertragingen.

[youridv1]

witte ruimte

Zeg gewoon white space. Dan weten mensen wel wat je bedoelt.

Anders zijn het ook commandoregelargumenten

[Reactie gewijzigd door youridv1 op 20 maart 2025 09:46]

[Oon]

De correcte Nederlandse term is 'witruimte', daar is geen Engels term voor nodig. In principe is die term ook van toepassing op ruimte tussen tekst.

[Reactie gewijzigd door Oon op 20 maart 2025 09:47]

[Marctraider]

Jij bent zeker ook van de geüpgratet, geüpdatet en gedatet?

[mati1983]

Waar helemaal niets mis mee is, want dat schrijf je in het Nederlands nu eenmaal zo. Behalve geüpgraded, want dat bevat geen 't'. Dat de helft van de hedendaagse samenleving te lui is om het te leren of na te kijken bij gebruik, is een ander verhaal.

[CPV]

Dat de helft van de hedendaagse samenleving te lui is om

Nou, het is al niet makkelijk of logisch en als het ook nog elke paar jaar verandert, haakt men snel af.

[TheVivaldi]

Dat is waar, maar dat is met Engelstalige woorden net zo. Voorbeeld: in het begin hadden we het over ‘sociale media’, maar dat werd gaandeweg ‘social media’ en binnen niet al te lange tijd werd dat alweer verkort tot het huidige woord ‘socials’. En dat is dan nog iets wat vanuit de mensen zelf is gekomen. Wat ook niet meehelpt is dat grote bedrijven als Google voortdurend de terminologie veranderen, óók in de Engelse taal.

Het woord waar het hierboven om begon, ‘witruimte’, bestaat al (bij wijze van spreken dan) sinds mensenheugenis en is nog nooit veranderd. (Sommige mensen zijn thans de Engelstalige term gaan gebruiken, maar de Nederlandstalige term is altijd hetzelfde gebleven.)

[Reactie gewijzigd door TheVivaldi op 20 maart 2025 11:22]

[lenwar]

Historisch gezien komt er iedere 10 jaar een bijgewerkte versie van het Groene Boekje uit. Dit is van de Nederlandse Taalunie. De veranderingen zijn veelal bevestigingen van zaken die het publiek zelf al op een bepaalde manier ging doen, of regels eenduidiger maken en dat soort zaken. (los van of we vinden dat ze dat goed lukt natuurlijk )

Het is in de basis ook niet gek om taal aan te passen, natuurlijk. Immers faciliteert taal communicatie en niet andersom. Het gebruik van leenwoorden ziet er vaak een beetje gek uit, wanneer je daar Nederlandse taalregels op gaat toepassen. Maar als je eerlijk bent.
Waarom zou je wel de meervoudsvorm met Nederlandse regels doen, maar niet het (on)voltooid deelwoord? Dat is toch eigenlijk gek als je er zo naar kijkt?

(Dus wel upgraden, maar niet geüpgraded)

[mati1983]

Dat valt allebei echt wel mee. Ook verandert 'het' ook niet elke paar jaar. Fatsoenlijk Nederlands spreken en schrijven is deels niets meer of minder dan een keuze. Wanneer je bij het schrijven tegen een werkwoord aanloopt waarvan je niet zeker weet hoe je het vervoegt, is dat in 20 seconden te googelen, waarna de meesten het gewoon zouden moeten kunnen onthouden.

(mooi voorbeeld overigens: zowel googlen als googelen blijkt juist)

[CPV]

Ik bedoel voornamelijk de Nederlandse schrijfwijze van Engelse woorden, die is nogal eens gewijzigd.

[The Zep Man]

Jij bent zeker ook van de geüpgratet, geüpdatet en gedatet?

daar is geen Engelse term voor nodig

"Bijgewerkt"

[Pathogen]

Opgewaardeerd

[TheVivaldi]

Er zijn meerdere Nederlandstalige mogelijkheden en ‘bijgewerkt’ is daar eentje van. Het is vooral afhankelijk van de context en voor welk publiek je schrijft (net als met een hoop teksten).

[R4gnax]

Nee; dan zou @Oon van het "opgewaardeerd" en "bijgewerkt" zijn, zou ik denken. Wat de correcte Nederlandse termen zouden zijn ipv de (zeer slecht) uit het Engels geadopteerde neologismen.

[TheVivaldi]

Maar zelf schrijf je deze reactie wel in het Nederlands?

[Die_ene_gast]

Ik hoopte dat het sarcasme er wel vanaf droop.

[InfiniteSpaze]

Witte ruimte betekent precies hetzelfde... Je comment voegt niet echt iets toe.

Bedankt voor de update Evelien, interessant artikel.

[SuperDre]

En dan gebruik je zelf ook ineens engels.

[InfiniteSpaze]

Sharp

[bantoo]

Als je denkt dat het significant beter is op een ander besturingssysteem wil ik ook een ticket naar de fantasie wereld waar die bestaan.

[TheVivaldi]

Ook als Linux-gebruiker ben ik het met je eens. Sterker nog: ik vermoed dat dit op Linux ook gewoon zou kunnen, daar je - net als op Windows - opdrachtregelargumenten kunt toevoegen aan .desktop-bestanden. Het enige verschil zal zijn dat het wat meer opvalt als je ineens je wachtwoord moet invoeren, om de malafide code in /usr of een andere systeemmap geplaatst te krijgen. Maar ook in de persoonlijke map van de gebruiker valt mogelijk wel wat te halen en daar heb je geen sudo voor nodig.

[mjansen2016]

Maar Idem ondervangt het UAC dit, tenzij jij een local admin bent of het programma met elevated rights runt. Dit zal dan in bedrijfsomgeving wat minder een probleem vormen als bij thuisgebruikers.

[TheVivaldi]

Ik richtte me inderdaad voornamelijk op thuisgebruikers, maar je hebt gelijk dat het in bedrijfsomgevingen ook kan voorkomen. Het verschil lijkt me echter dat UAC iets is dat mensen sneller zullen accepteren om ervan af te zijn dan als er ineens om een wachtwoord wordt gevraagd. Ik kan dat niet met een studie onderbouwen, dus dit is puur een aanname mijnerzijds. Ik vermoed namelijk dat een wachtwoordvraag iets meer vraagtekens oproept dan een UAC-schermpje.

Desalniettemin zullen er vast mensen zijn die dan alsnog klakkeloos hun wachtwoord invoeren, dus 100% waterdicht is het zeker niet.

[Blokker_1999]

Zelfs een local admin moet op Windows door UAC, met als belangrijkste verschil dat je geen wachtwoord moet ingeven. Als je natuurlijk zo hard Microsoft en UAC haat dat je het uitzet, moet je natuurlijk niet komen klagen dat Windows je niet komt waarschuwen.

Dat neemt natuurlijk niet weg dat je dit niet zou kunnen combineren met andere kwetsbaarheden om zo via privilege escalation alsnog met verhoogde rechten iets uit te voeren of gewoon vanuit userspace je ding te doen waar je ook al veel kunt misdoen.

[R4gnax]

Zelfs een local admin moet op Windows door UAC

Nee. Dat moet je alleen als die local admin account opgezet is als een token-split account.
De ingebouwde 'Administrator' account (die standaard uitstaat en voor recovery-doeleinden bedoeld is) is vziw nog steeds een voorbeeld van een admin-account die niet token-split is; altijd admin rechten heeft; en niet door UAC token-acquirement / elevation heen hoeft.

[Reactie gewijzigd door R4gnax op 20 maart 2025 15:49]

[LadyGiga]

En dat blijft maar duren die incompetentie ;-(