'Windows-implementatie van Kerberos-protocol vertoont gebreken' - update

Een beveiligingsonderzoeker schrijft dat Kerberos, een authenticatieprotocol in onder andere Windows, gebreken vertoont waardoor een kwaadwillende gebruiker onder andere zichzelf beheerdersprivileges toe kan kennen. Het lek zou niet te dichten zijn.

Het Kerberos-protocol maakt het mogelijk gebruikers op een netwerk te au­then­ti­ceren zonder dat daarbij wachtwoorden verstuurd worden. Er wordt daarbij gebruikgemaakt van een key distribution center, dat zorgt voor de nodige sleutels. Het is de onderzoeker van het Dfir-Blog gelukt om het wachtwoord van een account genaamd 'krbtgt' te gebruiken om een geheime sleutel aan te maken. Dit account wordt standaard aangemaakt en wordt door Microsoft aangemerkt als een 'service account'. De naam is niet te wijzigen en het account is ook niet verwijderbaar. Het wordt wel aangeraden het standaardwachtwoord te wijzigen, dit gebeurt volgens de onderzoeker echter vrijwel nooit.

Met de aangemaakte sleutel kan vervolgens het key distribution center overgehaald worden om verdere bevoegdheden toe te kennen. Hierna zou het mogelijk zijn allerlei handelingen uit te voeren, waaronder het aanmaken van nieuwe gebruikers. Het aanmaken van de met het verouderde rc4-algoritme gecodeerde sleutel is vrij eenvoudig, aangezien deze gelijk is aan de hash van de ntlm-user.

Volgens de onderzoeker is het niet mogelijk de aanval tegen te gaan, 'omdat dit nu eenmaal is hoe Kerberos werkt'. De beste optie zou zijn om geprivilegieerde accounts te beschermen en gebruik te maken van Microsoft-technieken als groepen van Protected Users en de Credential Guard. The Register heeft Microsoft om commentaar gevraagd en het bedrijf laat weten op de hoogte te zijn van het probleem.

Update, 16 december: Dit scenario gaat ervan uit dat de aanvaller reeds toegang heeft tot de domain controller. Ook is het geen nieuw gebrek in Kerberos, de technieken zijn al langer bekend als 'Golden Ticket' en 'Pass the Hash'. De onderzoeker geeft door een update op zijn blog dan ook aan dat het gaat om een uitgebreide writeup en niet om nieuwe bevindingen.

Reacties (73)

Hier wat meer info over het krbtgt account: http://windowsitpro.com/s...-directory-ad-environment

Hier een artikel welke beschrijft hoe je het beste het password van het krbtgt account kunt wijzigen:
http://windowsitpro.com/s...-active-directory-account

It's also a best practice to reset the KRBTGT user account password twice. This is because the KRBTGT account stores only two of the most recent passwords in the password history. By resetting the password twice, you effectively clear all passwords from the history and you invalidate possible malicious Kerberos tickets that have been protected using the previous passwords.

Het resetten van het KRBTGT account is niet voldoende. Het maakt het exploiteren van dat account ietsje moeilijker, maar het hebben van het KRBTGT account opent initieel een legio van andere mogelijkheden. Denk aan het aanmaken van een domain admin account, of zelfs erger, het template object (AdminSDHolder) in het AD , die gebruikt wordt voor bepaalde geprivileerde accounts, aanpassen zodat je jezelf laat weer rechten kan geven als je golden ticket niet meer bruikbaar is.

Hier lees je overigens veel meer over dergelijke persistency tricks
https://adsecurity.org/

Het probleem dat je noemt, stelt zich bij elk gepriviligeerd account. Misbruik van krbgt heeft net zo'n grote impact als een domain/enterprise admin.
Uit het artikel is niet duidelijk op te maken waarom deze account kwetsbaarder zou zijn dan enig ander account. Mij lijkt het te pakken krijgen van het wachtwoord net zo moeilijk als dat van een ander gepriviligeerd account.
Mij lijkt het daarom meer op angst/waarschuwing, omdat het merendeel van de AD admins geen kaas heeft gegeten van kerberos en (dus) niet weet of beseft wat de impact van krbtgt is.

Afaik is er nog geen manier om de 'standaard' wachtwoorden van service accounts te achterhalen. Stellen dat je daarom het wachtwoord moet veranderen is dus wat sterk uitgedrukt. Wel zou de krbtgt account gewoon mee onder password management moeten vallen en dus regelmatig gewijzigd moeten worden. (Zoalks bij elk account)

