Lokale Windows-gebruikers kunnen Registry-file met adminwachtwoordhashes inzien

Een kwetsbaarheid in Windows maakt het mogelijk voor lokale gebruikers om een Registry-file op te vragen met daarin hashes en securitytokens van admin-gebruikers. Door een verkeerd geconfigureerde Access control list kunnen gebruikers bij info in de Security Account Manager.

De bug kan leiden tot een local privilege escalation, waarbij aanvallers lokale rechten kunnen verheffen tot adminrechten. De bug werd ontdekt door beveiligingsonderzoeker Jonas Lykkegaard, die naar Windows 11 keek. Later bleek dat de bug ook in Windows 10 uit te buiten was. De bug bestaat daar al jaren, maar was tot nu toe nooit opgevallen.

De kwetsbaarheid zit in de Security Account Manager. Daarin worden hashes opgeslagen van de wachtwoorden van alle gebruikers op een systeem. Lykkegaard ontdekte dat in Windows 10 en Windows 11 die files in de Registry toegankelijk zijn met Read-privileges voor alle gebruikers op een systeem. Dat wordt in eerste instantie wel tegengehouden, doordat Registry-bestanden in gebruik zijn door het systeem en dus niet kunnen worden gekopieerd. Als Volume Shadow Copies zijn ingeschakeld, kan dat echter worden omzeild doordat een aanvaller dan een snapshot van de Registry-files kan maken.

Microsoft heeft de kwetsbaarheid inmiddels erkend. Het bedrijf heeft die geregistreerd als CVE-2021-36934. De bug kan worden uitgebuit op in ieder geval Windows 10 1809 en nieuwere versies. Vanaf die versie veranderde Microsoft de permissies voor gebruikers. Er is nu nog geen patch beschikbaar, maar Microsoft noemt wel een work-around. Admins kunnen toegang tot %windir%\system32\config uitzetten en bestaande System Restore-opslagpunten verwijderen.

Reacties (62)

[mvrhrln]

Beetje Telegraaf denken met de kopteksten ?

"Lokale Windows-gebruikers kunnen Registry-file met adminwachtwoorden inzien"
wordt: daarin hashes en security tokens van admin-gebruikers

Nogal een verschil.

Admin-edit:

Bedankt voor je feedback. Commentaar voor de redactie hoort echter thuis in Geachte Redactie. Hier staat het de inhoudelijke discussie niet in de weg en kan de redactie het eenvoudig terugvinden.

[Reactie gewijzigd door Santford op 23 juli 2024 07:08]

[sluismaster]

Ik weet niet on welke hash of tokens het hier gaat. Maar als ik mij niet vergis, kan een aanvaller in sommige gevallen met enkel de hash zich voordoen als een andere gebruiker. Hiervoor heb je dus geen plaintext password nodig.

Ik ben het met je eens dat het een verschil is, maar in effect misschien niet.

[Reactie gewijzigd door sluismaster op 23 juli 2024 07:08]

[Danny]

Ik weet niet on welke hash of tokens het hier gaat. Maar als ik mij niet vergis, kan een aanvaller in sommige gevallen met enkel de hash zich voordoen als een andere gebruiker. Hiervoor heb je dus geen plaintext password nodig.

Dat lijkt me dan eigenlijk al een kwetsbaarheid an sich

[latka]

Niet echt. Als je een netwerk login doet wil je niet dat je wachtwoord cleartekst over de lijn gaat dus stuur je de hash op. Toegegeven dat zijn niet de meest handige protocollen (APOP) en er zijn betere alternatieven (CRAM-MD5 die ook al weer achtherhaald is) maar om nu te stellen dat het een kwetsbaarheid an-sich is hangt af van de aanval scenario's waartegen je je wilt beveiligen.

[joco]

waarom zou je dat niet willen?
wij sturen toch met z'n allen ook constant wachtwoorden over over het netwerk (en dan nog al het grote boze publieke internet....)

