Onderzoekers vinden manier om Windows UAC te omzeilen zonder dll-bestand

Onderzoekers Matt Nelson en Matt Graeber hebben een manier ontdekt om code op een Windows-machine uit te voeren, zonder dat daarvoor toestemming via UAC nodig is. De methode maakt geen gebruik van dll-bestanden, die normaal gesproken voor een dergelijke techniek zijn vereist.

Nelson beschrijft de techniek op zijn blog en stelt dat deze werkt op Windows 7 en Windows 10. Hij vermoedt echter dat de methode ook werkt op andere versies van het besturingssysteem die UAC toepassen. Tegenover Threatpost legt de onderzoeker uit dat de techniek een kwaadwillende in staat stelt om willekeurige code uit te voeren op een Windows-computer. Daarvoor moet de aanvaller echter al toegang hebben tot de pc en beheerdersrechten bezitten. Het gaat daarmee om een 'post-exploitation'-techniek, die kan worden ingezet als al op een andere manier toegang is verkregen.

De methode maakt gebruik van eventvwr.exe, in Windows bekend als Event Viewer. De onderzoekers stelden vast dat dit proces bepaalde registerwaarden oproept als een high integrity process. Daarmee wordt een proces bedoeld dat vanuit het systeem meer 'vertrouwen' geniet als het gaat om permissies. Er bestaat een verband tussen de registerwaarden van HKEY_CLASSES_ROOT, oftewel HKCR, en HKEY_CURRENT_USER, oftewel HKCU. De onderzoekers leggen uit dat het daardoor mogelijk is om een proces te beïnvloeden dat deze waarden oproept, door de inhoud daarvan aan te passen.

Event Viewer doet precies dat en gebruikt beide waardes om mmc.exe op te roepen, dit is de Microsoft Management Console. Dit proces opent op zijn beurt het Console-bestand evenvwr.msc, waarna de Event Viewer wordt getoond. Door het verband tussen HKCR en HKCU konden de onderzoekers vervolgens een registerstructuur aanmaken, waardoor eventvwr.exe een andere locatie opriep. Zo konden ze mmc.exe vervangen door Powershell en op die manier willekeurige code uitvoeren.

Volgens Threatpost heeft Microsoft nog niet laten weten of het probleem opgelost gaat worden. In het verleden zou het bedrijf geen hoge prioriteit hebben gegeven aan manieren om UAC te omzeilen. Het is mogelijk om deze methode te voorkomen door UAC in te stellen op 'Always notify', aldus de onderzoekers.

Reacties (66)

[SierraHotel]

Wat ik nu niet helemaal begrijp... Is dit echt een security issue? je moet ten slotte al rehten hebben?

[Rafe]

Zoals al in het artikel staat: "Het gaat daarmee om een 'post-exploitation'-techniek, die kan worden ingezet als al op een andere manier toegang is verkregen" - bijvoorbeeld nadat je bent binnengekomen via een proces met beperkte rechten en dan beheerdersrechten met een andere exploit hebt verkregen (privilege escalation). Met deze fout kan je dan stilletjes zaken wijzigen zonder dat de gebruiker plotseling een UAC-prompt krijgt.

[Reactie gewijzigd door Rafe op 23 juli 2024 13:39]

[Killah_Priest]