Edit:de basis van de beschreven attack is 'pass the hash' met ntlm. Deze aanval is al oud en werkt met elk gebruikt account. Feit is dat dit in veel omgevingen deze aanval wel gewoon werkt.

[Reactie gewijzigd door the_stickie op 15 december 2015 17:32]

Wat ik nog erg onduidelijk vindt van deze artikel is dat het niet aangeeft dat je er vanuit moet gaan dat je toegang hebt tot de Domain Controller...

A Microsoft spokesperson has told us in response to the flaw: "We are aware of the Golden Ticket and Pass-the-Hash techniques and encourage customers to follow our guidance at www.microsoft.com/pth to help protect themselves. It is important to be aware that only organizations that already have a fully compromised domain controller are vulnerable to this technique." ®

Ehm... Wat als je een proxy/firewall er tussen zet en het Traffic waarbij de request de rc4 van krbtgt er in zit simpelweg niet routeerd naar de betreffende Windows bak?

Of op de Windows bak zelf een aparte ontvanger maken in de server configuratie voor die user, immers de server decrypt hem al en voegt de username aan de request toe, voordat de apllicatielaag er mee aan de slag gaat.

Wat dacht je van ntlm uitschakelen zodat pth niet werkt, het wachtwoord van krbtgt niet geraden kan worden en dus het 'inherent onveilig' kerberos volledig buiten schot blijft.

Bijzonder jammer dat t.net deze (non) issue onvoldoende zelf onderzoekt en overdreven koppen klakkeloos overneemt.

Maar let op: door krbtgt 2 keer te resetten maak je alle bestaande Kerberos tickets ongeldig.
Dan moeten alle gebruikers opnieuw aanmelden en moeten alle services worden herstart.

Deze actie heeft ook alleen zin als je de feitelijke kwetsbaarheid in de omgeving (iemand heeft zichzelf volledige toegang tot Active Directory gegeven) eerst aanpakt.

Als je alleen maar krbtgt zou resetten gaat de aanvaller gewoon terug naar AD en haalt de nieuw hash op.

Het enig zinnige advies in reactie op dit verhaal is: beveiligt uw Domain Controllers alsof het uw kinderen zijn.

Wat een sneu artikel zeg. Dit is gewoon het 'golden ticket' verhaal, is al heel lang bekend, en dit gaat absoluut niet over een kwetsbaarheid of lek, niet in Kerberos, en niet in Windows.

De "aanval" begint met het bezit van de hash van het krbtgt account. Dan moet de "aanvaller" dus al toegang hebben tot de Active Directory database. Die staat alleen op Active Directory Domain Controllers en normaal gesproken kunnen daar alleen Domain Admins bij.
Maar ja, als een 3e partij op de Domain Controllers kan komen, dan houdt het op.

En ja, dat werkt op andere implementaties van Kerberos precies zo. Alle Kerberos tickets worden door de KDC's in een Kerberos omgeving met een gedeelde sleutel beveiligd.

De enige 'zwakte' die kan worden aangeduid is dat Windows in elk geval tot en met de huidige versies het krbtgt wachtwoord niet automatisch periodiek wijzigt. Kan zijn dat sommige Linux versies dat wel doen, maar dat hoeft zeker niet, want deze sleutel mag je niet verliezen.

Zelfs als je de sleutel periodiek wijzigt, dan nog helpt dat niet tegen de beschreven "aanval", want zoals gezegd: die start met volledige toegang tot een Domain Controller.

Overigens heeft elke Windows Active Directory een eigen, uniek krbtgt wachtwoord, want daar wordt een random waarde voor genereerd bij installatie. En als laatste: je kan het wachtwoord niet eens op een bepaalde waarde zetten: elke keer als je het wijzigt, wordt er automatisch een random waarde voor de hash gegenereerd.

Staat intussen ook een toevoeging bij het originele artikel:

MEDIA NOTE: This is not a new flaw, just a good write-up! I don’t know why media reporting this as a new flaw.

Artikel is inderdaad niets nieuws dus.

Bedankt voor de reactie, de blogpost wekte de indruk dat het om weer een nieuwe kwetsbaarheid gaat. Het artikel heeft een update gekregen.

Blijkbaar oud nieuws en heeft Microsoft wel een tooltje om het betreffende account te resetten:
https://gallery.technet.m...e-krbtgt-account-581a9e51

Inderdaad. Als je tegen mij zegt Kerberos, dan zeg ik niet het meest veilige wat microsoft ooit gebrouwen heeft.