Het aan een "client" kant hashen en dan de hash gebruiken als communicatie over de lijn lijkt me enorm stupide.
Behalve als het gaat om one time hashes of dingen met een expire date (zoals JWT tokens)
maar puur hashes van de wachtwoorden zoals je ze opslaat in de database (bcrypt of dergenlijke wachtwoord hashes) die moeten nooit over de lijn heen als echte authenticate, want dan staat dat gelijk aan plain text wachtwoorden..

[m3gA]

Dat klopt inderdaad. Wordt een 'pass the hash attack' genoemd.

[Verwijderd]

Dat is niet goed, je hash gebruiken als inlog, is hetzelfde als plaintext je wachtwoord opslaan, als dat al kan

[slowdive]

Dat is niet wat er gebeurd. Als een user de hash van het password zou invoeren in een invoerveld, zou de hash van die hash vergeleken worden met de hash van het echte wachtwoord. Die twee hashes zijn verschillende en dus kan de gebruiker niet inloggen.
De gestolen hash wordt door een hacker in de achtergrond gebruikt om te doen alsof er rechtmatig ingelogd is. Dat zou natuurlijk niet mogelijk moeten zijn.

[Boydh]

Het lijkt er inderdaad op dat er gebruik gemaakt kan worden van de hashes met mimikatz.
Heb het zelf nog niet geprobeerd, maar lees online dat andere het wel succesvol hebben gedaan.
Is wel al eerder bestaande toegang tot het systeem voor nodig, maar het zou gebruikt kunnen worden als deel van een exploit chain.

[Dracozirion]

Dat gaat dan om een pass the hash aanval en is inderdaad mogelijk.
Nu, het gaat niet enkel om de SAM hive hier maar ook om de SECURITY registry hive waardoor ook cached domain credential hashes (en dus niet enkel local) kunnen worden uitgelezen. Maakt het een stuk interessanter voor hackers op omgevingen waar er gebruik wordt gemaakt van domain admins op clients die niet in de protected users group zitten (geen NTLM auth en geen caching).

[The Third Man]

Een plain text wachtwoord heeft een extra vector omdat het ook bruikbaar is voor andere systemen. Als de beheerder hetzelfde wachtwoord voor z'n lokale admin en bijvoorbeeld de netwerk shares gebruikt dan is het risico op lekken veel groter als het wachtwoord plain text te lezen is. Bij een goed gesalte hash of token zoals hier het geval lijkt te zijn is dat er niet omdat je niet meer achter het plaintext wachtwoord kan komen. Dat maakt wel even een verschil.

[Niet Henk]

Let wel dat als het NTLM hashes betreft, deze op een low-end PC voor lange wachtwoorden in een paar dagen te kraken zijn, voor korte wachtwoorden en met een high-end PC kan het in een kwartiertje.

Desalniettemin niet het meest serieuze lek, sinds je die hashes middels een boot schijfje altijd al kon uitlezen en wijzigen. Nu kon je daar tegen beschermen middels bitlocker, dus zeker niet niks dat je daar nu omheen kan, maar toch.

[rob12424]

Vroeger had je hier toch de Linux distributie OPH Crack voor? Ik heb deze wel eens moeten gebruiken omdat mijn ouders zich hadden buitengesloten. Dat werkte met Rainbow Tables. Duurde max. 3 uur ofzo. En trok de hashes naar mijn weten uit het Ram geheugen.

[GekkePrutser]

Klopt, dit werkte wel goed, maar het was gebaseerd op de destijdse LanManager compatible hashes die niet gesalt waren. Daarom werkte een rainbow table ook.

Niettemin kom je met GPU's (en hashcat!) ook een heel eind tegenwoordig met modernere hashes.

[zalazar]

Zoals al aangegeven was die rainbow table van toepassing op LM hashes. Deze wordt naast de NTLM hash opgeslagen. Tegenwoordig staat de setting "Network security: Do not store LAN Manager hash value on next password change" op Enabled waardoor er geen LM hash meer wordt opgeslagen.
Bij LM is er een maximale lengte van het wachtwoord van 14 en bij wachtwoorden langer dan 14 kan er geen LM hash meer worden opgeslagen. Bij eerdere versies van Windows ontstond er dan een warning.
Bij LM wordt een wachtwoord van 14 karakters gesplitst in 2 delen van 7 karakters en per deel wordt een hash berekend. Vandaar dat de grootte van de rainbow table beperkt kon zijn omdat beide hashes maar een wachtwoord van maximaal 7 karakters kunnen bevatten. Tegenwoordig is er geen rainbow table meer nodig en kun je bijvoorbeeld via de GPU zo'n hash snel kraken.

