Onderzoekers omzeilen Windows Defender-scan via eigen smb-server

Beveiligingsbedrijf CyberArk heeft een aanval gepubliceerd onder de naam Illusion Gap. Door een eigen smb-server op te zetten en een doelwit een gehost bestand te laten openen, is een scan door Windows Defender te omzeilen. Microsoft ziet dit niet als een beveiligingsprobleem.

CyberArk meldt dat de methode werkt doordat Windows Defender zelf een exemplaar van het bestand bij de smb-server ophaalt. Door een aangepaste smb-server te gebruiken, is het mogelijk om de kwaadaardige versie van het bestand aan de loader van Windows door te spelen en de schone versie aan Defender te leveren zodra het doelwit het bestand opent. De smb-server kan namelijk via een filter onderscheid maken tussen de twee verzoeken, schrijven de onderzoekers. Op die manier wordt de kwaadaardige versie uitgevoerd en vindt geen detectie plaats.

Een aanvaller moet daardoor een dergelijke smb-server op kunnen zetten om van de methode gebruik te kunnen maken. De onderzoekers zeggen dat misschien ook andere antivirusproducten vatbaar zijn voor deze aanval, maar leveren hiervoor geen bewijs. Ze meldden hun bevindingen aan Microsoft, dat reageerde met de mededeling: "Op basis van de melding vereist een succesvolle aanval dat een gebruiker content uitvoert vanaf een niet vertrouwde smb-share op een aangepaste server die zijn gedrag kan aanpassen op basis van toegangspatronen. Dit lijkt geen beveiligingsprobleem, maar een feature request, die is doorgezet naar de engineeringafdeling."

Tegenover The Register geeft het bedrijf een uitgebreidere uitleg, waarbij het zegt dat de aanval 'beperkt praktisch inzetbaar is'. Als de aanvaller het doelwit eenmaal zover heeft gekregen om alle stappen uit te voeren, zou Windows Defender verdere vervolgacties detecteren, aldus Microsoft. Bovendien zou Windows verschillende waarschuwingen tonen. CyberArk zegt dat de techniek werkt op Windows 10 en 8.1, en dat zij interessant is voor geavanceerde aanvallers.

Werking van de smb-server volgens CyberArk

Reacties (64)

[BlackEyedAngel]

Ik vind het altijd maar een beetje vreemd om zo publiekelijk neer te zetten hoe het werkt

[RJG-223]

Als dat niet gebeurt, dan lossen bedrijven security problemen helemaal niet meer op, of pas op het moment dat het uitkomt, wat best maanden of jaren later kan zijn. Bedrijven hebben namelijk helemaal geen belang erbij om problemen op te lossen waar niemand, of slechts weinig mensen aantoonbaar last van hebben. Zeker als ze kunnen ontkennen dat ze het wisten. Oplossen kost namelijk geld, en het levert niets op. Als dit soort zaken gepubliceerd wordt, dan lijdt een bedrijf schade als ze een probleem niet oplossen, en dus levert het geld op als ze het wel oplossen. Dan is er dus een businesscase.

Hetzelfde geldt voor IT-afdelingen van bedrijven. Die zullen slechts budget krijgen om security-problemen te monitoren en updates uit te voeren als dat economisch zinvol is. Publicatie van problemen en meldplicht / publicatieplicht van inbraken en data-diefstallen maakt het aantoonbaar economisch zinvol.

Goed gebruik is, om een probleem eerst bij de software-bouwer te melden, en pas later (een of twee maanden, meen ik) te publiceren. Dan is er genoeg tijd om een update uit te brengen, en er is genoeg tijd voor IT-afdelingen om die te installeren. Als software-bouwers en IT-afdelingen laks zijn, is dat dan hun eigen probleem. Net zoals het jouw eigen probleem is als je geen goed slot op jouw huisdeur hebt, en geen anti-inbraakstrips etc.

Overigens: publicatie is inderdaad niet in het belang van een individueel bedrijf, software-bouwer of gebruiker. Het is wél in het belang van de maatschappij als geheel.

[bogy]

het probleem is anders wel simpel op te lossen...

