jekob heidelberg bloghoved

Historien om den skjulte Domain Admin

Jeg har tidligere skrevet et indlæg, som reflekterede over hvor mange administratorer, der egentlig findes i et givent Active Directory (AD). Jeg vil nu udvide med endnu et par kreative eksempler på hvordan en kompetent angriber, kan skjule sig i mængden - steder hvor den almindelige IT-revision aldrig kigger.

Misbrug af Kerberos

I hverdagslivet kender vi til mange eksempler på, at der forfalskes billetter til koncerter, festivaler og lignende arrangementer. Sagen er, at det med lidt snilde også er muligt at udstede falske Kerberos tickets til sig selv (eller andre).

Konceptet er kendt som "Golden Tickets" (og senest "Silver Tickets") og er for nylig implementeret i det populære værktøj, Mimikatz. En angriber kan eksempelvis udnytte, at have opnået adgang til password hash-værdien for "krbtgt" kontoen, f.eks. efter at have stjålet en kopi af NTDS.dit filen.

Illustration: Privatfoto

En sådan udstedt "billet" kan indeholde medlemskab af en hvilken som helst AD gruppe, og omgår eksempelvis tjek for om brugeren er deaktiveret, logon-hours og lignende. Man kan således nemt danne en Kerberos ticket, som giver fuld adgang til AD og tilknyttede resourcer, i eksempelvis 10 år. Et relativt skræmmende scenarie for de fleste.

I Mimikatz ser operationen således ud:

Angreb som disse er vældig svære at opdage og standse. De opdages kun hvis man har helt styr på hvem der logger ind, hvorfra, hvortil, og hvornår i ens miljø - og sammenstiller denne information med det forventede og almindelige adfærdsmønster. De standses ved at foretage en nøje planlagt "nulstillingsprocedure" for Active Directory (bl.a. "krbtgt"-kontoen, men få professionel vejledning inden), med mindre man hellere vil starte helt forfra.

Misbrug af SIDHistory

En anden yderst interessant tilgang er at skjule Security IDentifier (SID) værdier for højt priviligerede brugere eller grupper i en AD brugerkontos SID-historie, som ellers typisk kun bruges i migreringsscenarier.

Nedenfor ser vi brugeren "Sidney Sneaky", som tydeligvis ikke er medlem af andre grupper end "Domain Users". Han ser altså umiddelbart helt almindelig ud ved første øjekast - og i IT-revisionens AD-udtræk.

Problemet er, at Sidney faktisk er administrator på domænet. I hans SIDHistory er indlagt SID-værdien for bade "Domain Admins" gruppen og "Administrator" kontoen. Sidney er dermed i praksis medlem af "Domain Admins" (SID 512), og kan udgøre sig for at være Administrator brugeren (SID 500).

Med Mimikatz er operationen ganske enkel og smertefri, idet værktøjet går udenom Microsoft standard API'er, som ikke tillader en sådan skrivning til AD brugerkonti.

Dette angreb er relativt enkelt at opdage - hvis man altså kigger efter det aktivt. En SIDHistory værdi bør nemlig aldrig indeholde SID-værdien for det domæne hvori brugerkontoen befinder sig. SIDHistory populeres normalt fra fremmede domæner under AD migrering.

Den metode jeg vil foreslå, er et PowerShell script alla nedenstående. Scriptet kan omskrives, så det rapporterer via mail eller lignende:

Get-ADUser -Filter 'SIDHistory -Like "*"' -Properties SIDHistory | Where {$_.SIDHistory -Like "$((Get-ADDomain).DomainSID.Value)-*"} | Select SamAccountName, SID, SIDHistory

Som det ses ovenfor, har scriptet identificeret en mistænkelig konto i det givne domæne.

Så nu spørger jeg igen: Hvor mange administratorer findes der egentlig på dit domæne?

Husk: Én gang Domain Admin, altid Domain Admin!

Henvisninger

Kommentarer (18)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Jakob H. Heidelberg

Hej Brian,

Tak for din kommentar!