[The Zep Man]

Waarom gebruikte je niet Offline Windows Password & Registry Editor? Daarmee kan je van een onversleutelde Windows installatie wachtwoorden van lokale accounts wijzigen.

[rob12424]

1 het was in de tijd van Windows 98 ongeveer.
2. Ik ben geen systeembeheerder, mijn vak is totaal iets anders. Je moet dat dus maar net weten. En met zoeken kreeg ik zeker niet dat resultaat te zien tot de mogelijkheden.

Moet zeggen ik heb mij met Linux ook een keer buitengesloten. Dat was een groter probleem........

[souplost]

Kan geen probleem zijn. Je kan altijd nog booten in single user mode. VB:https://www.tecmint.com/boot-into-single-user-mode-in-centos-7/

[The Zep Man]

1 het was in de tijd van Windows 98 ongeveer.

Voor Windows 98 hoefde je niet met een wachtwoord in te loggen. Je kon gewoon het wachtwoorddialoog annuleren, want dat was enkel voor netwerkauthenticatie.

Moet zeggen ik heb mij met Linux ook een keer buitengesloten. Dat was een groter probleem........

Bij Linux is de grootste hindernis full disk encryption. Zonder dat kan je gewoon alternatieve media booten en het wachtwoord wijzigen.

Met full disk encryption moet je een recoverymethode (vaak een recovery key) hebben.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 07:08]

[rob12424]

Zoals ik al zei: mezelf buiten gesloten. Geen toegang for user 1001 (root en SE Hardenned + app armor)

Dan kun je nog geen schijf encryptie hebben. Dan kom je er echt niet in. Dat was eigenlijk de bedoeling. Maar ging een beetje fout......

En zoals ik al zei: ik heb geen ICT achtergrond.

[The Zep Man]

Let wel dat als het NTLM hashes betreft,

Het betreft NT hashes. NTLM betreft een protocol waarin NT hashes gebruikt worden voor authenticatie.

De statische NT hash van een wachtwoord is gebaseerd op DES of MD4 zonder salt. De lengtes zijn zo kort dat het makkelijk te brute-forcen is.

Een geldige NT hash (MD4) kan gegenereerd worden met OpenSSL via:

printf '%s' "EenWachtwoord" | \
iconv -t utf16le | \
openssl md4 | \
sed "s/^.*= //" | \
sed 's/\([0-9a-f]\{2\}\)/\\\\\\x\1/gI' | xargs printf | \
base64

Windows doet hetzelfde wanneer een wachtwoord wordt aangemaakt/gewijzigd. Het resultaat wordt (versleuteld) op disk opgeslagen, en de sleutel daarvan wordt ook op disk opgeslagen.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 07:08]

[rajackar]

Het stelt je wel in staat om een offline brute force attack op de hashes te doen, kinderlijk eenvoudig omdat uit te voeren.
Met tokens gaat het nog een stukje verder aangezien die vaak direct gebruikt kunnen worden.

[ApexAlpha]

Dat is inderdaad een verschil, maar het nieuws is dat lokale accounts het bestand kunnen lezen. Dat mag absoluut niet en het is vrij bizar om te zien dat Microsoft zo een update eruit pusht zonder dat er ergens een alarmbel gaat rinkelen.

Dit zou voor Windows de eerste unit test moeten zijn die je schrijft.

Overigens is het leuk dat wachtwoorden gehasht zijn, maar met die hash kun je je vaak al aanmelden op andere systemen in het netwerk via Pass-the-Hash techniek.

https://en.wikipedia.org/wiki/Pass_the_hash

[Jerie]

Mwah. Dit is net zoiets als dat /etc/shadow door gebruikers is in te zien. Dat is niet per definitie meteen een ramp, maar je wilt dat absoluut niet.

