Ongepatchte bug in Windows blijkt ook local privilege escalation te zijn

Een beveiligingsonderzoeker heeft details gepubliceerd over een kwetsbaarheid in Windows waarmee een local privilege escalation kan worden uitgevoerd. Die was doorgegeven aan Microsoft, maar blijkt nu ernstiger te zijn dan gedacht. Er is een onofficiële patch beschikbaar.

De bug staat bekend als CVE-2021-24084. Die werd ontdekt door beveiligingsonderzoeker Abdelhamid Naceri, die er in juni details over publiceerde. Aanvankelijk leek het te gaan om een bug waarmee aanvallers bestanden konden lezen waar ze geen rechten toe hadden. Naceri publiceerde de details daarover omdat het lek relatief onschuldig was, maar ook nadat hij geen reactie had gekregen van Microsoft dat beloofde het lek te repareren.

Nu zeggen beveiligingsonderzoekers dat de kwetsbaarheid ernstiger blijkt dan gedacht. Onderzoekers van 0patch beschrijven in een blogpost dat de bug het niet alleen mogelijk maakt bestanden uit te lezen, maar ook om lees- en schrijfpermissies op een computer uit te delen via dezelfde kwetsbaarheid. Dat kan in combinatie met CVE-2021-36934, een lpe-kwetsbaarheid in de Registry die ook wel bekendstaat als HiveNightmare. Een aanvaller die toegang heeft tot de bug om bepaalde bestanden uit te lezen, kan die bug ook misbruiken om adminrechten op een systeem te krijgen.

0patch heeft details over de kwetsbaarheid online gezet. Het bedrijf heeft Microsoft niet op de hoogte gebracht, omdat Abdelhamid Naceri dat dus eerder dit jaar al deed. Wel heeft 0patch een eigen, onofficiële micropatch uitgebracht die het probleem moet fixen. Die is er voor Windows 10-versies 21H1, 20H2, 2004, 1909, 1903 en 1809. Windows 10 1803 en ouder zijn niet getroffen.

Door Tijs Hofmans

Nieuwscoördinator

30-11-2021 • 08:19

33

Reacties (33)

33
33
27
2
0
3
Wijzig sortering
Het is dus eigenlijk alleen mogelijk door een andere kwetsbaarheid te misbruiken. Het is dus niet 'ernstiger dan gedacht'.
De beveiligingsonderzoeker doet dat nu zo voor komen, nadat hij op ramkoers is tegenover Microsoft na gesteggel over de hoogte van de bug bounty.
CVE-2021-36934 is in juli/augustus al gedicht, dus al je die updates wel hebt geïnstalleerd zal deze CVE-2021-24084 ook niet voor local privilege escalation kunnen zorgen.
Hmm. Patches voor windows, maar niet van microsoft zelf. Glad ijs?
Bor Coördinator Frontpage Admins / FP Powermod @Jelster30 november 2021 08:28
In ieder geval iets wat er in diverse bedrijven en overheidsinstanties niet doorheen komt. Het installeren van een niet officiële patch is altijd een risico afweging. Het lek moet wel heel erg zijn willen vele mensen aan de gang gaan met niet officiële aanpassingen aan het systeem.

Nu werkt een "patch" bij 0patch wat anders dan een officiele patch. 0patch werkt met een agent op de machine welke de lopende processen in de gaten houdt. Zodra er een proces is gevonden waar 0patch een patch voor heeft wordt dat proces in memory gepatched zonder het proces te verstoren (althans dat is de bedoeling). 0patch past geen executable bestanden aan; het gaat dus uitdrukkelijk om "in memory" patching.

Aan het draaien van dit soort software zelf kleven ook weer nadelen; hoeveel garantie heb je dat het systeem en de lopende processen echt geen nadeel ondervinden. Is de patch afdoende getest? Werkt het in memory patchen van lopende processen echt zonder hinder? Ik kan mij voorstellen dat het ene proces kwetsbaarder is dan het andere op dit punt. Elke agent is er doorgaans 1 te veel. Hoe meer software hoe meer kans op kwetsbaarheden.

Meer info: https://0patch.com/ (onder How does it work?).

Ik moet overigens het eerste bedrijf waar dit wordt gebruikt nog tegenkomen.

[Reactie gewijzigd door Bor op 25 juli 2024 01:29]

Nu werkt een "patch" bij 0patch wat anders dan een officiele patch. 0patch werkt met een agent op de machine welke de lopende processen in de gaten houdt. Zodra er een proces is gevonden waar 0patch een patch voor heeft wordt dat proces in memory gepatched zonder het proces te verstoren (althans dat is de bedoeling). 0patch past geen executable bestanden aan; het gaat dus uitdrukkelijk om "in memory" patching.
Een constant draaiend proces dat dit mogelijk maakt vergroot natuurlijk ook het aanvalsoppervlak. In de afweging moet meegenomen worden of dit soort zaken de situatie juist niet erger maakt.

[Reactie gewijzigd door The Zep Man op 25 juli 2024 01:29]