Maar als je al admin rechten hebt op een machine dan kun je in feite via een remote powershell sessie sowieso vrijwel alles op systeem niveau wijzigen zonder dat er ooit een UAC prompt naar voren komt (ik wijzig namelijk regelmatig remote via PS settings op machines of servers, als ik dezelfde settings bv "lokaal" wil wijzigen dan moet ik normaal gesproken bv Powershell als elevated draaien, via een remote PS sessie hoeft dat niet - een beetje hetzelfde als vanaf een DC met Powershell (ik weet het, bad practice op interactief op een DC in te loggen, ik doe dat ook zelfden) Set-ADUser doen, kan niet als je niet elevated bent terwijl dit via een remote PS sessie naar dezelfde server wel gewoon kan.

En je kunt btw vanuit een lokale PS sessie een remote sessie maken naar je eigen machine als er bepaalde settings voor WinRM zijn doorgevoerd

[Reactie gewijzigd door Killah_Priest op 23 juli 2024 13:39]

[R4gnax]

Zoals al in het artikel staat: "Het gaat daarmee om een 'post-exploitation'-techniek, die kan worden ingezet als al op een andere manier toegang is verkregen" - bijvoorbeeld nadat je bent binnengekomen via een proces met beperkte rechten en dan beheerdersrechten met een andere exploit hebt verkregen.

Het is een post-exploitation attack omdat je binnen moet zijn als de local admin account. Maar je hoeft nog niet een UAC bypass gedaan te hebben om reeds volledige rechten te hebben.

Het opzetten van de exploit vereist enkel het zetten van een waarde in de HKEY_CURRENT_USER registry hive, welke ook al met standaard gebruikersrechten gewoon schrijfbaar is.

[Armin]

Met deze fout kan je dan stilletjes zaken wijzigen zonder dat de gebruiker plotseling een UAC-prompt krijgt.

Dat kan ook zonder deze "exploit". In die zin is het jammer dat mensen zo ontzettend mekkerden toen Vista uitkwam dat Microsoft zich gedwongen zag om de UAC wat minder snel te laten waarschuwen. (Aan de andere kant was er ook zo ontzettend veel bagger software die dacht voor alles admin rechten nodig te hebben dat je als gebruiker inderdaad ook soms gek werd).

Ikzelf heb UAC ook op Windows 7, 8.x en 10 nog steeds op zijn strengst staan om die reden.

[Beunhaas91]

Op deze manier kun je op de achtergrond, zonder dat de gebruiker daar wat van ziet, iets anders openen. Ik hoef niet uit te leggen dat dit behoorlijk ernstige gevolgen met zich mee kan brengen!

[hottestbrain]

En daarom is het wel degelijk een rechtenkwestie. Zonder adminrechten gaat dit toch niet lukken.

[Mizgala28]

Klopt maar ik ben bewust de admin op mijn PC.

Je denkt toch niet dat ik iedere keer zin in heb om mijn wachtwoord in te typen? Nee, en een makkelijker wachtwoord veroorzaakt weer een ander probleem.

Reden dat ik admin ben is simpel, ik start vaak programma's op die admin rechten vereisen = UAC scherm komt tevoorschijn.

[M.l.]

Maar het punt is dus dat je nu dat scherm niet meer gaat zien. Als je per ongeluk troep binnenhaalt zal het door middel van deze techniek dus ongemerkt in je systeem kunnen nestelen.

[Mizgala28]

Klopt, ik neem die risico wel heb zelf weinig keuze betreffende dat.

[SBTweaker]

Klopt maar heb je iemand dit zien ontkennen?

[MSalters]

Dat is het natuurlijk niet. Het stikt van de methoden om settings te wijzigen als je eenmaal beheerdersrechten hebt. Je kunt bijvoorbeeld onder je eigen account een service starten, of met behulp van de task scheduler.

De kern van de Windows beveiliging zijn de rechten die een gebruiker heeft. Een heleboel misverstanden zijn gebaseerd op het idee dat de security principal iets anders dan een user is. Programma's bijvoorbeeld zijn geen security principal.

[Armin]

Dit!

UAC is géén security feature!

UAC omzeilen is dus ook géén "exploit".

[HerrPino]

als iemand toegang heeft tot de pc en admin rechten bezit kan hij/zij UAC ook gewoon eenvoudig uitzetten.

[Creesch]

Het gaat dan ook niet om iemand met fysieke toegang tot de pc maar om een applicatie die de boel kan omzeilen zonder dat degene achter de pc het door heeft.
Waarmee dus het hele doel van UAC (voorkomen dat applicaties ongewenst veranderingen aan de pc doorvoeren) teniet wordt gedaan.

[Zezura]

Er is dus een reden waarom je standaard als gebruiker geen admin meer bent. En waarom je alleen via UAC tijdelijk deze rechten kan verkrijgen.

[BRAINLESS01]

Ja, maar als software UAC kan omzeilen werkt dat niet meer. Dat is wat deze onderzoekers nu gedaan hebben. Als jij je machine volledig correct ingesteld hebt, waarbij UAC dus wijzigingen zou moeten blokkeren, dan kunnen deze onderzoekers alsnog wijzigingen doorvoeren. Het programma draait dan wel als admin, ondanks dat de gebruiker daar niet voor kiest en zelfs niet van op de hoogte is.

[Kenhas]

klopt niet. heb je geen admin rechten, dan werkt het niet.

Daarvoor moet de aanvaller echter al toegang hebben tot de pc en beheerdersrechten bezitten

[sdk1985]

klopt niet. heb je geen admin rechten, dan werkt het niet.

[...]

Vertaalfout. De vereiste is een admin account. Dat is vrij vertaald een beheerdersaccount. De rechten popup is nu juist wat wordt omzeild. De rechten heb je niet nodig:

“This attack simply allows an admin user to execute code in a high-integrity context without requiring the user to ‘approve’ the administrative action via the pop-up. It essentially removes the restrictions an attacker has when running under the context of a local administrator,” Nelson told Threatpost. “This is a post-exploitation technique, so an attacker would need to already be on the system.”

[Reactie gewijzigd door sdk1985 op 23 juli 2024 13:39]

[DerDee]

Mis ik iets of heb je voor het aanpassen van het register admin rechten nodig? Als je UAC kunt omzeilen met iets waar je eerst door UAC heen moet dan is het toch een bank kluis kraken als je erin zit? Of kan iemand vertellen wat ik mis?

[thegve]

Het lek zit hem in het mergen(samenvoegen) van de HKCU ( Hyve-Key(?) Current User ) en de HK Current Root.
De root Hyve is bedoeld voor systeembrede instellingen, en de HKCU is voor de Current User bedoeld. HKCU is overigens een link naar HKEY_USERS\<User Security-ID>, en deze word tijdens het aanmelden geladen vanuit het NTUSER.DAT bestand uit het profiel.
In HKCU worden instellingen opgeslagen die alleen voor die gebruiker gelden.
De meeste Microsoft applicaties laden zowel de HKCR als de HKCU, en voegen die dus samen. Op die manier werkt het gros van de domain policies ook, voordat de desktop word geladen worden er een aantal registerwaardes in de HKCU gezet, en die worden door bijvoorbeeld explorer.exe en dus UAC ingelezen.
Omdat NTUser.Dat gewoon in je profiel staat en je daar schrijfrechten op hebt is dit een behoorlijke achilleshiel in het Windows securitymodel, in ieder geval als je je daar niet bewust van bent. Zowel als beheerder als gebruiker regelmatig meegemaakt dat Windows domain-policies meer "doe dat liever niet" is, dan dat het echt geblokkeerd word.

[D11]

Ik denk dat Zezura bedoeld dat je als gewone gebruiker inlogt, en indien nodig dmv UAC je admin account en wachtwoord invult.

Doe ik in ieder geval wel ...

[Armin]

Het gaat dan ook niet om iemand met fysieke toegang tot de pc maar om een applicatie die de boel kan omzeilen zonder dat degene achter de pc het door heeft.

Als je admin rechten hebt als stuk malware kun je op tientalle wijzen dit reeds doen. Dit is enkel methode X+1.

UAC is enkel bruikbaar als laatste laag security feature wanneer op het Vista-stijl "aan" staat. Op Windows 7 en hoger is dat "always notify".

Staat het op een andere stand is het meer een fearture die 'oeps' momenten tegengaat van de gebruiker

[Delay]

Dat is niet het doel van UAC, lees eens https://blogs.msdn.micros...hing/20160816-00/?p=94105

[ikbentomas]

Maar een script wat draait wanneer een dergelijke gebruiker ingelogd is kan dat nu dus ook zonder een UAC popup.

[Proxx]

maar het register moet wel aangepast worden... kan dat wel zonder een UAC popup?
En als je al een keer een UAC Melding krijgt is het toch normaal dat meerdere processen kunnen me liften op dat ene verzoek?
Bijvoobeeld: als ik powershell elevated start kan ik toch ook verschillende dingen installeren met Install-package of choco install ....,...,...

in dat geval vind ik dit maar een slechte vondst, en zie ik niet waarom ze dit zo ingewikkeld aanpakken.

je hebt namelijk al admin rechten gegeven aan iets wat kwaadaardig is.

[Reactie gewijzigd door Proxx op 23 juli 2024 13:39]

[joostiphone]

Op mijn werk heb ik admin rechten op mijn eigen account (en toegang tot de PC), maar ook al heb ik deze admin rechten, door beleid kan ik niet de UAC wijzigen.

Dus ik denk dat het interessante van dit artikel is (en ik ben wel een leek in dit soort dingen) dat buiten het gebruik van DLL bestanden er dus ook een manier is, wat ongewenst gedrag en resultaat is, de UAC gewijzigd kan worden.

[musiman]

Wanneer jij admin rechten hebt op jouw lokale computer die middels Active Directory Group Policies wordt beheerd, dan kan het inderdaad zijn dat Group Policy beleid bij jou de UAC settings op een bepaalde waarde zet.
Echter, als lokale admin kun je de doorvoer van Group Policies eenvoudigweg stoppen en daarmee alle restricties weghalen die via Group Policies werden opgelegd...

Daarom ben ik erg terughoudend met het geven van lokale admin rechten aan medewerkers. Sterker nog, die heb ik (met mijn eigen useraccount) nog niet eens!!!

Nu blijkt ook wel weer, dat het gewoonweg te gevaarlijk is om een gebruiker local admin rechten te geven. Ik kan je legio andere voorbeelden geven, waarom het zo gevaarlijk is.

[jimbo123]

Ja, maar helaas zijn er toch nog veel gebruikers die standaard met admin-rechten op hun systeem werken. Een dergelijke vulnerability wordt dan gewoon toegevoegd aan het lijstje van een exploit-kit en is weer een extra weg voor een virus om actief te worden zonder dat een gebruiker een UAC melding ziet en nog enige kans heeft om alert te worden.

Wel een beetje een issue dus.

[Sebazzz]

Werking van de hack, die niet helemaal goed uit de verf komt in het artikel:
eventvwr.exe zal altijd administrator altijd gestart worden. De event viewer launcher kijkt echter eerst in de vrij aan te passen registry hive van de huidige gebruiker welk commando te starten. Je kan dus dat commando aanpassen.

Dit betekent dus dat je als non-elevated kan aanpassen van een per-definitie elevated proces zal uitvoeren. Vervolgens moet je natuurlijk wel eventvwr.exe uitvoeren. Gezien er naar HKCU zal worden gekeken, zal dit altijd de HKCU zijn van de administrator zodra het proces (eventvwr.exe) gestart is.

[jimshatt]

Als ik het goed begrijp is eventvwr.exe dus zoiets als een setuid proces op Linux die een ander proces spawned met elevated privileges. Als het proces dat gespawned moet worden in een of ander user-writable configbestand of registry key staat kun je dus via die weg een ander proces laten spawnen. Klopt dat een beetje?

Uiteindelijk moet je wel eventvwr.exe uitvoeren maar dat kan ook weer via een ander proces (love.exe als attachment of zo ).

TL;DR: High Ingerity proces Windows == setuid proces Linux?

[MneoreJ]

Een setuid program start altijd als root, ook als het onder een account zonder privileges gestart wordt. Zoiets bestaat niet exact zo in Windows -- je kunt een exe wel markeren als "elevation vereist", maar hij zal dan vragen om te elevaten op het moment dat je start, of niet starten als dat niet mogelijk is. Tenminste -- als je UAC niet instelt op "doe alles maar stil", want dan heb je inderdaad hetzelfde effect dat een exe met elevation automatisch zal elevaten wanneer jij als admin draait. Which is bad, want de executables in Windows zijn niet allemaal zorgvuldig doorgekamd op veiligheid onder die configuratie, zoals setuid binaries op Linux dat (hopelijk) wel zijn.

UAC kun je zien als de inverse van sudo -- in plaats van te beginnen met een normaal account en dan wanneer gewenst naar root te elevaten begin je met een admin account dat privileges dropt en wanneer gewenst weer verkrijgt. UAC is makkelijker werken voor de onschuldige eindgebruiker, maar ook inherent onveiliger. Als je als gewone gebruiker inlogt en het instelt op "always notify" heb je ongeveer hetzelfde als wanneer een Linux desktop detecteert dat je voor een operatie root moet wezen en sudo voor je start.

[batjes]

UAC kun je zien als de inverse van sudo -- in plaats van te beginnen met een normaal account en dan wanneer gewenst naar root te elevaten begin je met een admin account dat privileges dropt en wanneer gewenst weer verkrijgt. UAC is makkelijker werken voor de onschuldige eindgebruiker, maar ook inherent onveiliger. Als je als gewone gebruiker inlogt en het instelt op "always notify" heb je ongeveer hetzelfde als wanneer een Linux desktop detecteert dat je voor een operatie root moet wezen en sudo voor je start.

Nee, hoe jij het brengt, op die manier is UAC juist erg vergelijkbaar als SUDO, aangezien je gewoon een standard user bent. Dat de account volgens de user account settings een admin heet, betekend niet dat de user account een admin is. Er is -by default- maar 1 "admin" en dat is Administrator, er is maar 1 root, en dat is SYSTEM.

Maar goed, UAC lijkt niet op sudo, niet inverse, maar ook niet op dezelfde manier. De werking (of het resultaat) is wel vergelijkbaar.

En het verschil tussen always notify en "notify when apps make changes" is dat met always notify hij inderdaad bij elke user actie moeilijk komt doen i.p.v. verificieëren d.m.v. hardware inputs (en nog wat zaken) om de gebruiker niet al te veel zinloos tot last te zijn. Voor een stricte UAC vergelijkbaar met jou sudo anologie pak de RTM Vista, constant lastig gevallen door UAC schermpjes is juist alles behalve veilig, want het werkt dan averechts.

Tevens is UAC elevation geen admin rechten elevation, het zijn pseudo admin rechten. Het is wel elevated, maar het komt niet in de buurt van de rechten die een default administrator account heeft (laat staan een root achtige account zoals SYSTEM)

Orginele link lijkt niet meer te werken, dus
http://webcache.googleuse...&cd=4&hl=nl&ct=clnk&gl=nl
voor leesvoer

[Reactie gewijzigd door batjes op 23 juli 2024 13:39]

[MneoreJ]

Nee, hoe jij het brengt, op die manier is UAC juist erg vergelijkbaar als SUDO, aangezien je gewoon een standard user bent.

Alleen als je er ook echt een bent (wat dus de aanbevolen, veilige opstelling is, en waarbij UAC je dus zal vragen om de credentials van een volwaardige administrator). Als je lid bent van Local Administrators ben je wel degelijk een administrator, maar vanaf Vista werk je by default onder een token zonder die adminrechten. Dat lijkt heel erg op een gewone user zijn, maar is niet precies hetzelfde. Het token met alle rechten bestaat ook nog gewoon en is vrij eenvoudig toegankelijk, hoewel niet via de UI zonder de elevation dus.

Tevens is UAC elevation geen admin rechten elevation, het zijn pseudo admin rechten.

Wat zijn "pseudo-admin rechten" volgens jou? Dat staat namelijk echt niet in het gelinkte document. Wanneer je met UAC elevate wordt de taak uitgevoerd onder je admintoken. Er is geen onderscheid tussen administrators onderling. De default "Administrator" is niet bijzonder. SYSTEM is wel bijzonder in die zin dat het dingen kan die een administrator standaard niet kan, maar omdat een administrator nu eenmaal volledig beheer heeft kunnen die rechten wel toegekend worden (al was het maar door een SYSTEM proces over te nemen). Je kunt een administrator veel beter als root beschouwen dan als iets anders, dat komt qua veiligheid namelijk het best in de buurt. Wat je by default niet kan, daar kun je jezelf gewoon rechten voor geven.

Uitzondering hierop zijn de DRM-achtige zaken die er sinds Vista ingebouwd zijn waarbij zelfs administrators bepaalde dingen niet meer mogen. Ook die zijn volgens mij te omzeilen, maar daarbij moet je echt absurd veel moeite doen.

[batjes]

Je hebt inderdaad als "admin" user 2 tokens, administrator account heeft maar 1 user token. De "normale" admin user heeft zoals je opmerkt een token zonder admin rechten, en 1tje voor het elevaten.

Wat ik bedoel met psuedo admin rechten, een UAC elevated process krijgt -voor een deel- zijn eigen gevirtualiseerde "admin omgeving" binnen Windows, niet zoals de Administrator account welke gewoon direct overal access toe heeft. Het UAC process krijgt zijn eigen gevirtualiseerde registry en zo laat Windows het denken dat het rechten heeft in de system32/syswow64 mappen (wat niet zo is). Vrijwel alle "admin rechten"die het process krijgt, krijgt het niet echt, vandaar de pseudo, het krijgt eigenlijk alleen "echte" admin rechten in mappen als program files e.d.

Die "DRM" is zelfbescherming van het OS. Waar je default als Administrator niet bij kan, heb je niets te zoeken tenzij je weet wat je doet, en als je weet wat je doet is die limitatie omzeilen appeltje eitje. Want zoveel moeite is het niet (paar klikjes en ff wachten)

[MneoreJ]

Oh, je bedoelt registry virtualization. Zeg dat dan gelijk.

Dat is geen UAC-beperking maar een compatibiliteitshack. Applicaties die UAC-aware zijn declareren juist requestedExecutionLevel en worden daarmee uitgesloten van virtualisatie, per de docs.

[R4gnax]

Tevens is UAC elevation geen admin rechten elevation, het zijn pseudo admin rechten. Het is wel elevated, maar het komt niet in de buurt van de rechten die een default administrator account heeft

Uhm... UAC implementeert gewoon split-token permission sets, hoor. Dat betekent dat een local admin account met twee permissiesets werkt; een gestripte standard-user set en een set met de volledige normale permissieset van een normale local admin account.

Een local admin heeft na UAC elevation evenveel rechten als wanneer UAC uit zou staan.

[Sebazzz]

Eventvwr is op moment van starten zelf al elevated. Echter, wát hij moet starten is te overschrijven in de HKCU van de administrator. Om dat te overschrijven is geen elevation nodig. De volgende keer dat de event viewer launcher gestart wordt, zal niet de event viewer starten maar het malafide commando.

[jimshatt]

Ja precies, dat is ook zo bij setuid processen op Linux. Degene die het commando uitvoert hoeft niet eens rechten te hebben, maar het proces dat een setuid flag heeft draait elevated. En kan dus elevated processen spawnen.

De fout zit hem er dus in dat een elevated proces waar geen UAC voor nodig is omdat het als High Integrity gemarkeerd is, het te spawnen proces uitleest uit een user-writable configuratie (hier de HKCU van de administrator).

[GNID]

Nee, zo werkt het dus niet!!
(of ik heb de verkeerde decryptie sleutels gebruikt voor je bericht; echt helder is het niet)

Eventvwr.exe start eventvwr.msc. In de filetypes wordt gekeken wat er met .msc bestanden moet gebeuren. Dit wordt achtereenvolgens onder HKCU en HKLM gezocht (samengevoegd onder HKCR).
EDIT: Voor de goede orde: dit wordt gezocht in de HKCU van de user die eventwr.exe start
Omdat je zelf invloed hebt op het CurrentUser deel, kun je ipv de standaard mmc.exe een willekeurig ander programma (laten) starten.
Tot zover redelijk rechttoe-rechtaan.

Maar... als je in de code van eventvwr.exe kijkt, zie je dat in het manifest staat:
[code]
®  M U I <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<!-- Copyright (c) Microsoft Corporation -->
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3" manifestVersion="1.0">
<assemblyIdentity
version="5.1.0.0"
processorArchitecture="x86"
name="Microsoft.Windows.Eventlog.EventVwr"
type="win32"
/>
<description>Event Viewer Snapin Launcher</description>

<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
<requestedPrivileges>
<requestedExecutionLevel
level="highestAvailable"
uiAccess="false"
/>
</requestedPrivileges>
</security>
</trustInfo>
<asmv3:application>
<asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
<autoElevate>true</autoElevate>
</asmv3:windowsSettings>
</asmv3:application>
</assembly>

(
[/code]
(dat kun je trouwens simpeler en netter bekijken met SigCheck van SysInternals)

En het draait nu om die highestAvailable

Als jij als admin aangelogd bent, wordt het gewenste programma gestart als administrator (zonder dat UAC iets van zich laat horen).
Als jij ingelogd ben als "Jan Klant-In 't Pand", is highest available gewoon user-level en zal eventvwr dus gestart worden met de credentials van Jan Klant.

[Reactie gewijzigd door GNID op 23 juli 2024 13:39]

[SunnieNL]

Daarom staat er dus dat je al local admin moet zijn om deze hack uit te voeren. En dus acht ik, net als Microsoft, de kans klein dat deze 'exploit' van de beheertools misbruikt gaat worden.
(Je hebt immers al een groter probleem)

[GNID]

Precies! (had je bericht niet gezien voordat ik postte).
Kanttekening: simpele exploits bestaan bijna niet meer; het is altijd een gecombineerde aanval. Wrik een steen los, waardoor je bij plankje kunt, waardoor .... ... je het raam kunt openen.

[R4gnax]

Daarom staat er dus dat je al local admin moet zijn om deze hack uit te voeren. En dus acht ik, net als Microsoft, de kans klein dat deze 'exploit' van de beheertools misbruikt gaat worden.
(Je hebt immers al een groter probleem)

En; hoeveel mensen gebruiken UAC i.c.m. een admin account voor hun dagelijkse thuisgebruik? Wat zelfs in Windows 10 nog steeds de factory-default is?

Want die zijn dus per definitie allemaal vatbaar voor deze issue.

[Reactie gewijzigd door R4gnax op 23 juli 2024 13:39]

[SunnieNL]

nee, je doet de aanpassing met een elevated user..
Uit het artikel:
[quot] Nelson said that Windows admins can protect their systems against this attack by setting the UAC level to Always Notify, or by removing the current user from the Local Administrators group. [\quot]

De user moet dus al local admin zijn.

Enfin, makkelijk te fixen voor MS door eventvwr alleen te laten kijken naar hklm classes root en niet eerst naar hkcu classes root

[R4gnax]

nee, je doet de aanpassing met een elevated user..
Uit het artikel:
~[quot] Nelson said that Windows admins can protect their systems against this attack by setting the UAC level to Always Notify, or by removing the current user from the Local Administrators group. [\quot]

Fout. De exploit zelf komt neer op het aanpassen van één enkele registry waarde in het HKEY_CURRENT_USER segment van het registry (namelijjk HKCU\Software\Classes\mscfile\shell\open\command). Daar heb je geen volledige admin rechten voor nodig.

Het UAC level op Always Notify instellen is een mitigation omdat de gebruiker dan de UAC prompt al bij het lanceren van eventvwr.exe gaat krijgen, nog voor de exploiteerbare registry-keys om de hoek komen kijken.

Op lagere UAC levels zijn er bepaalde trusted binaries (waaronder eventvwr.exe) die op een white-list staan om zonder prompt te mogen lanceren. Task scheduler is er ook zo één. Disk cleanup ook. (En in elk geval voor die drie zijn er ook exploits die kunnen in de praktijk al gebruikt worden voor UAC bypasses.)

De reden dat deze aanval 'post-exploitation' is, is omdat een aanvaller al als local user ingelogd moet zijn op het systeem (specifiek: als de token-split adminstrator account die geexploiteerd moet gaan worden). Daarvoor heb je al een eerdere exploit nodig.


Overigens is UAC op 'always notify' zetten ook een wassen neus.

Het zorgt er voor dat eventvwr.exe een UAC prompt gaat geven wanneer het gelanceerd wordt, waardoor het opvalt als de aanvaller dit doet. Maar een aanvaller kan ook gewoon het mscfile shell open command aanpassen om eerst een admin-level powershell te starten en daarna de normale event viewer msc te lanceren, waardoor het helemaal niet opvalt als je de gebruiker zelf zo ver kunt krijgen om event viewer te openen.

Bijv door met wat social engineering skills powershell een waarschuwings- of error dialog te laten tonen die de gebruiker aanspoort om event viewer te starten om een volledig rapport v/d error te lezen.

[Reactie gewijzigd door R4gnax op 23 juli 2024 13:39]

[MneoreJ]

Daarvoor moet de aanvaller echter al toegang hebben tot de pc en beheerdersrechten bezitten.

Zoals Raymond Chen zegt: het soort vulnerability waarvoor je eerst al binnen moet zijn ("the other side of this airtight hatchway").

UAC kunnen omzeilen als beheerder is altijd mogelijk, alleen niet altijd makkelijk. Als je je druk maakt om security moet je inloggen als gewone gebruiker, en in de UAC prompts met een ander account inloggen dat wel beheersrechten heeft. Dit werkt al in W7 als een zonnetje. Maar ja, dan moeten mensen wachtwoorden gaan onthouden enzo... niet te verkopen aan de gewone gebruiker.

Het is mogelijk om deze methode te voorkomen door UAC in te stellen op 'Always notify', aldus de onderzoekers.

En het laatste restje interesse dat je nog zou kunnen hebben voor dit grapje is nu hopelijk helemaal verdwenen.

UAC is altijd bedoeld geweest als overgangsmaatregel om mensen niet als admins ingelogd te laten zijn maar netjes te werken met aparte accounts, één zonder rechten, één met. Het is géén essentiële beveiliging. UAC gebruiken met één account, dat admin is, en het dan ook nog niet instellen op "always notify" is gewoon onveilig. Dit is hooguit een illustratie daarvan. Dat is ook de reden dat MS geen hoge prio geeft aan UAC "veiliger" maken -- veiliger is niet continu als beheerder ingelogd te zijn, en niet UAC gebruiken als "soort van" manier om dat voor elkaar te krijgen.

Ja, dit moet uiteindelijk toch wel gefixt worden, wegens voornoemde weerzin van gebruikers om wachtwoorden te moeten gaan tikken voor acties die beheersrechten vereisen. Maar qua veiligheid is dit maar een voetnootje. De echte les is niet "UAC moet gefixt worden" maar "stop met het gebruiken van lapmiddeltjes".

[SunnieNL]

Always notify is de Vista instelling van uac. Dan wordt je knettergek van de popups (bv voor instellen display)

Wat Microsoft moet doen is beheerderstools die als high priority proces draaien niet te laten kijken naar hkcu classes root maar alleen naar hklm classes root. Nu kijken ze eerst naar de hkcu waardoor je de waarde in de hklm classes root kan overschrijven.

De always notify in de uac voorkomt het starten van regedit.

[Reactie gewijzigd door SunnieNL op 23 juli 2024 13:39]

[MneoreJ]

Ik draai onder W7 en W10, heb always notify aanstaan op beiden, en tot nu toe houdt mijn geestelijke gezondheid het prima uit... maar dat hangt misschien ook van je workflow af. Over Vista kan ik geen uitspraken doen.

[mkools24]

Ik word op linux soms al gek van sudo typen heel de tijd, dus dan su ik liever naar root maar dat geldt dan enkel voor die ene terminal. Bij Windows gebruik ik vaak RunAs, op het werk dan waar ik als normale user inlog.

[sfranken]

Dat ligt er dan maar net aan hoe je sudo is ingesteld. Met een lange(re) timeout voorkom je dat je elke X tijd je password in moet geven. Snelle howto:

1) Open een terminal en voer "visudo" uit (als root)
2) Zoek de regel op met "Defaults env_reset" en pas deze aan naar het volgende:
"Defaults env_reset,timestamp,timeout=30". De 30 is hier het aantal minuten, maak hiervan wat je leuk vind. Als je 0 invult krijg je bij elk commando een sudo prompt, met -1 nooit (niet echt aan te raden)
3) Opslaan
4) ...
5) WINST!