Je hebt helemaal gelijk, Microsoft heeft Kerberos inderdaad niet gebouwd. Het is ontwikkeld bij MIT en is opensource.

Neemt niet weg dat dit issue Windows specifiek is en dus een ontwerp fout van MS.

[Reactie gewijzigd door Abom op 15 december 2015 16:03]

Er is niks lek of stuk, niet in Windows, niet in Kerberos.
De 'aanval' start met volledige toegang tot Active Directory.
Als je een aanvaller volledige toegang tot een UNIX Kerberos omgeving geeft, kan hij daar ook de Kerberos masterkey stelen en misbruiken.

Gebeurt dat vaak?

Daarmee los je het lek toch niet op? Je kan de username niet wijzigen.

nee, maar wel het wachtwoord.
Momenteel staat er bij iedereen een standaardwachtwoord.

A strong password is assigned to the KRBTGT account automatically. Be sure that you change the password on a regular schedule. The password for the KDC account is used to derive a secret key for encrypting and decrypting the TGT requests that are issued. The password for a domain trust account is used to derive an inter-realm key for encrypting referral tickets.

https://technet.microsoft.../dn745899.aspx#Sec_KRBTGT

Als ik dit goed begrijp heeft niet iedereen hetzelfde standaard wachtwoord.

[Reactie gewijzigd door PolarBear op 15 december 2015 15:17]

Nee, dat is niet zo. Bij de installatie van Active Directory wordt een random waarde voor de krbtgt hash gegenereerd. Die is dus in elke omgeving anders.

Hij wordt standaard niet gewijzigd, maar het is wel een goed idee om dat periodiek te doen. Niet zo zeer om aanvallers tegen te gaan, maar om de hash in oude backups onbruikbaar te maken.

Microsoft heeft een tijdje geleden al script gepubliceerd om het krbtgt wachtwoord te kunnen wijzigen. https://blogs.microsoft.c...-available-for-customers/

Volgens mij was dat zelfs naar aanleiding van een soortgelijke melding. Is dit echt een nieuw issue of een bestaand iets wat weer aandacht krijgt?

Edit, golden ticket dus. Dit is al een tijdje bekend. Zoals de bron zelf al aangeeft, twee keer achter elkaar het krbtgt wachtwoord wijzigen.

Nog een kleine aanvulling, als je nou besluit om het krbtgt wachtwoord aan te passen laat dan genoeg tijd tussen de twee wijzigingen zodat ad replicatie eerst kan plaatsvinden. Het nieuwe wachtwoord moet eerst gerepliceerd worden naar de andere dc's voordat de tweede reset kan plaatsvinden.

[Reactie gewijzigd door @r!k op 15 december 2015 14:56]

Wauw oke. Dus wat kan of is verstandig om op dit moment te doen? Alleen de paswoord van de krbtgt user veranderen?

Doe niks! Er is helemaal niks stuk of lek!

Het startpunt voor het verhaal is dat iemand al volledige toegang tot Active Directory heeft.
Ja, zo iemand kan overal bij, inclusief de hash van krbtgt, en daarmee kan hij een KDC nadoen.
Dat kan op Windows, maar kan ook prima op een Linux/Unix implementatie van Kerberos.

Als je er achter komt dat het krbtgt wachtwoord is gestolen, *dan* kan je het 2 keer resetten in de hoop de aanvaller uit de omgeving te krijgen. Maar let op: alleen domme aanvallers kunnen zo worden gestopt, want een beetje slimme aanvaller met volledige toegang tot AD (nogmaals: het startpunt) krijg je er echt niet meer uit.

Los daarvan kan je wel overwegen om het krbtgt wachtwoord periodiek te wijzigen, maar dat doe je dan met een heel specifieke reden: om het krbtgt wachtwoord in oude backups onbruikbaar te maken.

En voor de volledigheid: elke AD heeft een uniek krbtgt wachtwoord, want dat wordt gegenereerd bij de installatie. En elke keer als je het reset wordt er opnieuw een random waarde gegenereerd.

Lees oa http://blogs.microsoft.co...-available-for-customers/