Wij hebben het eerder al gebruikt bij overnames waar er enkele lijken uit de kast vallen en je zsm iets tijdelijk wil oplossen/verbeteren zonder grote wijzigingen door te voeren.
Op dat vlak voelt in memory patching een beetje aan als magie. De agent draait en *poef* alles is zogezegd gefikst :)
Uiteraard blijven de vulnerabilities wel nog gevonden worden door scanners aangezien die meestal naar file versies kijken tegen over een echte penetration test.
In memory patching; Vindt de virusscanner daar niets van?
In de open-source community is dit vaker gebeurt (maar dan bijvoorbeeld op basis van pull-requests). Misschien is het een mooi moment voor Microsoft om eens te overdenken of ze dit niet een viable-product vinden (andere bedrijven patches laten schrijven, en zelf doen waar je goed in bent).
Raar is dat MS nog steeds geen Developer en later ook een Publiek Beta systeem heeft.

Lijkt mij dat dit soort fouten eerder zichtbaar worden.
Bedoel je zoiets?

Sommige fouten zijn natuurlijk in meeste soorten gebruik geen probleem waar je tegenaan loopt, dat valt niet zo op. Pas als iemand actief op zoek gaat naar manieren om systeem te misbruiken blijkt soms dat er dingen mogelijk zijn die niet de bedoeling waren. Echte UX-fouten vallen in zo'n beta-systeem wel op, dit soort bugs moet je het volgens mij toch vaker van dergelijke initiatieven hebben - al dan niet binnen de context van die insider-builds.
Ik denk niet dat je met beta systemen dit soort logic bugs gaat ondervangen.
Zeker met developers niet. Bij developers loop je tegen echte bugs aan, zaken die niet of deels niet functioneren volgens documentatie.
Maar developers zijn voornamelijk bezeg met het maken van nieuwe code en zijn niet op zoek naar security bugs.
Het grote publiek zie ik ook al als een bron die veel informatie zal opleveren aangaande security problemen. Het moet wel een heel opvallend ding zijn als jan met de pet iets wil opmerken aangaande security.
Dit soort hele subtiele zaken, zeker diegenen die "erger" worden op een ongepatchted systeem gaat een gewone gebruiker nooit ontdekken.

Dit soort zaken wordt alleen maar ontdekt door mensen die er heel veel verstand van hebben en heel veel ervaring hebben met het specifiek opzoeken van (security) issues. Veelal zijn dat mensen die voor bedrijven werken en er financieel gewin bij hebben zo ook bij het commercieel bedrijf 0patch.
Andere bedrijven patches laten schrijven die dat doen via reverse engineering en vervolgens alleen dat onderdeel testen en niet kijken of er dan ergens anders in windows iets omvalt?
Denk dat Microsoft op zich iets sneller weet of een code op plek A veranderen iets zou kunnen betekenen voor plek B.

Nou brengt 0patch vaker micro patches uit (zie ze op de een of andere manier deze maand ineens veel vaker in mijn tijdlijnen op verschillende plekken langs komen). Probleem is wel dat zij dll's patchen van Windows zelf. Dat houdt in dat je op een gegeven moment tegen een probleem kan aanlopen als Windows zelf die DLL ook wil patchen en de basiscode niet meer klopt waardoor integratie van de dll faalt en Windows zijn patch er weigert overheen te zetten. Dan moet je eerst een repair/reset van Windows doen wil de boel weer gaan werken.
0patch past geen bestanden aan maar patched een reeds in het geheugen geladen dll of exe.
0patch kan geen bestanden op disk aanpassen want ze hebben geen signing key.
Windows bestanden kunnen niet beschadigt worden door 0patch.
Hoe moet ik dat zien? Als de dll in kwestie wordt opgeroepen dan zorgt 0Patch ervoor dat de door hun gepatchde dll gebruikt wordt?
Dat is misschien nog wel gevaarlijker. Sommige malware en exploits gebruiken dezelfde methode. Bij een beetje security komt er geen software op een machine dat in memory code van andere applicaties gaat overschrijven. Ik moet er niet aan denken wat dat allemaal met problemen met zich mee kan brengen.
Bor Coördinator Frontpage Admins / FP Powermod @SunnieNL30 november 2021 12:57
Probleem is wel dat zij dll's patchen van Windows zelf. Dat houdt in dat je op een gegeven moment tegen een probleem kan aanlopen als Windows zelf die DLL ook wil patchen en de basiscode niet meer klopt waardoor integratie van de dll faalt en Windows zijn patch er weigert overheen te zetten.
Dit is helemaal niet waar. 0patch werkt uitsluitend "in memory". Er worden geen bestanden aangepast op het systeem waar het op draait buiten dat je een agent moet installeren. Zie ook Bor in 'nieuws: Ongepatchte bug in Windows blijkt ook local privilege escalat...

[Reactie gewijzigd door Bor op 25 juli 2024 01:29]

Dit in combinatie met Naceri's eerdere 0-day is toch een beetje te toevallig. Gewoon een verlengstuk van de ordinaire bedreiging van de vorige keer.