Als de security tokens Kerberos tokens zijn, dan ben je overigens wel meteen het haasje.

Al met al een zeer slordige, kwalijke kwetsbaarheid.

[Jim80]

"Lokale Windows-gebruikers kunnen Registry-file met adminwachtwoorden inzien"
wordt: daarin hashes en security tokens van admin-gebruikers

Volledig mee eens, als je die redenering doortrekt, staan de private keys van Bitcoin wallets gewoon op de blockchain.

EDIT: Tweakers heeft ondertussen de titel al aangepast

[Reactie gewijzigd door Jim80 op 23 juli 2024 07:08]

[delphium]

Voor iets meer diepgang:
https://www.kb.cert.org/vuls/id/506989

TL:DR

The advisory states that, if successfully exploited, this bug, dubbed by some as HiveNightmare, can be used to:

Extract and leverage account password hashes.
Discover the original Windows installation password.
Obtain DPAPI computer keys, which can be used to decrypt all computer private keys.
Obtain a computer machine account, which can be used in a silver ticket attack.

Or, shorter, "a local authenticated attacker may be able to achieve [local privilege escalation], masquerade as other users, or achieve other security-related impacts." This can be used to thoroughly infect a system with malware, snoop on other users, and so on.

En tegelijkertijd een dikke bug in de Linux kernel:
https://www.qualys.com/20...lege-escalation-linux.txt

[souplost]

Je vergist je. Het gaat hier over windows. Die belangrijke Linux bug is al lang opgelost en ge-patcht. Eens kijken of dat Microsoft ook zo snel lukt.

[delphium]

Daar heb je gelijk in. Ik heb vanmorgen al mijn systemen bijgewerkt én weer eens ge-reboot. Dat is in Linuxland ook een bijzonderheid en zeer snel gebeurd (niet langer dan normaal).

[MrDummy]

Is het niet al zo lang bekend dat we met bijvoorbeeld Recovery CD van Ultimate Boot CD, de wachtwoorden kunnen resetten en zo toegang kunnen verschaffen tot Windows?

Gebruik er regelmatig mee op verzoek om backups te maken van de computers uit de faillissements, als de curator / oude eigenaar ernaar vraag.

De wachtwoord zelf weet ik niet, maar daar heb ik ook niet nodig voor alleen toegang tot Windows.
Gaat het om dezelfde kwetsbaarheid of is het andere SAM probleem waardoor de wachtwoorden zelf zichtbaar worden?

[DDX]

Als je netjes bitlocker aan hebt staan op de boot drive kan je niets met je boot cd/usb.
En los daarvan moet je dan ook nog een fysieke toegang hebben tot de pc.

[Sander2000]

Je hebt inderdaad fysieke toegang nodig, maar je kunt nog steeds met een boot CD/USB een OS herinstalleren. Je hebt dan alleen geen toegang meer tot de oorspronkelijke data.

Ik zat zelf een paar weken geleden in de situatie dat ik een PC had van mijn werk, althans een werknemer (heb een klein bedrijfje) en ik wilde die gebruiken, maar ik had iemand die verantwoordelijk was voor de IT, maar die wilde het wachtwoord niet delen (administrator). De enige optie die ik had was de PC herinstalleren, en dat kan dan wel, je verliest dan alleen wel alle data.

In dit geval was de data niet belangrijk, alle werknemers bewaarden het op een shared drive, maar de PC was voor mij op dat moment nodig als backup. En dan biedt zo'n USB toch uitkomst, maar wel met verlies van data.

Uitgaande van de snelheid van de "format" denk ik dat het een quick-format was, dus dat alleen file allocation tables verwijderd zijn, niet de data zelf op de HD, met tools die block-level scans doen is misschien nog data te achterhalen, hoewel die met bitlocker encrypted zal zijn.

[Reactie gewijzigd door Sander2000 op 23 juli 2024 07:08]

[m_snel]

Dat kan je natuurlijk ook in bios uitzetten, met een ww.

[The Third Man]