[mkools24]

Nice die -1 klinkt wel goed eigenlijk maar bijv. 4 uur ofzo zou al een stuk beter zijn, dank voor de tip!

[MneoreJ]

Dat kan ook. Zit een klein risico in in de vorm van shatter attacks (processen zonder privileges die de processen met hoge privileges manipuleren via de gedeelde windowing). Daar is wel beveiliging tegen maar die is niet waterdicht (op Windows althans, geen idee hoe X daarmee omgaat). Als je een compleet aparte (tekst) terminal gebruikt of (onder Windows) een aparte sessie ben je veilig, maar dat is natuurlijk niet veel praktischer dan sudo/UAC gezien het voortdurende omschakelen (hoewel het wel een wachtwoord scheelt).

[Reactie gewijzigd door MneoreJ op 23 juli 2024 13:39]

[MSalters]

Jouw idee kan contra-productief zijn. Als je als Administrator software installeert onder je eigen account, in plaats van systeem-breed (wat security-wise aan te raden valt - admin software is niet bedoeld voor gewone gebruikers) dan is die software geïnstalleerd in HKCU van de Administrator account., niet in HKLM. En aangezien jij HKCU wil negeren zal die software dan onbruikbaar zijn.

Ikzelf zou *.msc toevoegen aan de lijst van hardcoded file extensies, en álle Registry entries ervoor negeren - of het nu in HKLM of HKCU is. Dát is de werkelijke problematiek hier, de basisfunctionaliteit van Windows zou niet afhankelijk moeten zijn van een (foute) configuratie.