Meer geld of meer irresponsible disclosure.

[Reactie gewijzigd door Pinkys Brain op 25 juli 2024 01:29]

In juni zijn de bevindingen gedeeld met Microsoft. Microsoft heeft dus bijna vijf maanden de tijd gehad dit op te lossen.
In juni was het gemeld als onschuldig en nu op een verdacht toevallig moment gechained met een andere bug (die volgens de post van SunnieNL hieronder wel gefixed is overigens) om hem ernstiger te maken. Ik geloof niet zo in toeval in deze.
Het lezen van bestanden waartoe een aanvaller geen rechten heeft is niet onschuldig.
Maar dat is dus het probleem bij MS... Ze laten dingen liggen die op dit moment nu meteen direct niet gevaarlijk lijken. Of fiksen dingen op een manier die de proof-of-concept stopt, maar geen complete oplossing is.

Bij betere mentaliteit zou dit dus niet gebeurd zijn. Of hadden ze zelf gezocht of de bug niet misschien gevaarlijker was dan gemeld. En hadden ze de bounty zelfstandig verhoogd nadat ze zelfstandig het grotere belang ontdekt hadden.
Als het triage systeem bij Microsoft niet optimaal is is dat een probleem, alleen niet het probleem waar ik het over wou hebben. Daar werd al genoeg over gepraat.

"security researchers" die zo gauw ze ontevreden zijn over het geld overstappen van responsible disclosure naar schade veroorzaken is ook een probleem.
Ik geloof niet dat veiligheid echt prioriteiten heeft bij MS en dat het ze extra omzet levert als er weer iets mis gaat.
Waarom wordt er door dit security bedrijf verwijzen naar de HiveNightmare terwijl daar al in juli een patch voor is verschenen? Als die pach nog steeds niet op je systemen staat heb je wel een groter probleem in je gehele patch proces.
Er wordt naar verwezen als voorbeeld omdat combinaties van verschillende findings een enkele finding een stuk ernstiger kan maken dan dat het op het eerste gezicht lijkt.
Waarom word Windows 10-versies 21H2 niet genoemd, of is het daar dan wel gefixed?

Of is 20H2 een typo?

[Reactie gewijzigd door matthys70 op 25 juli 2024 01:29]

Two conditions need to be met in order for the local privilege escalation to work:
  • System protection must be enabled on drive C, and at least one restore point created. Whether system protection is enabled or disabled by default depends on various parameters.
  • At least one local administrator account must be enabled on the computer, or at least one "Administrators" group member's credentials cached
Local privilege dingetje… klinkt weer als een storm in een glas water en een hoop aandacht voor niks. Onofficiële patches…euhm…no thx :) dat kan 1000x goed gaan, tot het breekt en dan is de oplossing mogelijk erger als de kwaal.
Bor Coördinator Frontpage Admins / FP Powermod @IrBaboon7930 november 2021 09:33
Local privilege dingetje… klinkt weer als een storm in een glas water en een hoop aandacht voor niks.
Waarom is dat in jouw ogen zo? Dit kan zeker in bv een zakelijke omgeving voor de nodige impact zorgen. De beveiliging is zo sterk als de zwakste schakel.
Vanwege ‘local’. Remote is een stukje vervelender maar local is over het algemeen een vector die juist in een bedrijf vrij goed kunt afvangen door fysieke security aan de ‘deur’: dwz: medewerkers locken hun systemen en laten geen random personen binnen. Dan heb je nog een paar andere vectoren maar dan moet je (= de medewerker zelf) gericht gaan zoeken om het te kunnen exploiteren…dat zijn dan fijne medewerkers iig.

Bedrijven zullen iig geen onofficiële patches gaan draaien want dat gaat tegen hun support contracten in…
Insider threat is al een paar jaar verantwoordelijk voor 1/5e van de cyber security incidenten.

Niet echt een storm in glas water als je het mij vraagt en steeds meer bedrijven realiseren zich dat gelukkig. Een third part patch installeren op dit specifieke probleem op te lossen zou ik dan ook weer niet doen.
En misschien is een aanvaller al binnen op je systeem, kan hij alleen niets omdat de gebruiker geen admin is op de machine, maar ineens, *poof* is hij dat wel.
Daar ben ik het niet mee eens. Als er een mail word gestuurd met een link naar een unknown website met daarop een excel bijlage met macro die via een obfuscated weg een payload download die deze local priviledge escalation uitvoert, dan heb je dus via 1 simpele e-mail en 2 klikken van een eindgebruiker die denkt goed te doen, admin rechten op een systeem (en wellicht zelfs domain).
Local is iets anders dan on-premise. Als je op een VM werkt, dan ben je op afstand aan het werk, maar wel degelijk local. Verplaats dat naar een omgeving met VDI op basis van Windows 10 (b.v. in Azure of VMware Horizon) en j hebt nog steeds local, maar dan op afstand.

Op dit item kan niet meer gereageerd worden.