Resetten kan altijd, dat is niet het probleem... Het is het terug kunnen halen van het wachtwoord (of de hash) zelf, omdat als je dan 1 pc in het bedrijf hebt gehackt, je waarschijnlijk gelijk toegang hebt tot de rest van de pc's omdat de lokale admin meestal in een image is geconfigureerd die overal op uitgerold wordt.

[Archie_T]

Ik hoop toch dat we in 2021 dat niet meer doen en in ieder geval LAPS gebruiken.

[Blokker_1999]

You wish.

[Sander2000]

Dat kan inderdaad al tijden, maar er is een verschil.

Ten eerste kost het meer tijd om voor te bereiden, en heb je een dergelijke USB met tool nodig. Voor de meesten hier is dit natuurlijk geen probleem en hebben we zo'n USB al ergens liggen, maar het moet ook mogelijk zijn de bios in te gaan en op te mogen starten via USB. Dat mag op een werkplek vaak niet en het bios heeft wellicht een extra wachtwoord.

Daarnaast is het zo dat als je je wachtwoord reset (op een andermans systeem) dat die persoon gelijk weet dat zijn wachtwoord aangepast is en er allerlei bellen gaan rinkelen. Dat wil je dus eigenlijk als aanvaller niet. Als je een hash hebt, dan is die wellicht te brute-forcen. Veel mensen gebruiken overal hetzelfde wachtwoord en zodra je het wachtwoord heb, kun je het systeem in, zonder iemand het eigenlijk merkt, en zonder dat je extra toegang of tools nodig hebt.

Probleem is natuurlijk wel dat er voor de hash nog een collission gevonden moet worden.

[Karsten88]

Alleen nu kan malware geautomatiseerd admin worden, malware kan niet je systeem rebooten en een boot CD'tje draaien.

[kodak]

Dat werkt als je toegang tot de gegevens op de disk hebt. Daarom is het belangrijk om een disk te versleutelen. En als het goed is doe je dat al als er persoonsgegevens van anderen op de disk kunnen staan.

[satya]

Ik dacht dat dat niet meer kon sinds Windows 10. Al helemaal niet als schijf versleuteling aan staat wat bij een aantal bedrijven in elk geval standaard is.

[dehardstyler]

Dat zit er inderdaad al heel lang in, maar hiermee kun je dus daadwerkelijk achterhalen welke passwords gebruikt worden. En dat is natuurlijk wel vervelend, zeker voor de mensen die overal hetzelfde wachtwoord gebruiken.

[spoor12b]

Al onze laptops zijn Azure AD joined en gelukkig staat sinds die tijd het local admin account uitgeschakeld. We zijn dus gelukkig niet kwetsbaar voor deze aanval.

[Lick_A_Brick]

Let wel op dat als je ooit inlogt op een PC met een gebruiker die wel local admin is deze credentials (volgens mij) ook gewoon gecached worden, en dus de hashes hiervan kunnen worden uitgelezen.

[m_snel]

Normaal zet je dat uit, tenzij je het device offline wil gebruiken.

[robbinwehl]

@spoor12b dat heb je niet goed!
Windows slaat namelijk de hash op van de user die als laatst ingelogd is...
Trek je netwerk stekker maar eens uit je pc, zet hem aan en log maar es in zoals je altijd doet, je zult zien dat je gewoon ingelogd word.
(* als alle settings verder default staan mbt domein/azure login)

[Fish]

cached credentials ........

[D11]

Even snel een gekeken naar een powershell script. Moet iets worden in de trend van:

# Welke restorepoints zijn er?
Get-ComputerRestorePoint

# Kan ook met vssadmin getoond worden
vssadmin list shadows

# Delete alle shadow copies en/of restore points
vssadmin delete shadows /all

# stel de rechten goed in
icacls %windir%\system32\config\*.* /inheritance:e

# Maar een nieuwe restore point
Checkpoint-Computer -Description "RestorePoint1" -RestorePointType "MODIFY_SETTINGS"

[GertMenkel]

Is het slim om alle restore points te verwijderen voor je een nieuwe maakt? Ik zou zelf eigenlijk een restore point maken voordat ik de rest delete, dan weet je bij problemen zeker dat je nog een vorm van restore points hebt.