2x dat password veranderen (zorgen dat je change eerst wel gerepliceerd is naar je overige DC's)

2x pwd veranderen maakt alle huidige kerberos tickets ongeldig. Je DC's krijgen dan een flinke klap te verwerken.
2x pwd veranderen was een soort van fix tegen het golden ticket/pass the hash issue. zie http://cert.europa.eu/sta...TheGolden_Ticket_v1_1.pdf

2x veranderen is in dit geval nodig omdat anders het oude password nog geldig zou blijven via de hashes.

maargoed, wat heet een flinke klap voor je DC? tenzij je duizenden devices hebt moet het voor de meeste DC's toch redelijk makkelijk te handelen zijn.

2x veranderen is in dit geval nodig omdat anders het oude password nog geldig zou blijven via de hashes.

Dat is hetzelfde wat ik zeg maar dan met andere bewoording.

maargoed, wat heet een flinke klap voor je DC? tenzij je duizenden devices hebt moet het voor de meeste DC's toch redelijk makkelijk te handelen zijn.

Niet iedereen werkt voor een MKB bedrijf
Waar haal je overigens "devices" vandaan? Elk principal in de KDC (het zij een Computer account, het zij een service account, het zij een user, etc.) kan kerberos doen. Daarnaast is elke (AD) connectie authenticated via kerberos. Web services/Exchange etc. kunnen dat ook allemaal zijn. Allemaal met een service account.
Tikt snel aan en omdat alle tickets tegelijk ongeldig worden (ipv hun standaard levensduur) kan het (afhankelijk van de omgeving) problemen veroorzaken. Logisch gevolg van drukte.

AH vandaar dat outlook op Android nog in het telefoonboek kan als je wachtwoord is gewijzigd .. maar bij de 2e wijziging dus niet.

Dus wachtwoord van je user altijd 2x wijzigen als je een nieuw wachtwoord maakt kan zinvol zijn. Weer wat geleerd.

Ben ik nou gek of wordt de oplossing al gegeven binnen het artikel?

een 'service account'. De naam is niet te wijzigen en het account is ook niet verwijderbaar. Het wordt wel aangeraden het standaardwachtwoord te wijzigen, dit gebeurt volgens de onderzoeker echter vrijwel nooit.

Verander het standaardwachtwoord en klaar is Cees? Lost misschien niet alle problemen op, maar voorkomt de meeste problemen wel?

Er is geen standaard wachtwoord: elke Active Directory heeft een unieke, tijdens de installatie gegenereerde, krbtgt hash.

Het artikel is niks meer of minder dan een herhaling van wat allemaal al gezegd is in het 'golden ticket' verhaal. Er is niks stuk of lek.

Dit is niet de eerste of enigste keer dat Kerberos op Windows stuk is. Met de golden ticket hack kon je gewoon tickets voor jezelf uitschrijven binnen een domein dat kerberos gebruikt, en dat is ook nog steeds niet gepatcht. Het is zelfs al op Defcon langs geweest, een of twee jaar geleden zelfs!

Maar er is niks stuk... Ook de demo op Defcon ging op exact dezelfde manier: men startte met volledige toegang (dus: Domain Admin) tot de Active Directory.

Dan kan je aan de krbtgt hash komen (ja, allicht) en dan kan je 'golden tickets' maken.

Is dit in alle versies van Windows?

Alleen in Windows Server producten (want daar vind Kerberos activiteit plaats).

Is niet helemaal waar, maar de laptop van jantje is iig niet affected

Kerberos draait ook prima op genoeg *NIX producten, hoor.

maar de kerberos op Unix is niet vulnerable want die heeft geen NTLM hashes...

Nee, maar Linux/UNIX implementaties van Kerberos gebruiken net als Windows een masterkey om de tickets te ondertekenen, en als een aanvaller die key kan bemachtigen (het uitgangspunt voor dit hele verhaal), dan is hij king of the castle.

Het verhaal beschrijft dan ook geen vulnerability, maar puur en alleen wat een aanvaller allemaal kan als hij eenmaal binnen is.

Haha das zeker ook waar ja

Volgens mij alles vanaf Win2000.

Kortom: alles wat een NT-kernel heeft...

Nee, dat klopt niet. Oudere versies van Windows NT (3.1, 3.5, 3.51 en 4.0) hebben ook een NT-kernel, maar zijn niet getroffen. Deze gebruikten namelijk nog geen Kerberos.

[Reactie gewijzigd door wildhagen op 15 december 2015 17:53]

Dat was ook min of meer het punt wat ik probeerde te maken: overal waar Kerberos in verwerkt zit is getroffen. Is het dan niet mogelijk om een Windows-kernel te maken zonder Kerberos, maar met een ander soort systeem dat deze lekken niet heeft?

Er is niks 'getroffen', want er is niks lek: uitgangspunt voor deze zogenaamde 'aanval' is dat iemand volledige toegang heeft tot de Active Directory database op Windows. Ja, dan is er geen redden meer aan.

Dat is op elk willekeurig OS net zo, en is trouwens met elk willekeurig authenticatie protocol zo. Als je de master-key(s) kan stelen, houdt het op.

Dat was ook min of meer het punt wat ik probeerde te maken: overal waar Kerberos in verwerkt zit is getroffen. Is het dan niet mogelijk om een Windows-kernel te maken zonder Kerberos, maar met een ander soort systeem dat deze lekken niet heeft?

Dat is mogelijk... maar niet haalbaar; er zijn veel teveel systemen die Kerberos gebruiken en die zouden dan allemaal niet meer werken.

"Kun je een Windows maken zonder Kerberos" is net zoiets als "kun je een Internet maken zonder IPv4": in theorie wel, maar voordat je de oude versie "uit kunt zetten" ben je tientallen jaren verder.

maar de oudere versies gebruiken NTLM wat zo lek is als een mandje. Dus dan ben je nog verder van huis... NTLM gebruikt zwakke crypto waardoor je de hashes die over de lijn gaan (en die je met wireshark dus kunt zien) kunt brute forcen.

Ja, alle Windows versies vanaf Windows 2000.
En elke Unix/Linux versie met een Kerberos implementatie.

alleen in een active directory forest...

alleen in een active directory forest...

En met een gebruiker die al verregaande rechten heeft op de betreffende machine.

Merk verder op, en ik citeer de "ondekker" zelf:

• This is not a new flaw, just a good write-up! I don’t know why media reporting this as a new flaw.

Gaat dit enkel over de Windows implementatie van Kerberos of over Kerberos in het algemeen?

Waar ik zelf vooral in geinteresseerd ben is Linux. Je hebt MIT en Heimdal AFAIK. Als ik het artikel mag geloven, zou de Linux-implementaties dus ook kwetsbaar zijn omdat 'dit nu eenmaal de manier is waarop kerberos werkt'?

EDIT: Ik heb even gezocht in de CVE database, maar vind hier niets van terug ... .. Zijn er nog andere bronnen?

[Reactie gewijzigd door bucovaina89 op 15 december 2015 14:37]

Volgens mij alleen van Windows. De laatste keer dat ik met Kerberos speelde onder *nix was het gebruikelijk om een beheer (administrator/manager) account aan te maken, en dat moest je beveiligen met een password. Als het goed is is dat password bij elke kerberos instance anders.

Precies zoals bij Windows.

Alleen heeft *nix Kerberos geen krgbt account

Dit verhaal is alleen van toepassing op de windows kerberos implementatie. De Linux implementaties hebben geen NTLM hash.

Het is ook geen probleem met het Kerberos protocol, het is een probleem van de Kerberos implemntatie in windows die dus voorspelbare tickets gebruikt.

Hier gaat geen CVE van komen, want er is niks stuk of lek.
Er is geen kwetsbaarheid, dit is inderdaad zoals Kerberos werkt.
Iemand die de master-key van een Kerberos omgeving kan stelen, kan vervolgens een KDC nadoen.
Dat is met andere authenticatieprotocollen net zo: als iemand de private key van een certificaat weet te stelen, kan hij of zij vervolgens de identity van de eigenaar van het certificaat nadoen.

"Kerberos, het authenticatieprotocol van Windows"? Kerberos is een netwerk authenticatie protocol. MS geeft dat blijkbaar verkeerd geimplementeerd in Windows. Maar het lek zit niet in Kerberos.

Klopt, Kerberos bestond al jaren voordat MS het in Windows implementeerde.

Het probleem lijkt me zo niet in Kerberos zelf te zitten maar in het gebruik van een standaard account en wachtwoord. Zonder de juiste credentials kan er ook niet om meer privileges gevraagd worden.

Microsoft heeft een eigen implementatie van het MIT geregistreerde Kerberos V5 protocol. Hierbij heeft Microsoft zich aan de standaarden gehouden, maar heeft een oppervlakkige oplossing geboden voor de default KRBTGT account.

Default bij een nieuwe implementatie van een AD Forest of AD Domain dien je dit wachtwoord te wijzigen. Veel organisaties hebben alleen maar puur een migratie gedaan en dat is gaan bloemkolen tot in den treure, maar ik vermoed dat de Kerberos kennis bij 90% van de organisaties die een Active Directory hebben nog niet eens in huis is.

"oppervlakkige oplossing voor de default KRBTGT account" ???

Er is niks mis met Kerberos, of met de versie daarvan in Windows.

Elke Active Directory krijgt automatisch een unieke krbtgt hash tijdens de installatie.