[R4gnax]

Ikzelf zou *.msc toevoegen aan de lijst van hardcoded file extensies, en álle Registry entries ervoor negeren - of het nu in HKLM of HKCU is. Dát is de werkelijke problematiek hier, de basisfunctionaliteit van Windows zou niet afhankelijk moeten zijn van een (foute) configuratie.

De werkelijke problematiek is dat eventvwr.exe niets anders is dan een stub die gebruik maakt van het standaard shell open commando om het commando dat geassocieerd is met .msc files uit te voeren.

eventvwr.exe en andere auto-elevated system tools zouden niet files via een shell open commando moeten openen met hun op dat moment door de gebruiker geassocieerde programma, maar een directe hardcoded shell exec moeten draaien van het programma dat ze verwachten te gebruiken met het file dat geopend moet worden als argument.

[Reactie gewijzigd door R4gnax op 23 juli 2024 13:39]

[irritantrotjoch]

Maar als je zelf fisiek achter een pc zit om te rommelen dan boeit die always notify boodschap toch niet, of je zet hem zelf uit.

[Wolfos]

Daarvoor moet de aanvaller echter al toegang hebben tot de pc en beheerdersrechten bezitten

Lijkt me meer een feature dan een exploit. Natuurlijk kan de beheerder UAC uitzetten.