stel defender zo in dat het de lokale, gescande kopie uit zijn cache haalt en die doorspeelt de windows exec-runner om te openen ipv het een tweede keer te downloaden.
Ik vond het altijd al zo vreemd dat hetzelfde bestand twee keer moet gedownload worden, dat is toch totaal inefficient. (ik heb hier nogal een grote file-server draaien, bv als ik nieuwe drivers voor de gpu afhaal komen die rechtstreeks daar op; als ik ze dan opende (vroeger toch) dan zag ik altijd dat die twee keer werden gedownload van de fileserver (een tooltje als netmeter maakt dat snel duidelijk). Zeker bij tragere wifi verbindingen (54g) merk je dat heel goed, en het verzadigd bovendien snel zo'n netwerk als je met velen tegelijk een paar bestanden van de fileserver haalt. De pc's zijn gelukkig allemaal via gigabit verbonden met het netwerk. Aangezien alles op de fileserver gescand wordt hebben mijn clients al een tijdje geen AV meer draaien (zelfs Defender is volledig uitgeschakeld). Illegale dingen worden hier niet gedownload op het netwerk en de pfsense-box blokkeert alle gekende malicious sites via filtering.

[RJG-223]

het probleem is anders wel simpel op te lossen

Voor elk probleem bestaat er een oplossing die elegant is, efficiënt, eenvoudig, en fout.

Ik weet niet of jouw oplossing dat is, maar als zo een probleem simpel op te lossen lijkt, dan is de meest waarschijnlijke verklaring dat die oplossing verkeerd is.

In dit geval neem ik aan dat Windows executables met paging inlaadt. Dat betekent dat alleen de delen die nodig zijn ingeladen worden, en enkel op het moment dat ze nodig zijn. En het kan zelfs ook gebeuren dat delen van de code tijdelijk uit het geheugen verwijderd worden, om (wellicht uren) later opnieuw ingeladen te worden. Ook bij dit opnieuw inladen zou de server alsnog gehackte code kunnen sturen. En de Windows-kernel code die dit alles doet, is waarschijnlijk voor een deel heel verschillend van de code die gebruikt wordt bij het gewoon lezen van een bestand. Al met al niet zo eenvoudig als je zou denken.

De (vermoedelijk) enige manier op dit werkelijk op te lossen is om bij het uitvoeren eerst een lokale kopie te maken van de hele executable, en het exemplaar van het netwerk daarna niet meer te gebruiken.En de vraag is of dat zo makkelijk te implementeren is. En dan mag je hopen dat je niet een diskless client hebt...

[Mythio]

Tja, ze werken in ieder geval met responsible disclosure. Eerst melden en wachten op een reactie, daarna pas publiek maken. Vaak is publiek maken een extra incentive voor bedrijven om met een oplossing te komen EN voor andere bedrijven om na te denken of hun software ook niet vatbaar is voor zo een aanval.

[latka]

Het protocol van een pinlezer is ook te vinden en de documentatie van de sloten van nemef is ook niet geheim. Voordeel van kennisdeling is dat het kan leiden tot verbeteringen. Als je erop blijft zitten zal een enkeling het uitvogelen en misbruiken en het vooral niet melden zodat jij nog steeds veilig denkt te zijn terwijl links en rechts de hackers je voorbij komen.
Kennisdelen = goed.

[DeZwarteLijst]

Je moet eens proberen om bij een softwarebedrijf een bug te laten fixen.
Vaak stoot je gewoon op mensen die je ofwel niet beantwoorden, ofwel de ernst van de situatie wegwuiven.

Ben nu sinds 2 maanden in communicatie met een redelijk groot bedrijf in VOIP Technologie owv een bug die ik heb gevonden.

Ze blijven je gewoon steeds met een kluitje het riet in sturen omdat ze niet de tijd, noch de resources hebben of krijgen om dit soort zaken aan te pakken.
Achwat je kan het root-wachtwoord van onze telefoons zo onderscheppen?

Daarom wordt je als researcher vaak gewoon gedwongen om te publiceren.
Als dat gebeurt komt er nl. plots wel heel wat aandacht voor aangezien dit voor slechte PR zorgt, wat een totale no-go is voor het management.

Security is niet belangrijk, je moet ze raken waar het pijn doet als ze niet willen meewerken, en dat is de PR.

(Dit klinkt misschien heel zwart/wit en/of gemeen, maar er zitten zoveel gaten in alles wat overal wordt uitgerold dat dit echt een noodzaak is)

[terror538]

Het komt mij als compleet idioot over om er maar op te vertrouwen dat het bestand wat je de 2e keer uitleest hetzelfde is als wat uitgevoerd wordt.

Is het niet veel logischer om een scan uit te voeren op wat er in het geheugen ingeladen is voordat het uitgevoerd wordt?!?

-edit- En of als dat niet handig is wellicht een hash vergelijken van het ingeladen bestand met het bestand op schijf, komt de hash niet overeen dan is er geknoeid.

[Reactie gewijzigd door terror538 op 23 juli 2024 08:22]

[.oisyn]

Is het niet veel logischer om een scan uit te voeren op wat er in het geheugen ingeladen is voordat het uitgevoerd wordt?!?

Niet echt. Een executable wordt namelijk helemaal niet volledig ingeladen als hij wordt uitgevoerd. Sterker nog, het deel dat wordt ingeladen is minimaal - de volledige PE header en allerlei tables (section table, IAT, etc) worden ingeladen om te achterhalen welke sections er zijn en welke DLL's er nog meer moeten worden ingeladen. Delen van de executable worden vervolgens gememorymapped. Het opvragen van data of het uitvoeren van code dat nog niet is ingeladen resulteert in een page fault, waarna de kernel de betreffende pages uit de executable vist.

Een virusscanner kan daar op zich weinig mee, die wil gewoon het hele bestand scannen. En dus leest hij, apart van de PE loader, de volledige executable. Dat is doorgaans helemaal geen probleem, want de file is gelockt en dus zal hij niet veranderen. Maar dan vertrouw je natuurlijk wel op het betreffende device dat de data aanlevert. Ik gok dat deze exploit niet gelimiteerd is tot SMB, maar dat je hetzelfde trucje ook kunt toepassen op een speciaal geprepareerde USB stick en zelfs harddisk. Al kan file caching wel roet in het eten gooien - eerlijk gezegd snap ik niet waarom dat hier niet al het geval is.

[Reactie gewijzigd door .oisyn op 23 juli 2024 08:22]

[kdekker]

Dat hangt er vanaf. Als een executable langer in het geheugen zit, kan Windows besluiten deze uit te pagen. Is die exe weer nodig, dan wordt er weer ingepaged, maar netwerk file systemen kunnen te traag zijn, waardoor je page errors krijgt. Je kunt met het maken van een exe (door de ontwikkelaar dus) of achteraf (met toolstjes) de /SWAPRUN optie aanzetten. Op die manier gaat de binary eerst het geheugen in.

Maar goed: de SMB server zelf zal toch ook wel een virusscanner hebben (als dit een intern systeem is). Dat een hacker dat nu niet doet, maar toch de server in het netwerk kon hangen is ook al vreemd.

De negatieve kant van 'op elk systeem in een bedrijfsnetwerk staat een virusscanner' dat nagenoeg alles 2x gescanned wordt. Ik heb zelf net een nieuwe PC (met SSD, 16GB memory), maar bij een lekker groot visual studio project compileren gaan 10-tallen procenten van je CPU op aan de virusscanner. En ik heb al tijden allerlei problemen met sluiten van (file en registry handles) waar het lijkt dat de virusscanner (file filter) voor vertragingen c.q. random errors zorgt (meestal bij zware belasting). De virusscanner is voor ontwikkelaars soms net zo erg als een virus. Helaas. Efficiency en virusscanners, dat is nogal een beetje tegenstrijdig. En openheid van wat ze nu precies scannen (+ configureerbaarheid daarvan) is nu net niet wat ze hebben.

[CrazyBernie]

Daarom hebben wij voor ontwikkelaars de virus scanner uit staan in de workspaces want vooral bij onze web projecten was het gewoon hel.

[psykic]

En deze computers hangen dan aan het netwerk of apart netwerk zonder internet toegang ?

Want anders gaan die computers wel wat huisdieren hebben.

[real[B]art]

Mwoah, me dunkt dat je gewoon de build folder uitsluit in de virusscanner. Ik ga er van uit dat dat ook is wat @CrazyBernie bedoelde eigenlijk.

[CrazyBernie]

Bart ik bedoelde de hele workspace dir want je wilt ook alle project files uitsluiten niet alleen de build folder. Want vooral de performance van intellisense kan bij grote projecten rampzalig zijn met virus scanner aan.

Ik kon soms op mijn xeon met 32gb en dubbele ssds nog steeds gewoon niet lekker typen. Met de scanner aan dan

Alle andere dirs natuurlijk niet.

[Wim-Bart]

Dan heb je hele andere issues dan de virus scanner wanneer dit invloed heeft op het typen. Meer verkeerde drivers voor MB en IO.

[CrazyBernie]

Wim Bart het type probleem was er alleen in visuel studio met code lens actief. Alle andere applicaties had ik deze problemen niet.

[Wim-Bart]

Waarom geen exclusions op extensie van source bestanden.

[CrazyBernie]

Omdat je dan ook .DLL en .EXE moet excluden dat lijkt me niet echt handig dan kun je net zo goed de virus scanner uitzetten.

[Wim-Bart]

dll en exe zijn geen source bestanden

[CrazyBernie]

Maar omdat codelens en intellisense reflection gebruiken maken zo op de achtergrond continu eigenlijk dll's en exe's aan zodat ze daarna de standard reflection kunnen gebruiken. Dus ja je moet alle file types exluden voor die dirs niet alleen maar .cs of .html bestanden.

Tenminste bij de projecten die wij draaien.

[Wim-Bart]

Dan is de enige mogelijkheid dus folders excluden inderdaad. Andere kant wel een risico, want hoe voorkom je dat tijdens een build de boel niet geïnfecteerd wordt.

[kdekker]

De virusscanner doet meer dan alleen files scannen. Ook alle netwerkverkeer en registry toegang (wat eigenlijk ook een file is). Ik heb nog steeds raadselachtige errors, die ik niet heb op een systeem zonder virusscanner (daar staat alleen Windows defender).

De build folders moet je zeker uitsluiten, maar ook de build processen en de include paden. Helaas snappen de meeste ITers niet wat een virusscanner precies doet, en heeft ook geen benul hoeveel duizenden en duizenden files tijdens een build geraakt worden (include van windows.h resulteert al in een pre preprocessor output van meer dan 100000 regels. De bron daarvan zijn 10-tallen files, die je voor iedere source hebt). Met 1000-den source files kom je dan op heel grote getallen. De meeste AV producten scannen alles, iedere keer opnieuw, of ze berekenen een checksum, wat effectief net zo veel tijd kost.

[cornedor]

Zou dit niet een grote performance impact hebben? Dat zou namelijk betekenen als je een grote .exe heb waar veel data in zit dat daar eerst uitgebreid een hash van moet worden gemaakt, dit kan wel even duren.

[KirovAir]

Zou dit niet een grote performance impact hebben? Dat zou namelijk betekenen als je een grote .exe heb waar veel data in zit dat daar eerst uitgebreid een hash van moet worden gemaakt, dit kan wel even duren.

Met de huidige systemen zou dat weinig impact hebben. (Niet veel meer als twee keer het bestand inladen, wat nu dus al gebeurd)

Ik vind het zelfs een vrij nette oplossingsrichting om de hash te checken. Probleem is dat Defender los staat van het OS dus deze hash niet zo maar kan communiceren. (Of Defender moet elke NtCreateUserProcess hooken en daar vervolgens een hasing algoritme over loslaten, alleen dit heeft wél weer performance impact en mogelijk breekt het ook bestaande software)

Al met al niet heel eenvoudig op te lossen zonder intrusive te zijn. (Tenzij Microsoft hier zelf een API voor bloot gaat geven.)

[RSpliet]

Tsja, maar waar gehasht wordt vallen collisions. Een hash is nu eenmaal geen waterdichte methode voor het bepalen van equivalentie omdat je data weggooit, dus vroeg of laat zal ook een methode gebaseerd op hashes worden aangevallen als "niet veilig genoeg".

[aadje93]

het duurt wel even voor je een collision gevonden hebt voor een bestand dat je graag uitgevoerd hebt. op een niet al te zuiver SMB server. Dat is dus wel heel erg ver gezocht

[RSpliet]

Nee, dat is niet vergezocht. De aanvaller moet een niet-gedetecteerde executable creëren en aanbieden met dezelfde hash als zijn "geinfecteerde" variant. Met SHA-1 als hashing algoritme is dat praktisch mogelijk dankzij mensen van CWI en Google, waarbij zelfs zonder research de tijd (/hoeveelheid hardware) voor een aanval afneemt naar mate de hardware sneller wordt. Ja 110 GPUs een jaar draaien is een hoop tijd, maar er zijn aanvallers met grotere resources. De vraag is niet hoe veel tijd zo'n aanval vandaag duurt (want MS weet vast wel beter dan SHA-1 vandaag de dag te kiezen), maar hoe lang zo'n aanval zou duren over 10 jaar, en hoeveel gebruikers van zo'n hashing-based SMB beveiligingsmechanisme er tegen die tijd nog over zijn.

[latka]

2x via het netwerk laden is duidelijk trager dan 1x laden en 1x hashen (hash=>1GB/s, laden=100MB/s bij een 1Gb netwerk).

[CurlyMo]

Een simpele gedachte. Je hoeft natuurlijk niet het volledige bestand te hashen. Je kunt ook wat bijvoorbeeld ZFS doet een hash op blocklevel niveau maken. Bijvoorbeeld bij het ophalen van het bestand van de server elke 1MB hashen totdat het hele bestand is ingeladen. Voor 100MB heb je dus 100 hashes. Dan kan je desnoods de 100 hashes hashen om maar één hash over te houden.

[BeosBeing]

-edit- En of als dat niet handig is wellicht een hash vergelijken van het ingeladen bestand met het bestand op schijf, komt de hash niet overeen dan is er geknoeid.

Zoiets deed Thunderbyte antivirus in 1997 (ik weet niet of het echt een hash was of iets soortgelijks/primitievers). Het werd in 1998 opgekocht door Norman ASA, de makers van Norman Antivirus maar of deze functie er daarna nog in zat weet ik niet. TBAV was een van de eerste heuristische scanners in Nederland.

Norman ASA werd in 2012 opgesplitst in Norman Safeground en Norman Shark, waarvan het eerste in 2014 werd opgekocht door AVG

[batjes]

To be successful, an attacker would first need to convince a user to give manual consent to execute an unknown binary from an untrusted remote location.

Niet echt een security flaw, als je een gebruiker zo ver krijgt dat deze rotzooi als administrator gaat uitvoeren, is het bypassen van Defender het minste van je zorgen.

[latka]

Security moet toch in-depth: niet 1 laagje maar op alle lagen? Waarom wordt anders de C: schijf gescand? Die was schoon bij de start en alles wat erop komt wordt gescanned (nooit begrepen waarom mensen C: scannen).

[batjes]

Op elke schrijf wordt alles gescanned bij het wegschrijven en lezen door Defender. Tenzij je dit zelf uitzet. Ik zet het bij sommige games uit, omdat het de laadtijden enorm verbeterd.

Periodiek scannen van de C is gewoon een extra check. Er kan altijd wat door defender geslipt zijn toen het de data wegschreef. Vooral omdat er elke week wel weer nieuwe definities uitkomen.

[latka]

Ik zet het iig. uit voor waar ik compile. Iedere virusscanner tot nu toe vertraagt compilen van sourcecode vreselijk (veel kleine bestandjes).

Periodiek C: scannen om die reden snap ik, maar online? Kans dat dit wat vind is nihil en performance impact is dramatisch.

[dehardstyler]

Windows is voor iedereen gemaakt, niet alleen voor Tweakers he?

[johnkeates]

Dat zou je denken, maar de mate waarin je constant met Windows moet sleutelen en met het OS bezig moet zijn zou je haast doen vermoeden dat het is echt geschikt is voor de 99% van de bevolking die gewoon geen idee heeft hoe het werkt of wat ze moeten doen.

[.oisyn]

maar de mate waarin je constant met Windows moet sleutelen en met het OS bezig moet zijn

Je bedoelt zo goed als nihil?

[johnkeates]

Nee, ik bedoel dat je niet zomaar je computer kan gebruiken maar elke dag wel een popup, melding, update, scan, cleanup of reboot moet doen.

[.oisyn]

Je reinste kolder. Laten we "popup", "melding", "update" en "reboot" maar even onder hetzelfde ding scharen - ja, je moet soms rebooten bij een update. Elke dag? Absoluut niet. Maximaal eens in de twee weken, meestal langer. En dat is dan als je je PC nooit afsluit, want anders doet hij het gewoon dan. Elke dag een scan of een cleanup gaat helemaal nergens over. Scans gebeuren op de achtergrond en wat je met cleanup bedoelt is me een raadsel.

[Reactie gewijzigd door .oisyn op 23 juli 2024 08:22]

[johnkeates]

Heb jij wel eens een PC aangeraakt die niet van jezelf is? Ik vrees dat je beeld net wat te rooskleurig is. De meeste mensen die een PC met Windows gebruiken vallen in dezelfde categorie mensen die telefoons met Android gebruiken. OEM software distributies op OEM apparatuur met alle bijkomende 'value added services'.

Sure, een gestripte OEM setup, of schone installatie zal een stuk beter werken, net als dat AOSP schoner is dan een commerciële distributie. Dat maakt helaas niet dat in de realiteit alle gebruikers opeens ook een systeem hebben dat constant werkt zonder sleutelen.

Het is zelfs zo willekeurig dat je 10 dezelfde laptops uit 1 batch van een A-merk fabrikant kan kopen, uit de doos kan halen en aan kan zetten, en allemaal anders reageren, functioneren en andere volgorde van interactie vereisen om te werken.

[.oisyn]

Dus eigenlijk bedoel je de "mate waarin je met OEM software moet sleutelen". Excuses, ik dacht dat het over Windows ging.

[Anonymoussaurus]

Een clean-up kan een disk-cleanup zijn? Of dat hij automagisch de gedetecteerde objecten in quarantaine zet.

[batjes]

Daar zijn die waarschuwingen en Windows S voor.

[dehardstyler]

Als je door het patchen van Windows kunt zorgen dat er helemaal geen melding komt, is dat veiliger toch?
Jij weet net zo goed als mij ( ga ik maar even vanuit ) dat iedereen die IT niks boeit gewoon op Yes klikt. Dat het hartstikke fout is: Klopt.
Maar om het dan geen security flaw te noemen, nee.

[batjes]

Die mensen die overal op ja klikken, zijn nergens tegen te beschermen zonder ze a la iOS of Windows S de kans te ontnemen de boel onveilig te maken.

Geen security flaw in de manier van, er zijn oplossingen genoeg. Windows is met 2 vingers in de neus hier al tegen bestand te maken.

[dehardstyler]

Als de melding helemaal niet komt, kun je ook nergens op klikken!
Is het dan veiliger voor iedereen die de hele godganse dag overal ja op klikt? JA!

Windows is met 2 vingers in de neus hier al tegen bestand te maken.

Gefeliciteerd!

Boeit dat Anja met der laptop van €350 van de Mediamarkt iets? Nope.
Wordt haar laptop dus veiliger van deze actie? Ja!

[batjes]

Anja koopt vanaf nu dan maar lekker Windows S laptops. PEBKAC is geen security flaw.

[dehardstyler]

In een perfecte wereld, ja. Maar helaas.

[bbob]

Defender is een basis bescherming als je geen virisscanner hebt. Dat defender niet de beste oplossing is is ook bekend.

Gewoon dus een goede virusscanner nemen, probleem opgelost. Kost wel paar tientjes per jaar maar dank heb jo ook iets.

[Anoniem: 939189]

Gewoon dus een goede virusscanner nemen, probleem opgelost. Kost wel paar tientjes per jaar maar dank heb jo ook iets.

Ja en dan heb je Kaspersky en die ziet je eigen brouwsels als virus (false positive) of het weigert ontwikkel tools te installeren die door ander AV boeren als volkomen legitiem worden gezien.

[bbob]

Of je trekt internet uit je computer en dan heb je nergens last van.

Tja voor sommigen kan het nooit goed zijn.

[latka]

Zoals ik het nu lees wordt de dat dus 2x gelezen over het netwerk? Kan iemand dat bevestigen? Zou nogal wat zijn voor de netwerkbelasting als je die kunt halveren.

[cdwave]

Geen idee hoe je aan die conclusie komt, wees gerust, het OS doet er alles aan om liefst helemaal niks te hoeven lezen van IO zoals netwerk en disk. Da's een van de doelen van een OS.

[latka]

Dat noem je caching, dan moet je wel een exlusive lock op de data hebben. Dat is op een netwerk nogal een ding. Dan blijft over dat de data 2x van kernel space naar user-space moet. Nog steeds verre van efficient ;-)