[FastBunny]

Ja, want anders is het in het gemaakte restore point nog niet gefixt en kan die nog misbruikt worden

[GertMenkel]

Ik bedoel meer dat je eerst de fix doet, dan een restore point maakt en dan pas alle eerdere restore points weggooit. Het zou namelijk onhandig zijn als je erachter komt dat je system restore creation kapot is nadat je alle eerdere kopieën hebt verwijderd...

[D11]

Goed punt. Maar zoals gezegd. Even snel gekeken ..
Ik kijk uit naar je uitwerking.

[robbinwehl]

Volgens mij zijn dit toch gewoon ntlm hashes? Zit al sinds xp of eerder in Windows ?
Kinderspel om de hashes te verkrijgen, nu nog steeds blijkt...

Weet zo even de naam van het tooltje niet, maar je moest eerst een file downloaden van x 100 gb en dan kon je die hashes zo omzetten naar een wachtwoord (vrij snel)

[GertMenkel]

Voor zover ik me kan herinneren, waren dat meestal Linux USB's die je moest booten, of je moest admin-rechten hebben. Voor het kraken heb je niks speciaals nodig, maar daar gaat het hier niet om. Het lek is dat je ze kunt verkrijgen.

Een gemiddeld Windows-wachtwoord kun je tegenwoordig waarschijnlijk met een half uurtje kraken. Als je Bitlocker aan hebt staan, wordt dit alleen een stuk lastiger: je kunt niet bij de hashes zonder dat de PC aan staat, en je hebt dus normaal administratortoegang nodig om bij de hashes te komen.

Door een fout in de ACL kan ieder programma dus de hashes uitlezen en je wachtwoord kraken. Ook kan, afhankelijk van het protocol, de hash voldoende zijn om in te loggen over het netwerk, dan hoeft er niks gekraakt te worden.

Het is een slordige fout van MS, maar gelukkig één die makkelijk gerepareerd kan worden.

[pauldaytona]

Blijft nog de vraag waarom Microsft de rechten heeft aangepast vanaf 1809 w10, je past wat aan met een reden toch?

[kr4t0s]

Dit is al jaren en jaren bekend. Het wordt letterlijk in de sales presentaties van bijvoorbeeld Cyberark getoond.

[spoor12b]

Da's een goeie. Het zou inderdaad nog beter zijn om elevation helemaal uit te schakelen maar dat wordt een te zware maatregel.

Nog beter om z.s.m. passwordless te gaan maar volgens mij kan je, wanneer je voor remote beheer, even als local admin moet werken niet met FIDO2 of WhFB aanmelden op een ander apparaat. Dat het meestal remote moet maakt het nog lastiger.

[Rataplan_]

Ik moet zeggen dat ik dit niks nieuws vind. Een jaar of 15 terug, Windows XP nog, en een lokaal systeem met machine speifieke software waarvan men geen wachtwoord meer wist. Dat kon je heel simpel met L0fthCrack oid regelen. Duurde wel lang gezien de CPU power van die tijd. Maar toen gebruikten we ook al shadow copies, of misschien zo'n recovery point, om bij de file te kunnen (het systeem was fysiek verzegeld dus we konden niet even de disk eruit halen, booten van USB oid ging ook niet). Die werd gekopieerd naar een andere machine, waar we dat L0fthcrack lieten draaien. En lo and behold, na een paar dagen kwam het wachtwoord eruit.
M.a.w. het verbaasd me eigenlijk dat men dit nu op deze manier eruit komt.

[goarilla]

Inderdaad, vergeet ook niet de chntpasswd tool waarmee je lokale user-passwoorden direct in de SAM file kan resetten. Voor die situaties waar je het oude passwoord niet meer moet weten en je kan booten van cd/usb.

[spoor12b]

Gelukkig gebruik ik thuis en op kantoor zowel bitlocker als credential guard net als andere security best practices. Jammer dat deze niet gewoon afgedwongen worden voor tenminste de logo requirements maar dan gaan waarschijnlijk consumenten zwaar klagen als ze al hun data kwijt raken door de beveiliging (terwijl ze geen backups maken).