[CAPSLOCK2000]

Het is de grote wisseltruc maar dan voor hackers.
Ze verleiden je om toestemming te geven voor A, maar via deze hack kunnen ze ook B doen zonder dat je het merkt.

[afterburn]

Je kunt vragen stellen bij de nuttigheid van deze hack: aangezien de machine al gecompromitteerd moet zijn met toegang als administrator is de machine al vogelvrij. Daarnaast moet je eerst langs UAC om de registry te kunnen editen om zo de UAC te omzeilen. Het lijkt me in dat geval makkelijker om gewoon de code uit te voeren die je wilt uitvoeren.

[R4gnax]

Daarnaast moet je eerst langs UAC om de registry te kunnen editen om zo de UAC te omzeilen.

Dat kon je in Windows 8 en hoger (ja; ook Windows 10) al via een exploit in de task scheduler die MS nooit gefixed heeft.

Deze is echter afhankelijk van zaken die bij user logon plaats moeten vinden na een reboot, en is dus niet echt praktisch voor on-demand inbraak. Deze oude, reeds bekende exploit kan vanaf nu alleen wel gebruikt worden om eenvoudig de registry keys voor deze nieuwe exploit te tunen en zo de machine klaar te stomen voor on-demand herhaalbezoekjes.

[Reactie gewijzigd door R4gnax op 23 juli 2024 13:39]