[cdwave]

Dat noem je caching, dan moet je wel een exlusive lock op de data hebben. Dat is op een netwerk nogal een ding.

Praktijk is dat het OS maar aanneemt dat de executable niet wijzigt terwijl hij loopt.

Dan blijft over dat de data 2x van kernel space naar user-space moet. Nog steeds verre van efficient ;-)

In het geval van een executable is dat vrijwel altijd een memory-map operatie en geen kopie. Er wordt alleen maar een adres map aangemaakt, maar er wordt geen kopie van de data gemaakt. Data wordt van device (disk of net) via DMA in de cache geplaatst, en er hoeft dan alleen nog maar een page mapping aangemaakt te worden. Dus het is zelfs zo dat de CPU de data nog nooit gezien heeft.

[latka]

Nope, SMB doet aan oplocks. Dus tussen beide verzoeken tot de file gaat de client nogmaals naar de server om het bestand op te halen. Dat is ook de reden dat deze aanval uberhaupt werkt.
En ik heb nergens gezegd dat er een kopie wordt getrokken, pages mappen van kernel naar userspace leveren wel een TLB flush op en die is ook niet gratis.

[cdwave]

Je zou ook een USB "disk" kunnen maken die hetzelfde doet (linux bordje met "mass storage" gadget bijvoorbeeld). En eender welk ander filesharing protocol, zoals NFS, zou ook werken.