Prøv at læse mit indlæg "Hvor mange administratorer findes der egentlig på dit domæne?" Det er det mindset man skal være i. Det jeg forsøger at anskueliggøre er, hvor alvorlig en sag det er at nogen tildeles, eller opnår (der er talvise muligheder), Domain Admin rettigheder.

Mit indlæg skal ses som argumentation for at få fjernet så mange brugere som overhovedet muligt fra højt priviligerede grupper. Der er simpelthen ikke nok opmærksomhed omkring dette i praksis. Der sløses med rettighederne.

Jeg har i øvrigt ikke sagt, at der nødvendigvis er tale om "uautoriserede" brugere :) Insider angreb er mere almindelige end man tror - og folk stjæler ikke kun kuglepenne og kopipapir fra deres arbejdplads...

http://www.version2.dk/blog/hvor-mange-administratorer-findes-der-egentl...

  • 3
  • 0
Jakob H. Heidelberg

LDAP er et godt eksempel på en anden mulighed for at miste credentials på domænet - over netværket. Alt for få har styr på PKI og certifikater på DCer (LDAPS) mv, men hvad angår eksempler, så kan jeg i kraft af mit arbejde ikke sige så meget om konkrete sager. NTDS.dit er dog enhver hackers mål og som jeg har beskrevet i andet indlæg, så findes der tools og scripts til at stjæle og analyse AD databaser. Det er enkelt og det er virkeligt!

  • 1
  • 0
Peter Mogensen

Undskyld men...
Nu er jeg ikke bekendt med Kerberos i Windows miljø, men siger du ikke hvis nogen har fået fat i TGS' nøgle (krbtgt), kan de misbruge den?

Ja det tror da pokker... så er der jo egentlig ikke så pokkers meget tilbage mere at kompromitere.

Det svarer jo lidt til udsagnet at at hvis nogen har fået en root-konto på maskinen, så er der mange "angreb" de kan lave.
Eller at hvis nogen får fat i nøglen til Verisigns root-certifikat, så er det svært at beskytte sig imod angreb hvor de misbruger det.

Dit problem er først og fremmest ikke at forhindre der har kompromiteret dig misbruger det, men at forhindre de overhovedet kompromiterer dig.

  • 0
  • 0
Jakob H. Heidelberg

Nu er jeg ikke bekendt med Kerberos i Windows miljø, men siger du ikke hvis nogen har fået fat i TGS' nøgle (krbtgt), så kan de misbruge den?

Det er præcis det, som Golden/Silver Tickets udnytter. Grunden til at det i mine øjne er værd at nævne, er, som jeg skrev til Brian Larsen, at man skal være særdeles varsom med at uddele disse rettigheder. I praksis er det min sjældent, at man er tilstrækkelig påpasselig med dette.

Samtidig oplever vi på allerede kompromitterede miljøer, at angriberne netop udnytter disse ting i Kerberos protokollen (falske tickets og tyveri af AD databaser), og jeg vil stadig kalde det misbrug. Dvs. at man i et restore-scenarie skal tage hensyn til, at man kan anvende et (flere år) gammelt AD udtræk idet passwordet for denne konto ikke nulstilles jævnligt. Det er en proces man bl.a. skal tilføje sin recovery plan. Det er viden man bør have i baghovedet når man designer sit miljø og administrative processer.

Du kan sagtens sammenligne angrebet med tyveri af et root certifikat. Så lad os sige, at nærværende blogindlæg omhandlede det scenarie, så ville det ikke være for at sige: "man kan hacke din certifikatinfrastruktur" (hvilket jeg heller ikke skriver noget sted), men for at gøre opmærksom på, at man skal være særdeles varsom med hvem man tildeler rettighed til at udtrække certifikatet (som i AD er hash-værdien for "krbtgt"). Tidligere administratorer kan eksempelvis stadig ligge inde med en kopi af den private nøgle til et root certifikat, som er gyldigt i mange år. Pointen er: tag højde for det!

  • 0
  • 0
Peter Mogensen

... at man skal være særdeles varsom med at uddele disse rettigheder.

Ja - ligesom man skal være varsom med hvem man giver root-adgang til UNIX maskiner.

I praksis er det min sjældent, at man er tilstrækkelig påpasselig med dette.