[floorcleaner]

Vermoedelijk bedoelen ze als je toegang hebt zonder admin rechten... bv via een andere user ?
Anders zie ik ook het nut niet ?

[Reactie gewijzigd door floorcleaner op 23 juli 2024 13:39]

[Yoshi]

neen, dat is ook wat ze zeggen, je moet al een gebruiker hebben met admin rechten (vandaar ook post-exploitation hack)

[the_stickie]

Microsoft zal dit niet als exploit bestempelen, simpelweg omdat een admin sowieso al 'alles' kan, ook processen pigggybacken.

Voor indringers is dit enkel nuttig om geen alarmbellen te laten afgaan door met settings te gaan rommelen en toch scripts uit te kunnen voeren die om een of andere reden elevated moeten draaien.
Ook in zo'n scenario kan je stellen dat de indringer al lang gedetecteerd had moeten worden en dat strikte security auditing alsnog (zouden) moet kunnen detecteren dat iemand inlogt en bepaalde zaken leest of kopieert. Ik vind het dus ook een 'minor issue'...

[jimh307]

Eventvwr.exe moet zijn: eventvwr.msc. Dat kan belangrijk zijn omdat anders wordt gesuggereerd dat het een exe bestand is waarmee je een exploit via exe voorsteld. Msc bestanden bevatten zelf geen uitvoerbare code.

[_XipHiaS_]

Everyone knows the UAC is DOOMed