Ik geef MS groot gelijk, 't is geen kwetsbaarheid van het systeem.

[latka]

NFS zou niet werken omdat er SMB specifieke vlaggen worden gebruikt (FILE_RESERVE_OPFILTER) waarop de server kan inhaken om te zien dat het defender is. USB stick is ook een ander verhaal (ga je niet heen via SMB). Nope: dit is een design probleem van de combinatie virusscanner/SMB protocol.

[cdwave]

Je kunt de "execute" en "scan" ook wel uiteen houden zonder SMB vlaggetjes, maar gewoon door naar het patroon te kijken. De "scan" zal gewoon de file van voor tot achter lezen, de "execute" zal allerlei delen overslaan. Aangezien je de executable ook zelf gemaakt hebt, kun je het access patroon ervan ook voorkauwen door bijvoorbeeld een aantal secties in te voegen die niet gebruikt worden. De scanner betrap je dan snel genoeg.

Voor USB geldt hetzelfde, en dat levert veel toffere dingen op. Je kunt een malafide USB stick maken die zijn payload weet te verbergen voor scanners. Zelfs een SATA disk zou je op deze wijze kunnen spoofen, hoewel je daarvoor wel een FPGA nodig zult hebben.

Om caching effecten te omzeilen (als de scanner de file een keer gelezen heeft zal het OS die niet nog eens gaan lezen maar reproduceren uit de cache) kun je in de executable code opnemen die het OS vriendelijk vraagt om dat deel van de cache te legen. Dat stop je dan in het bonafide deel, zodat die het malafide deel kan activeren op het gewenste moment.

En ik zeg "OS" hier en niet "Windows", want dit werkt ook prima op andere OSsen.

[latka]

Heb je de attack vector bekeken? Het werkt alleen met SMB zoals het beschreven is. Wat er namelijk gebeurt onder windows:
Proces wil bestand lezen->Kernel stuurt notificatie naar virusscanner->Virusscanner proces leest data->het is goed->Kernel laat toe dat het proces de data leest.
De truuk is nu om de virusscanner buiten spel te zetten en een error te geven. Proces krijgt groen licht (want de virusscanner geeft niet aan dat het bestand geblocked is) en boem.
Naar het patroon kijken is lang niet zo nauwkeurig en dus valt het eerder op dat er gerommeld wordt. En ik snap je 'executable zelf gemaakt' niet helemaal. Er is geen client payload nodig, alleen een gehackte SMB server.
Op USB kan het als je een USB stick hebt die NTFS snapt (die ken ik niet) met de kanttekening dat het heuristisch zal zijn. Een FPGA implementatie van NTFS zie ik al helemaal niet gebeuren.

[cdwave]

Op USB kan het als je een USB stick hebt die NTFS snapt (die ken ik niet) met de kanttekening dat het heuristisch zal zijn.

USB device doet niet aan filesystemen, dat regelt het OS. USB (of eender welke bus) device regelt alleen dat er data op en neer gaat. Je kunt overigens prima NTFS op USB sticks gebruiken, vaak zat gedaan.