Det er jo nok deri problemet ligger.
Kerberos er designet sådan at man begrænser hvor mange credentials man skal beskytte rundt om i ens infrastruktur, ved at Kerberos-pakker kan sendes over ubeskyttede netværk, intet sted sender de faktiske nøgler/password med og kun benytter brugerens crendentials på et tidspunkt imod en server i hele systemet. Det gør det meget nemmere at sikre sig at der ikke leaker passwords rundt omkring i systemet.
Prisen er så at man har 1 centralt sted man skal beskytte imod at blive kompromiteret, nemlig KDC'et.
Men hvis man starter med selv at give en masse uvedkommende adgang til KDC'et så har man jo tabt - efter eget valg.

Samtidig oplever vi på allerede kompromitterede miljøer, at angriberne netop udnytter disse ting i Kerberos protokollen (falske tickets og tyveri af AD databaser),

Men det er jo ikke "ting i Kerberos protokollen". Det er folk, der installeret et system som Kerberos for mere sikkert at kunne authentikere folk og derefter selv giver gud og hvermand adgang til dets dybeste hemmeligheder.
Alternativt - at man tror man kan bevare en ikke-kompromiteret tilstand i et (som du siger) allerede kompromiteret miljø.

Det svarer til at sige at der er en "ting" man kan udnytte i x509 protokollen, så man kan lave angreb hvis man har nøglen til Verisigns root-certifikat.
Ja - hvis man allerede har totalt kompromiteret Verisign, så er det jo klart at man kan udnytte det. Det er vel ikke en "ting" i protokollen.
På samme måde som at det ikke er en "ting" i Kerberos protokollen at man - når man totalt har kompromiteret systemet - kan lave ulykker.

Dvs. at man i et restore-scenarie skal tage hensyn til, at man kan anvende et (flere år) gammelt AD udtræk idet passwordet for denne konto ikke nulstilles jævnligt.

Ja. Og det er jo åbenlyst.
Ligesom man ikke bare kan sætte root-password til noget hackeren ikke kender, når man opdager at ens root-konto er kompromiteret. Han kan jo have lavet hvad som helst. Man er nød til en total re-installation.
Og ligesom Verisign ikke bare kan begynde at udstede med et nyt certifikat hvis deres root-certifikat stjæles. Man er nød til prompte at revoke samtlige gamle udstedte certifikater.

Det er jo derfor at man passer så godt på de ting ... og derfor man også skal passe hulens godt på ens TGS-nøgle. Det er for sent at bekymre sig, når den først er sjålet.

  • 0
  • 0
Peter Mogensen

idligere administratorer kan eksempelvis stadig ligge inde med en kopi af den private nøgle til et root certifikat, som er gyldigt i mange år. Pointen er: tag højde for det!

Ok... point taken.
Du har ret i at man bør re-cycle TGS-nøgler hver gang man fjerner admin-rettighederne fra KDC'et for nogen. - da de principielt kan have taget backup af nøglerne og dermed kan bygge deres eget "fake" KDC externt.

Men Kerberos er jo netop også designet til at kunne lave løbende key-rollover. Det skal man så bare bruge. Hvis man ikke gør det, så skal man nok løse op på Kerberos.

  • 0
  • 0
Jakob H. Heidelberg

Men Kerberos er jo netop også designet til at kunne lave løbende key-rollover. Det skal man så bare bruge. Hvis man ikke gør det, så skal man nok løse op på Kerberos.

Præcis, og det er det jeg ovenfor kalder en nulstilling. Det foregår stort set aldrig i et almindeligt drevet AD miljø. Jeg har henvist til en af de eneste artikler om emnet.

Der er rigtig mange overvejelser i tilfælde af en (ekstern) kompromittering - og det er ofte unikt fra sag til sag (angrebsmetodik, pro/con på total restore, omkostningsberegninger, resourcer osv.), men den vil jeg lade ligge. Enig i at total restore er optimalt, men så snart der bliver regnet på den option ude i organisationerne, bliver den i praksis ofte taget af bordet.

