Column: Microsoft schuldig aan verspreiden wormen via XP netwerkshares
De onderstaande bijdrage is afkomstig van Security.nl bezoeker Bitwiper
Het feit dat wormen zoals Conficker (Downadup) zich zo succesvol kunnen verspreiden via netwerkshares wordt veroorzaakt door een bug in Shell32.dll. Microsoft is van deze bug op de hoogte en heeft er al een half jaar geleden een patch voor gemaakt, maar het niet nodig gevonden om deze voor Windows XP, Windows 2003 Server en ouder als security patch in de maandelijkse patch-cyclus mee te nemen (alleen bij Vista is dit wel gebeurd met MS08-038, zie de FAQ).
NoDriveTypeAutoRun
De bug zit hem in het processen van de registerwaarde "NoDriveTypeAutoRun" (dit is een "REG_DWORD" waarde die standaard voor elke gebruiker bestaat onder de sleutel HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer, en systeembreed by default niet bestaat). De buggy versie van Verkenner (feitelijk Shell32.dll) kijkt uitsluitend naar die registerwaarde bij het mounten van een drive, d.w.z. het insteken van een USB-stick of het mappen van een netwerkdrive op een drive-letter; dat werkt zoals verwacht. Echter, indien men vervolgens in verkenner de drive dubbel-klikt om deze te openen, ofwel er met de rechter muistoets op klikt en voor ofwel Openen of Verkennen kiest, zal Verkenner niet meer naar "NoDriveTypeAutoRun" kijken, maar wel de inhoud van een Autorun.inf bestand in de root van de drive evalueren. Afhankelijk van de inhoud van Autorun.inf kan dan wel degelijk een bestand automatisch worden uitgevoerd!
NoDriveTypeAutoRun waardes
Dat Autorun.inf bestanden toch geëvalueerd worden ondanks dat NoDriveTypeAutoRun anders voorschrijft blijkt uit het volgende. Volgens recente Microsoft documenten (zoals deze) gelden de volgende mogelijke bit-waarden voor NoDriveTypeAutoRun (de waardes moeten bij elkaar opgeteld worden om tot de gewenste totaalwaarde te komen):
bit 0 (waarde = 0x01) Disables AutoPlay on drives of unknown type
bit 1 (waarde = 0x02) onbekend/ongebruikt?
bit 2 (waarde = 0x04) Disables AutoPlay on removable drives
bit 3 (waarde = 0x08) Disables AutoPlay on fixed drives
bit 4 (waarde = 0x10) Disables AutoPlay on network drives
bit 5 (waarde = 0x20) Disables AutoPlay on CD-ROM drives
bit 6 (waarde = 0x40) Disables AutoPlay on RAM disks
bit 7 (waarde = 0x80) Disables AutoPlay on drives of unknown type
D.w.z. een XP SP2 en SP3 default waarde van 0x91 betekent dat standaard AutoPlay (of AutoRun, het onderscheid tussen beide termen is niet altijd even duidelijk) voor network drives uit staat; toch kunnen de wormen zich verspreiden! Kortom, het is zinloos om te proberen genoemde wormen onder XP en ouder tegen te houden door met de beleidseditor (policy editor) of de registereditor aan de gang te gaan totdat Shell32.dll gepatched is.
Testen
Je kunt zelf eenvoudig testen of een Autorun.inf bestand op een USB-stick of netwerkshare wordt uitgevoerd door Notepad.exe naar de root van zo'n drive te kopieeren tezamen met een Autorun.inf met de volgende inhoud:
[autorun]
open=notepad.exe
shell\open\Command=notepad.exe
shell\explore\Command=notepad.exe
shellexecute=notepad.exe
useautoplay=1
Op netwerkshares is het gedrag iets anders dan op USB-sticks (een rechter muisclick op de netwerkdrive in "Deze Computer" gevolgd door "Open" start geen Notepad, terwijl dit wel gebeurt op een USB-stick).
Patch KB953252
Patch KB953252 installeert een update van Shell32.dll die, na het mounten van een drive, ook bij het openen en verkennen van die drive de waarde van NoDriveTypeAutoRun evalueert (er worden, in elk geval onder XP-SP3, geen andere bestanden vervangen). Belangrijk voor systeembeheerders is te weten dat behalve dat Shell32.dll wordt vervangen, KB953252 ook een registerwaarde toevoegt genaamd HonorAutorunSetting met waarde 1; die registerwaarde wordt door de patch alleen onder HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\Explorer geschreven. Het is belangrijk dat die waarde 1 blijft, zet je die op 0 dan vervalt Shell32.dll in het oude, buggy, gedrag (dit gebeurt onmiddellijk, een reboot of uit/inloggen is niet nodig).
Autorun op netwerkshares en USB-drives betrouwbaar uitschakelen onder XP
1) Installeer de juiste patch vanaf http://support.microsoft.com/kb/953252
2) Maak een registerwaarde NoDriveTypeAutoRun aan onder HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\Explorer (type DWORD) en geef deze de waarde 0x95
Let op: dit schakelt AutoRun op CDROM's niet uit, en daarmee ook niet voor USB-sticks die, naast een gewone partitie, ook een CDFS partitie hebben om van te starten (zoals U3 Flash Disks). Hoewel eventuele U3 sticks (of andere speciaal geprepareerde sticks) een risico vormen, zullen veel doorsnee gebruikers het gemak van een autostartende CD niet willen missen. Of je (binnen een bedrijf bijvoorbeeld) dit wel of niet wilt is een risicoafweging; het nut van Autorun op netwerkdrives en gewone USB-sticks ontgaat me.
Bovendien zijn er meldingen (bijv. deze en deze) dat Microsoft het uitzetten van AutoRun op CD's (via NoDriveTypeAutoRUn) vanwege mogelijke kopieerbeveiligingen weigert uit te voeren, maar deze kan ik niet bevestigen. Zie het alternatief voor patch KB953252 zoals verderop voorgesteld.
Aanmaken en wijzigen NoDriveTypeAutoRun: hoe doe je dat?
Aanmaken en wijzigen van NoDriveTypeAutoRun kan zoals hier is aangegeven (helaas ontbreekt daar de informatie dat dit onder XP, 2003 en ouder alleen zinvol is indien patch KB953252 is gedraaid).
Voor XP Home zorgt het uitvoeren van een tekstfile met de volgende inhoud ervoor dat alle (en ook toekomstige) gebruikers beschermd zijn:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer]
"NoDriveTypeAutoRun"=dword:00000095
Gratis tool: AutoRunSettings
vooral voor XP home gebruikers die het register niet handmatig of met een bestandje willen wijzigen, maar ook als je alleen wilt kijken en niets snapt van hexadecimaal rekenen, bestaat er een gratis en Engelstalig alternatief van Uwe Sieber: AutoRunSettings. Het makkelijkste is om daarmee de (standaard ontbrekende) HKEY_LOCAL_MACHINE registerwaarde aan te maken door in de rechthoek rechtsboven de gewenste waardes aan te clicken of uit te zetten en Apply te drukken (een vinkje betekent dat uitvoeren van Autorun is toegestaan). Je kunt het alle vinkjes uitzetten en naar keuze CD/DVD aan of toch uit.
Als je links boven waardes hebt gezet maakt het niet meer uit wat er rechtsboven staat. De CD/DVD insert notification kun je het beste aan laten. De waardes in het onderste venster kun je ook het beste ongewijzigd laten.
Alternatief voor NoDriveTypeAutoRun en patch KB953252
Voor degenen die geen enkele Autorun.inf (ook vanaf CD's) meer uitgevoerd willen hebben biedt Nick Brown al geruime tijd op zijn blog een prima alternatief aan, dat natuurlijk niet door Microsoft ondersteund wordt (en dus in de toekomst problemen zou kunnen geven). Deze truck wordt op steeds meer plaatsen vermeld, maar voor zover ik weet is Nick Brown de bedenker ervan. De discussie onder de blog is ook het lezen waard, maar niet altijd correct.
Aanvullende informatie
Ondertussen is de informatie op de WikiPedia Autorun pagina goed up-to-date, maar is de laatste paar weken wel vaak gewijzigd (waarbij soms relevante informatie lijkt te zijn weggehaald). De informatie op de Microsoft site over Autorun en NoDriveTypeAutoRun is op veel punten onvolledig, achterhaald of gewoon fout.
Bij de introductie van XP SP2 heeft Microsoft de default (per user) waarde van NoDriveTypeAutoRun gewijzigd van 0x95 naar 0x91, waarmee removable drives (bijv. USB) bij het mounten al een eventuele Autorun.inf uitvoeren.
Sommige "Autorun onderzoekers" vermelden dat gegevens van eerder gelezen USB-sticks, removable drives e.d. die onder de de MountPoints2 registersleutel zijn opgeslagen ervoor zouden zorgen dat de NoDriveTypeAutoRun instelling wordt genegeerd. In verschillende tests die ik zelf heb doorgevoerd heb ik daar niets van gemerkt, en echt duidelijke bewijzen hiervoor heb ik niet kunnen vinden. Mogelijk dat patch KB953252 (die ik iedereen aanraad) Shell32.dll ook op dit punt heeft aangepast.
Voor degenen die op het indrukken van de Shift-toets vertrouwen: deze werkt alleen bij het inserten van een drive, en niet bij Openen/Verkennen; en onder Vista is deze functionaliteit van de Shift-toets geheel uitgeschakeld!
Conclusie
Microsoft moet KB953252 ASAP als securitypatch verspreiden, alleen al omdat dit, zonder NoDriveTypeAutoRun te wijzigen, het verspreiden van Aurorun-wormen via netwerkshares tegengaat. Tot die tijd kunnen security-aware bedrijven die patch wellicht zelf uitrollen. Na het toepassen van die patch kunnen bedrijven m.b.v. policies betrouwbaar (mogelijk m.u.v. van CDFS partities) het Autorun gedrag betrouwbaar configureren. Indien men geheel geen Autorun.inf bestanden wil uitvoeren kan men Nick Browns's oplossing toepassen, maar dat is een niet door Microsoft goedgekeurde oplossing.
Belangrijke update!
De waarde voor het gedeelte "Autorun op netwerkshares en USB-drives betrouwbaar uitschakelen onder XP" stond in eerste instantie niet goed vermeld. Dit is nu aangepast.
Door Bitwiper
+10 voor dit artikel!!
Het zou niet nodig hoeven zijn als de onderliggende security en software architectuur dit soort automatisch starten van processen bij "mounten" van media zou verbieden.
"En wat dan nog ?"
Roept u maar....
Dat het "niet door Microsoft ondersteund wordt" zal voor de meeste mensen waarschijnlijk geen grote zorg zijn (de Conficker-wurm zelf words ook niet door MS gesteund en lijkt toch prima te werken), maar in ieder geval is mijn registry-hack, die uit een .REG-file van 3 regels, 100% ongedaan te maken met een andere .REG-file van 2 regels, die in de commentaar op mijn blogentry te vinden is.
Dat het "niet door Microsoft ondersteund wordt" zal voor de meeste mensen waarschijnlijk geen grote zorg zijn (de Conficker-wurm zelf words ook niet door MS gesteund en lijkt toch prima te werken), maar in ieder geval is mijn registry-hack, die uit een .REG-file van 3 regels, 100% ongedaan te maken met een andere .REG-file van 2 regels, die in de commentaar op mijn blogentry te vinden is.
Zoals ik al schreef, jouw oplossing werkt prima en beschermt ook tegen eventueel autostartende malware op CDROM's (denk aan [url=http://www.security.nl/article/12164/1/Verwijderen_Sony%27s_%27rootkit%27_sloopt_Windows.html]Sony's rootkit[/url] maar ook aan CDFS partities op removable drives).
Echter ik vermoed dat veel leken problemen zullen hebben met sommige CDROM's waarbij het niet altijd duidelijk is welk programma automatisch zou starten als Autorun zou werken (zeker niet als dat in een map staat). Bovendien zullen veel bedrijven niet snel tot niet-Microsoft maatregelen overgaan, gewoon omdat ze de consequenties niet kunnen overzien (zelfs computernerds verschillen voortdurend van mening over hoe e.e.a. precies werkt) en geen tijd hebben om goed te testen (bovendien, wat zou je moeten testen?).
Kortom, de volgende registryfile importeren en vervolgens rebooten is een prima oplossing zonder dat ik onder XP-SP3 negatieve bijwerkingen heb ontdekt, maar je hebt dan niet meer de flexibiliteit om het uitvoeren van Autorun op netwerkshares en USB sticks (de m.i. grootste risico's) te blokkeren en tegelijkertijd de uitvoering vanaf CD's toe te staan:
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\IniFileMapping\Autorun.inf]
@="@SYS:DoesNotExist"
Ander punt: ik ben afgelopen nacht even doorgeschoten met het wijzigen van de testversie van Autorun.inf om deze op netwerkshares aan de praat te krijgen, waardoor deze niet meer autostart op een USB-stick bij het insteken (in plaats van dat Notepad start krijgt nu een Autoplay popup menu met de vraag wat je wilt). Als je de volgende Autorun.inf op je USB stick zet werkt het autostarten van notepad wel bij insteken (d.w.z. natuurlijk alleen indien Nick Brown's patch niet gedraaid is, jouw persoonlijke NoDriveTypeAutoRun de waarde 0x91 heeft en onder HKEY_LOCAL_MACHINE geen NoDriveTypeAutoRun bestaat):
; open=notepad.exe
shell\open\Command=notepad.exe
shell\explore\Command=notepad.exe
shellexecute=notepad.exe
useautoplay=1
Verder vermoed ik dat de titel "Microsoft schuldig aan verspreiden wormen via XP netwerkshares", niet verzonnen is door de auteur, want die dekt de lading natuurlijk ook niet.
Zelf heb ik nog een idee gehad, maar nog niet volledig in praktijk gezet:
Patch de Windows DLLs zodat ze niet meer zoeken naar bestand autorun.inf maar bv. naar stoprun.inf. Hierdoor zal Windows zoeken naar bestand stoprun.inf op removable media i.p.v. autorun.inf. Nu moet iedereen natuurlijk niet stoprun.inf beginnen gebruiken, want anders beginnen de malware auteurs dit ook te doen.
De lijst met te patchen DLLs heb ik al. Patchen van de bestanden is eenvoudig, maar je loopt het risico dat ze overschreven worden op de 2de dinsdag van de maand. Daarom is patchen in memory beter, maar moet telkens uitgevoerd worden als Windows Explorer start (dus als een gebruiker aanlogged). Kan bv. eenvoudig gedaan worden met mijn bpmtk tool.
Verder vermoed ik dat de titel "Microsoft schuldig aan verspreiden wormen via XP netwerkshares", niet verzonnen is door de auteur, want die dekt de lading natuurlijk ook niet.
Iets na 03:00 een mailtje naar redactie met daarin:
Ik heb er nu toch maar wat haast mee gemaakt, hopelijk kunnen we er wat gebruikers mee helpen en de druk op Microsoft opvoeren om de bestaande patch als security patch automatisch te verspreiden.
Bij het mailtje zat een bijlage met als kop: "Microsoft schuldig aan verspreiden wormen via netwerkshares onder XP". Dat is door de redactie in eerste instantie ingekort tot "Microsoft schuldig aan verspreiden wormen op XP" en vervolgens op mijn verzoek gewijzigd in de huidige titel. De reden om voor deze titel te kiezen is dat dit m.i. een onderbelicht probleem is: de focus is vooral op autorun in USB-sticks en fotolijstjes. Zodra je zo'n worm op je netwerk hebt en klaar bent met patchen van [url=http://www.microsoft.com/technet/security/Bulletin/MS08-067.mspx]MS08-067[/url] blijft deze via allerlei (il)legale netwerkshares in omloop gebracht worden.
Ik vermoed dat deze worm zo "succesvol" is doordat deze zich via meerdere methodes verspreid, en daardoor moeilijk uit te roeien is. Dat je [url=http://www.microsoft.com/technet/security/Bulletin/MS08-067.mspx]MS08-067[/url] moet draaien begrijpt elke admin, maar juist doordat [url=http://support.microsoft.com/kb/953252]KB953252[/url] niet als automatische update verspreid wordt en je op de meeste plaatsen leest dat het aanpassen van NoDriveTypeAutoRun volstaat vaak zonder KB953252 te noemen leidt tot verwarring en veel onnodige slachtoffers (PC's, hopelijk geen ziekenhuispatiënten).
@Didier Stevens: wat jij noemt kan, maar, met alle respect, is m.i. Nick Brown's patch een stuk eenvoudiger, en het risico op false positives door virusscanners die code-injection detecteren is bij zijn patch niet aan de orde.
Akkoord.
Slechts één opmerking: strikt genomen gaat het niet om code-injection (dus CreateRemoteThread), maar om schrijven in het geheugen van een ander process (WriteProcessMemory), en er zijn veel meer AV producten die dit door de vingers zien.
De registry oplossingen zijn allang bekend bij de meeste grotere bedrijven.
Het feit blijft dat men simpel weg te laks om op tijd de juiste risico analyse te doen en dan patch snel genoeg te installeren.
Men zal veel meer en beter aan patch management moeten doen.
In de tijd dat XP gemaakt werd, waren de gevaren van internet al lang bekend maar nog niet op de huidige schaal natuurlijk.
Windows heeft alle kenmerken van moderne consumptie-producten. En dat is niet toevallig.
Is Microsoft dat verantwoordelijk, de mensen willen het toch zelf?
De mensen willen het zelf maar door de koppelverkoop kon de massa praktisch gezien geen computer kopen zonder Windows. Microsoft heeft z'n eigen inferieure baggerware door de strotten van het publiek gedrukt voor het eigen gewin. Iets dat iedereen overigens zou doen, laten we onszelf vooral niet heilger voordoen dan we zijn.
Doordat de IT-ers in spe alleen Windows kennen, is het voor bedrijven makkelijker om aan Windows-kennis te komen dan aan iets anders. Waardoor managers voor Windows kiezen. Managers hebben doorgaans geen verstand van echte zaken en 'geloven' dat het allemaal niets uitmaakt. Managers gebruiken thuis ook Windows.
Bitwiper heeft gelijk.
Het is wachten tot de massa vriendelijk wat geld gaat terugvragen. Met een financiele crisis worden mensen vast vindingrijk.
De registry oplossingen zijn allang bekend bij de meeste grotere bedrijven.
Dit is een bug, maar helaas bij USA National Vulnerability Database alleen in Vista [url=http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0951]aangemerkt[/url] als een security risk, terwijl deze (zie [url=http://support.microsoft.com/kb/953252]KB953252[/url]) net zo goed voor XP, 2003 en 2000 geldt. Er is nu ook een Microsoft blogger die [url=http://blogs.technet.com/kfalde/archive/2009/01/12/more-on-file-shares-and-autorun-inf-with-regards-to-malware.aspx]melding[/url] maakt van deze bug.
Over bugs gesproken: in mijn stuk bovenaan stond achter "2)" met de waarde 0x91 een storende fout, dat moet natuurlijk 0x95 zijn. Met dank aan de redactie voor het corrigeren hiervan, en excuses voor de lezers!
Als er geen alternatief was zou dit waarschijnlijk de "next best" zijn. 10 jaar geleden heb ik precies deze oplossing gebruikt om de toen "populaire" Wordmacrovirussen te stoppen. Ik schreef een programma die in WWINTL32.DLL en VBE.DLL naar bepaalde strings zocht: "AutoExec", "AutoNew", "AutoOpen", "AutoClose", "AutoExit", en "document_" (van document_open of document_close, voor VBS-virussen) en een nieuwe versie maakte waarin het woord "Auto" door "{random}" vervangen werd. Het heeft ons netwerk helemaal virusvrij bewaard, totdat Microsoft de "default security level" tot High (geen macros zonder toestemming) in Office 2000 heeft verhoogd.
Ik ben verantwoordelijk voor een netwerk met ongeveer 1.800 PCs en wij gebruiken sinds 20 jaar geen commerciële (noch "free", trouwens) antivirus cq anti-malware producten op de PCs, want (eenvoudig gezegd) deze producten werken gewoon niet (of in ieder geval, de verhoudingen prijs/prestatie en systeemvertraging/bescherming zijn veel te hoog). De gevolgen van de meeste virussen zijn te verwaarlosen ivm bijvoorbeeld een slechte serie harddisks. Alleen de wurmen die weten zich binnen je netwerk te verspreiden zijn werkelijk gevaarlijk, en in de meeste gevallen (Sasser, MS-Blast, Conficker) zijn deze helemaal niet door antivirussoftware buiten te houden. Een gratis antiviruspakket kan af en toe handig zijn om een PC schoon te maken na een aanval, als herinstalleren werkelijk geen optie is (maar dan moet je wel hopen dat de harddisk niet kapot gaat hé), maar ook dan is het niet zo nuttig bij de gemiddelde wurm want die zijn meestal eenvoudig om te verwijderen (2-3 registry entries en een paar DLLs deleten).
Dit is een bug, maar helaas bij USA National Vulnerability Database alleen in Vista aangemerkt als een security risk, terwijl deze (zie KB953252) net zo goed voor XP, 2003 en 2000 geldt. Er is nu ook een Microsoft blogger die melding maakt van deze bug.
Over bugs gesproken: in mijn stuk bovenaan stond achter "2)" met de waarde 0x91 een storende fout, dat moet natuurlijk 0x95 zijn. Met dank aan de redactie voor het corrigeren hiervan, en excuses voor de lezers!
Ik heb menig systeem met NoDriveTypeAutoRun afgesloten en heb nog nooit een dergelijke actie gezien. Maar de policy wordt dan ook in HKey_CU en HKey_LM gezet door mij. Ook het dubbelklikken via "My Computer" of "Deze Computer" resulteerde niet in het feit dat iets van autorun wordt gestart.
; open=notepad.exe
shell\open\Command=notepad.exe
shell\explore\Command=notepad.exe
shellexecute=notepad.exe
useautoplay=1
In een ander geval zou malware zelf sleutels naar eigen gerieven aan kunnen passen of aanmaken.
In een ander geval zou malware zelf sleutels naar eigen gerieven aan kunnen passen of aanmaken.
In het algemeen geldt dat indien malware met adminrechten op een systeem gedraaid heeft, er vanalles gewijzigd kan zijn waardoor zo'n systeem nooit meer helemaal betrouwbaar is.
Malware die met beperkte rechten draait kan wel heel nare dingen doen (spam verzenden, programma's autostartend maken uitsluitend als de betreffende gebruiker inlogt, bestanden wissen of versleutelen, netwerkscans uitvoeren, toetsaanslagen sniffen en doorsturen, soms de virusscanner uitzetten etc.) maar zal in de praktijk het systeem zelf niet kunnen beschadigen of wijzigen. Bijv. onder HKEY_LOCAL_MACHINE hebben gewone gebuikers nergens schrijfrechten, en dus ook de eventuele malware niet die onbedoeld draait.
E.e.e. natuurlijk onder voorbehoud dat die malware niet van privilege escalation technieken gebruik maakt/kan maken, maar dergelijke malware heb ik nog nooit gezien.
Ik heb dit WE software in elkaar geknutseld om de toegang tot \autorun.inf op USB sticks te weigeren.
Het is vroege beta software, en het draait in de kernel, dus alleen maar gebruiken op test machines. Lees de README.TXT voor de install procedure.
Ariad: http://blog.didierstevens.com/programs/ariad/
Ariad is ontwikkeld op Windows XP SP2, en ik heb het geïnstalleerd op Windows XP SP2 (Virtual & Physical), Windows Vista SP1 (Physical) en Windows 7 Beta (virtual).
Met jouw huidige oplossing ontgaat de meerwaarde me t.o.v. de [url=http://nick.brown.free.fr/blog/2007/10/memory-stick-worms.html]"Nick Brown" oplossing[/url]. Bovendien kunnen beide tot problemen leiden met encrypted USB sticks, in elk geval worden problemen gemeld met [url=http://www.security.nl/artikel/26417/1/Kingston_dtsp_USB-stick_werkt_niet_na_uitschakelen_AutoRun.html]Kingston DTSP[/url] sticks. Bovendien betekent jouw oplossing enig performanceverlies bij het openen van elk bestand.
Jouw oplossing zou voor sommigen wel handig kunnen zijn als deze een dialogbox zou tonen met de vraag of de Autorun moet worden uitgevoerd, c.q. of je deze eerst wilt inzien (notepad) of cancellen. Ook interessant zou een oplossing kunnen zijn waarbij je vertrouwde Autorun.inf files kunt whitelisten (bijv. middels hashes in de registry).
Ten slotte zou je mogelijk een kleine performanceverbetering kunnen doorvoeren door eerst te vergelijken met de backslash (path naar rootdir), en dat natuurlijk case insensitive.
My 2 cents...
...
Met jouw huidige oplossing ontgaat de meerwaarde me t.o.v. de "Nick Brown" oplossing
...
Jouw oplossing zou voor sommigen wel handig kunnen zijn als deze een dialogbox zou tonen met de vraag of de Autorun moet worden uitgevoerd, c.q. of je deze eerst wilt inzien (notepad) of cancellen. Ook interessant zou een oplossing kunnen zijn waarbij je vertrouwde Autorun.inf files kunt whitelisten (bijv. middels hashes in de registry).
...
http://www.governmentsecurity.org/forum/index.php?showtopic=31252
"And why another USB blocking tool? Well, because I always wanted to code a minifilter. And this one is in the public domain and open source, so you can see exactly how it works."
Eén van mijn manieren om iets te begrijpen is een programma schrijven.
En bedankt voor de suggesties. De whitelist is interessant.
Dit zou moeten getest worden. Mijn redenering bij het eerst testen van de path, is dat elke path steeds met backslash zal beginnen. Terwijl niet elke filenaam met de letter a zal beginnen.
En bedankt voor de suggesties. De whitelist is interessant.
My 2 cents...
Dit zou ik moeten testen. Mijn redenering is dat elke path sowieso met een backslash zal beginnen, terwijl niet elke filenaam met de letter a zal beginnen.
My 2 cents...
Dit zou ik moeten testen. Mijn redenering is dat elke path sowieso met een backslash zal beginnen, terwijl niet elke filenaam met de letter a zal beginnen.
- ofwel unicode_char voor unicode_char "uni-cased" en per char vergelijkt (en stopt zodra unequal of \0 gevonden)
- ofwel eerst beide strings "uni-cased" (dat zou zonde zijn)
In beide gevallen is het ook zonde is dat 1 van de strings een constante is.
Optimization is erg leuk, maar ik geloof dat we nu een beetje off-topic raken (mijn schuld, ik begon ermee :)....
Overigens ook leuk om dit soort sources te zien, ik heb kernel-stuff altijd heel boeiend gevonden maar vanaf NT4 is het allemaal nogal "afstandelijk" geworden (ik kom er gewoon niet meer aan toe).
Even over hashen: pak wel minstens SHA-1, want doordat je Autorun files ongestraft een random inhoud kunt geven (zie [url=http://www.f-secure.com/weblog/archives/00001575.html]hier[/url], 90kB crap) waardoor MD5 collisions betrekkelijk eenvoudig te realiseren zijn. Het is toegegeven nogal theoretisch, maar zodra wormmakers weten wat de hash van de Autorun.inf op bekende USB-sticks is zouden ze die wellicht kunnen spoofen en meezenden met de worm.
En ik heb versie 0.0.0.2 gepost. CD-roms worden ook behandeld, maken van een lege \autorun.inf kan niet meer, renamen naar \autorun.inf is ook verboden.
Wordt na het toevoegen van de registersleutel van Nick Brown een autorun-bestand nog door een virusscanner gescand?
Wordt na het toevoegen van de registersleutel van Nick Brown een autorun-bestand nog door een virusscanner gescand?
Windows bevat voor programmmeurs handige routines voor het lezen van gegevens uit [url=http://technet.microsoft.com/en-us/library/cc731332.aspx]ini-files[/url] (die een extensie naar keuze mogen hebben, waaronder .inf), bijv. [url=http://msdn.microsoft.com/en-us/library/ms724353(VS.85).aspx]GetPrivateProfileString[/url]. Daarmee kun je als programmeur aan Windows vragen: geef me uit bestand "X:\AutoRun.inf" uit de sectie "[Autorun]" de waarde achter "Open=", en als die sectie of die waarde niet bestaat, geef me dan maar "C:\Windows\System32\Notepad.exe" terug (hypothetisch geval).
De GetPrivateProfileString routine is eigenlijk een speciale variant van [url=http://msdn.microsoft.com/en-us/library/ms724366(VS.85).aspx]GetProfileString[/url] die al sinds Windows 3.x (of ouder?) gegevens uit C:\Windows\Win.ini leest. De bestanden C:\Windows\Win.ini (en C:\Windows\System.ini) bestaan vaak nog wel (voor stokoude applicaties die GEEN gebruik maken van routines als GetProfileString), maar de functionaliteit daarvan is allang overgenomen door het Windows Register (Registry). De term Private uit GetPrivateProfileString slaat dan ook op het gebruik van applicatie-specifieke ini-files.
Voor oudere applicaties die (nog) niet het register direct benaderen, maar ini-files wel met GetPrivateProfileString uitlezen, heeft Microsoft de mogelijkheid gecreëerd om per applicatie-specifieke ini-file aan te geven dat de gegevens voortaan uit het register moeten worden gehaald (of er in weggeschreven). Bijv. als systeembeheerder kun je zo'n "ini-file-mapping" in het register opnemen, en dat is precies wat Nick Brown's truuk doet - alleen verwijst hij daarmee naar een niet-bestaande plaats in het register.
Goede (en goed geconfigureerde!) virusscanners kijken niet naar bestandsextensies, en zullen elk bestand zelf openen om de inhoud te lezen. ongeacht de truuk van Nick Brown zou het onjuist zijn om in het geval van een kennelijk ini-bestand daar functies als GetPrivateProfileString voor te gebruiken: die haalt namelijk alleen de informatie uit de file waar je expliciet naar zoekt (en gaat daarbij zover dat binaire rommel compleet genegeerd wordt, zie [url=http://www.f-secure.com/weblog/archives/00001575.html]hier[/url] waar tussen 90 kB aan random troep feitelijke Autorun.inf informatie te vinden is).
Kortom, virusscanners zouden onbetrouwbaar werken als ze bestanden niet direct zouden lezen, en daarom geloof ik niet dat het toevoegen van de registersleutel van Nick Brown ertoe zal leiden dat Autorun.inf bestanden niet meer gescanned worden.
De consequentie daarvan is dat UITSLUITEND de huidige gebruiker toegang heeft, en, belangrijk, Local System niet meer. Dat heeft allerlei problemen tot gevolg, waaronder dat installeren van software soms niet goed meer werkt (zie [url=http://support.microsoft.com/kb/221524]hier[/url]). Ook interessant in het kader van deze thread is dat Autorun en Autoplay dan niet meer werken (zie [url=http://support.microsoft.com/kb/330135]hier[/url]).
Daarnaast is het zetten van deze registerwaarde ook erg onverstandig omdat de meeste on-access (achtergrond) virusscanners draaien onder het gebruikersaccount Local System (om ook bestanden te kunnen scannen waar jij als gebruiker geen toegang toe hebt, bijv. in de map "C:\System Volume Information\"), M.a.w. als je vanaf een CD/DVD een bestand opent of start terwijl AllocateCDRom op 1 staat, zal dat bestand niet automatisch op virussen worden gescanned!
Voor zover ik weet bestaat er geen AllocateUSBDrives o.i.d., maar of AllocateCDRom en/of AllocateFloppies eventueel ook invloed hebben op USB-drives weet ik niet (heb ik niet onderzocht).
Die update zorgt ervoor dat:
- autorun op netwerkshares niet meer werkt (de default NoDriveTypeAutoRun registerwaarde wordt nu correct toegepast)
- autorun op USB-sticks en vaste schijven kan worden uitgezet door het wijzigen van de NoDriveTypeAutoRun registerwaarde (handmatig of middels policies) waarna deze correct zal worden toegepast.
Let op: de update zelf blokkeert dus nog niet autorun van USB-sticks!
Technische informatie over deze update is te vinden in [url=http://support.microsoft.com/kb/967715]KB967715[/url] met de titel How to correct "disable Autorun registry key" enforcement in Windows (dat nieuwe artikel vertoont grote gelijkenis met [url=http://support.microsoft.com/kb/953252]KB953252[/url] welke exact dezelfde titel heeft, maar waar wel vertaalde versies van bestaan).
Uit de FAQ van [url=http://www.microsoft.com/technet/security/advisory/967940.mspx]Microsoft Security Advisory 967940[/url]:
No. Automatic updating will check to see if the system already contains the fix that correctly respects the registry keys values to disable Autorun capabilities as offered by Microsoft Knowledge Base Article 953252. If the fixed code is present, users will not be reoffered the updates from Microsoft Knowledge Base Article 967715 because, although Microsoft Knowledge Base Article 953252 was not deployed via automatic updating, both the updates contain the same changes.
Bron: [url=http://www.heise.de/security/Microsoft-bestaetigt-Excel-Luecke-und-fixt-Autorun--/news/meldung/133475]Heise Security[/url]
Microsoft luistert altijd, hoor Bitwiper: Het duurt alleen soms even voordat het doordringt. ;-) Even een kleine correctie: Vista & 2008 hebben kb953252 wel meteen als Automatische Update gekregen.
Hierbij een aanvulling over het USB-deel hierboven in beide Bitwiper artikelen (& daarom post ik het dan ook maar in beide):
[url=http://support.microsoft.com/kb/967715]How to correct[/url] "disable Autorun registry key" enforcement in Windows (kb967715) & ga dan naar:
Workaround 2: To prevent users from connecting to USB storage devices.
Waar verwezen word naar:
[url=http://support.microsoft.com/kb/823732/]
How can I prevent[/url] users from connecting to a USB storage device? (kb823732)
Waarin de volgende twee mogelijkheden gegeven worden:
[url=http://support.microsoft.com/kb/823732/#FixItForMe]“Fix it for me” section[/url].
[url=http://support.microsoft.com/kb/823732/#LetMeFixItMyself]“Let me fix it myself” section[/url].
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