Een FPGA implementatie van NTFS zie ik al helemaal niet gebeuren.

Welke bedoel je: "Ik weet niet wat een FPGA is?" of "Ik snap je SATA idee niet."

[latka]

We praten langs elkaar heen: de hack bestaat er uit dat je een andere file aanbied aan de virusscanner dan degene die je uiteindelijk uitvoert. Het herkennen van een van beide kan gegarandeerd via SMB. Jij stelt dat dit ook kan via USB of SATA. Mijn punten daartegen zijn:
1) USB stick of hdd krijgt niet de metadata mee om het onderscheid te maken tussen beide leesacties.
2) een USB stick of hdd levert geen files maar blocks: het is vrij ondoenlijk om dan de juiste data te leveren die nog oa. Door de ntfs driver moet.
3) ik nam aan dat je een fpga op je hdd wilde doen om iets slimste te doen om probleem 2 te omzeilen (ik weet wat een fpga is) maar ntfs is iets meer dan een state machine en dan kun je beter een SoC gebruiken om je slimmigheden te maken.

Dus om je vragen/opmerkingen te beantwoorden: ja ntfs op USB is geen probleem. USB levert idd blocks of data ( en geen files waar de hack hier over gaat).
Ja, ik weet wat een fpga doet (doe ik namelijk wel eens wat mee) en die heeft niets te zoeken in deze hack. Als jouw hack zou werken met een USB stick zoals jij voorstelt dan werkt het ook met een hdd. Als de een (hdd) een fpga nodig zou hebben heeft de ander (USB) dat ook nodig want ze zijn voor deze hack allereerst een massage storage device met gelijke mogelijkheden en eigenschappen.

[cdwave]

Optie 2 dus, je snapt mijn SATA idee niet.

Relatie SATA en FPGA was dat ik een FPGA wel een SATA device kan laten implementeren, maar met een gewone SOC (zonder FPGA dus) kan dat niet (die hebben alleen "host" functionaliteit). Voor USB is dat geen probleem, de meeste embedded USB controllers kunnen prima als gadget functioneren.

Wat betreft blocks, ja dat bedoelde ik nou net.

Een "evil" block device hoeft niet alles van het filesysteem af te weten, alleen genoeg om andere data aan de scanner te serveren dan aan de lopende executable. En overigens is dat prima mogelijk, aangezien het blockdevice zelf een complete computer is kan die prima het filesysteem ontleden en aan de evil block manager doorgeven welke blocks bij welk patroon geserveerd moeten worden. Ik zeg ook niet dat het makkelijk is, alleen dat het mogelijk is. En voor executables op een samba share krijg je nog waarschuwingen van Windows voor, maar voor een USB of SATA disk helemaal niet.

[darkfader]

Net zoiets als web indexer robots niet te laten betalen voor paywalled sites.