Tak for input Peter. Jeg håber, at du forstår, at ovenstående ikke er en kritik af Kerberos, men administration og anvendelse af samme, samt inspiration til hvor man (herunder IT revisionen) f.eks. kan se en angriber, som måtte have anvendt Mimikatz og lignende.

mvh
/Jakob

  • 0
  • 0
Jakob H. Heidelberg

Du vil i de fleste AD miljøer i dag finde krbtgt konti, der ikke har lavet password (nøgle) rotation i flere år. Der findes desværre ikke forkromede beskrivelse af processen fra MS eller andre - endnu. Men jeg er ret sikker på det er på vej. Det er kort nævnt i deres Mitigating Pass-the-Hash whitepaper.

  • 0
  • 0
Jakob H. Heidelberg

http://www.cmf.nrl.navy.mil/krb/kerberos-faq.html#kdccracked

Den tæller ikke som "forkromet" i min verden - men det kan man jo altid komme og sige. Jeg mener der mangler et whitepaper eller en KB/Technet artikel om emnet. Den vejledning du linker til, vil i øvrigt ikke virke for MS implementeringen af Kerberos, for jeg ved positivt (jf. link), at der skal laves en dobbelt-rotation. Om det er RFC compliant eller ej har jeg ikke overblik over?

http://blogs.technet.com/b/janelewis/archive/2006/12/19/the-krbgt-accoun...

mvh
/Jakob

  • 0
  • 0
Peter Mogensen

Den tæller ikke som "forkromet" i min verden

Næe... men har man brug for "krom" ?
Jeg mener... Den essentielle sætning er:
"However, it's important to keep in mind that the worst-case scenario is that your realm would need to be completely re-keyed. "

Hvordan man gør det er så et RTFM-spørgmål.
Det er muligt at MS ikke er særlig hjælpsom der. Det skal jeg ikke kunne sige.

Men du har ret i at det ikke nødvendigvis er simpelt at skifte TGS-nøgler, hvis man ikke ønsker det skal påvirke brugerne. Man kan ikke bare invalidere en nøgle hvor der stadig er levende tickets til.
Der har også været andre problemer:
http://comments.gmane.org/gmane.comp.encryption.kerberos.devel/6309

  • 0
  • 0
Jakob H. Heidelberg

Jeg er ret sikker på der kommer en forkromet anbefaling fra MS. Efter f.eks. Black Hat 2014 sessionen om nogle af de problematikker jeg nævner ovenfor:

Abusing microsoft kerberos sorry you guys don't get it
* http://www.slideshare.net/gentilkiwi/abusing-microsoft-kerberos-sorry-yo...
* http://www.youtube.com/watch?v=-IMrNGPZTl0

Til reference, for andre interesserede der måtte læse med, så findes følgende information fra Microsoft:

Men en vejledning om, hvad det har af konsekvenser for bruger/klient-authentication, eksisterende tickets/renewal, service konti/sessions osv., det er jeg sikker på er på vej. Det er, hvad der er behov for, samt en (automatiseret) proces for en løbende rotation af krbtgt, om muligt.

  • 0
  • 0
Peter Mogensen

Det er, hvad der er behov for, samt en (automatiseret) proces for en løbende rotation af krbtgt, om muligt.

Det burde være ligetil.
MIT Kerberos har en "keepold" switch til at tillade en grace-period så eksisterende tickets kan udløbe pænt.
Det er straks mere besværligt at rotere sine cross-realm krbtgt'er. Det kræver koordination.

I øvrigt så kan jeg forstå at krbtgt i AD har en nøgle afledt af et faktisk password til en bruger ?!?! ... hvorfor det? Hvorfor ikke bare en random key?

  • 0
  • 0
Jakob H. Heidelberg

I øvrigt så kan jeg forstå at krbtgt i AD har en nøgle afledt af et faktisk password til en bruger ?!?! ... hvorfor det? Hvorfor ikke bare en random key?

Det er en deaktiveret brugerkonto, hvis pwd hash anvendes som nøgle. Hvis man aktivt forsøger at ændre dens password, så nulstiller systemet selv til en random key. Så det er med andre ord begge dele, en brugerkonto og en random key.

mvh
/Jakob

  • 0
  • 0
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize