Jeg vil i dette indlæg give inspiration til, hvordan man kan forbedre sikkerheden omkring virksomhedens implementering af Active Directory (AD).
Vi skal se på, hvordan man i praksis, med lidt teknisk indsigt og kreativ tankegang, kan opnå administrator rettigheder på et domæne – uden at få ens egen brugerkonto smidt ind i en privilegeret gruppe.
Det er tanken, at påpege nogle typiske “huller”, der ofte opstår omkring AD, og som potentielt kan udnyttes af en ondsindet person – hvad enten hun er intern eller ekstern. Forhåbentlig kan bevidstheden om disse hullers karakter og eksistens hjælpe til at højne sikkerhedsniveauet i din virksomhed.
Det er ikke nok at tjekke sine grupper
Engang var det tæt på almindelig praksis at have de indbyggede privilegerede grupper i AD spækket med et utal af kendte og ukendte brugerkonti – typisk nogen som ingen i IT-afdelingen kunne redegøre for, men som ingen turde fjerne. I dag har de fleste af os heldigvis lært, at den type administrativ praksis er decideret skødesløs. Det bør høre fortiden til.
Det er dog langt fra tilstrækkeligt alene at overvåge medlemskabet af “Domain Admins”, “Enterprise Admins” og lignende indbyggede privilegerede grupper, som tildeler medlemmerne meget omfattende rettigheder. Der er mange andre ting, som man bør gøre sig bevidst.
Hvornår er man Domain Admin?
Lad os lige se på hvem der egentlig er administratorer i et givent domæne. Det kan under denne øvelse være ganske gavnligt at betragte en “Domain Admin” som »en person, der kender koden til en brugerkonto, som er tildelt rettigheder svarende til dem, der gives via medlemskab af “Domain Admins” gruppen«. Det skal lige bemærkes, at denne “kode” kan være enten et klartekst kodeord eller en tilsvarende LM/NT-hash-værdi.
Det er helt bevidst, at jeg ikke bare antager, at der kun er et enkelt individ bag hver enkelt brugerkonto. Det er forhåbentlig tilfældet i overvejende grad, men det er bestemt ikke en naturlov. Der kan være flere personer, som kender den aktuelle kode – enten med vilje (f.eks. de “forbudte”, men desværre meget populære, »shared accounts«) eller som følge af en kompromittering.
Det er også helt bevidst, at jeg siger “svarende til“. Man kan nemlig have masser af essentielle rettigheder uden at være medlem af nogen indbygget privilegeret gruppe. Med »Delegate Control« funktionalitet i AD kan man eksempelvis komme rigtig langt, og hvis virksomhedens overvågningsværktøjer kun koncentrerer sig om ændringer af gruppemedlemskabet i de almindelige velkendte grupper, så kan en ondsindet person, som én gang måtte have opnået administratorrettighed på domænet, bevæge sig frit under radaren derefter.
Det er en sund øvelse også lige at kigge på, hvad der helt præcist skal beskyttes i AD sammenhæng.
Hvad består kronjuvelerne af?
De vigtigste computere i et AD er dets Domain Controllere. På disse servere foregår al magien omkring autentificering af brugere og tildelingen af rettigheder ift. gruppemedlemskab og lignende. Det er altså disse computere, som vi bør sikre bedre end alle andre. Hvis en eller flere af disse først er kompromitteret, så falder hele korthuset ofte sammen.
Det absolut vigtigste objekt på enhver Domain Controller er dens Extensible Storage Engine (ESE) database fil, »Ntds.dit«, der som standard placeret under biblioteket »C:\Windows\NTDS\«. Denne fil indeholder al information om ADs topologi og indhold, herunder selve nøglerne til slottet: alle brugernavne og tilhørende koder (kræver også en kopi af SYSTEM hive filen). Adgangskoderne optræder godt nok i (envejs)krypteret form (desværre u-saltede hashværdier), men det kan man efterhånden cracke relativt hurtigt, hvis ikke brugerne er særdeles dygtige til at finde på – og huske – lange og komplekse adgangskoder.
I denne fil ligger der altså en enorm værdi for en angriber. Med brugernavne og adgangskoder vil man i teorien kunne tilgå ethvert system (og tilhørende data), som er afhængig af AD autentificering – som den bruger man nu engang lyster.
Hvad gør man med hashen?
En angriber kan gøre to ting med de hashværdier, der kan trækkes ud af »Ntds.dit«. Enten kan de (1) benyttes som de er, nemlig til såkaldte »Pass-the-Hash« angreb, der i bund og grund svarer til velkendt Single Sign-On (SSO) funktionalitet, eller (2) de kan udsættes for forskellige typer crypto-angreb, f.eks. vha. bruteforce-, wordlist- eller rainbowtableangreb (eller hybrider heraf). Der findes masser af gratis og effektive værktøjer til den slags operationer. Der findes oven i købet online tjenester, hvis man ikke selv vil gøre arbejdet.
Hvis man ønsker det, kan man sågar kigge efter brugernes tidligere anvendte adgangskoder. Disse gemmes nemlig for at AD kan holde styr på om brugerne kan genanvende gamle koder, hvilket som standard er sat til 24 værdier. Hvis det lykkes at “dekryptere” to eller flere adgangskoder for en given bruger, så er der en god sandsynlighed for, at man kan finde mønstre, som vedkommende vil anvende til at danne fremtidige adgangskoder (og tilhørende hash-værdier) også. Sådan kan man på uautoriseret vis bevæge sig gennem netværket – under “falsk identitet” – længe.
Det er altså værd lige at se på hvem, der egentlig har adgang til dine Domain Controllere og dine uvurderlige »Ntds.dit« filer.
Hvem har adgang kronjuvelerne?
Jeg vil i dette indlæg se helt bort fra traditionel fysisk sikkerhed omkring virksomhedens Domain Controllere. Det er min påstand, at mange stadig har alvorlige udfordringer på dette område, hvilket jeg da også har tænkt mig at uddybe ved en kommende lejlighed. Vi skal her se på nogle andre almindelige “smuthuller”.
Bliver dine Domain Controllere overvåget?
Normalt er det jo positivt, hvis serverparken bliver overvåget effektivt. Mange virksomheder har management- og overvågningssystemer, såsom Microsoft System Center Operations Manager (SCOM) og System Center Configuration Manager (SCCM), eller tilsvarende systemer.
Disse systemers agenter eller bagvedliggende services er desværre ofte sat op til at køre i en brugerkontekst, som giver en “almindelig” server administrator langt flere rettigheder, end godt er.
Det kan eksempelvis være muligt, at eksekvere scripts med administrative rettigheder, altså “på vegne af” en mere privilegeret bruger, og måske oven i købet i SYSTEM kontekst.
Selvom der ikke er rettigheder til at logge direkte på Domain Controllere med f.eks. RDP, så kan der med lidt kreativ tankegang fifle med AD. Det er eksempelvis forholdsvis nemt at tvinge »Ntds.dit« ud af en Domain Controller vha. et lille PowerShell script, eller på anden vis at manipulere med AD.
I den forbindelse bør der stilles nogle afgørende spørgsmål, såsom: Skal disse systemer overhovedet køre på mine Domain Controllere, således at almindelige server administratorer effektivt bliver “Domain Admins”? Kan det begrænses, så det kun er de rette (og få) personer, der får mulighed for at udføre kritiske opgaver i AD? Bør Domain Controllere holdes i et selvstændigt management miljø sammen med f.eks. PKI og IdM serverne?
Er dine Domain Controllere virtualiserede?
Virtualiseringen af Domain Controllere har tilført endnu flere sikkerhedsudfordringer, hvis alvor den gennemsnitlige IT-ansvarlige synes at underkende. Ud over fysiske udfordringer, så har man nu også virtuelle udfordringer, og problemet er, som i så mange andre tilfælde, at man ikke har fået tænkt sikkerhed med fra starten. Det er jo så dejlig nemt bare lige at virtualisere alt, men nu har vi pludselig også administratorer af det virtuelle miljø at tage højde for.
Disse begunstigede individer kan eksempelvis nemt tage »snapshots« af kørende Domain Controllere og/eller eksportere disse til eksterne medier. Så har de god tid til at rode med dem offline derhjemme efter fyraften. Det kan jo også tage lidt tid at bruteforce en større brugerdatabase.
Er dine VM-administratorer også lige lovlig privilegerede i denne sammenhæng?
Hvem har ellers adgang til Ntds.dit filen eller kopier af denne?
Lad os også lige kigge på storage. Hvis der anvendes SAN, NAS eller cloud storage, hvad enten det er til iSCSI eller NFS diske, eller om det er til backup, så er der her en anden angrebsvinkel.
En storage administrator har oftest fri adgang til »Ntds.dit« filer, enten som rå filer eller inde i containere, så som VMDK eller VHD(x) filer. Måske kan disse filer hentes fra skyen, mens man sidder på netcaféen nede på hjørnet? Dejlig nemt og bekvemt.
Vi har også vores kære »Backup Operators«. Det lyder jo umiddelbart harmløst, men de kan altså også få fat i kronjuvelerne relativt problemfrit. »Volume Shadow Copy« teknologien har oven i købet gjort det ekstremt nemt at hive »Ntds.dit« ud af en kørende maskine, som ellers har låst den pågældende fil (alternativt kan »ntdsutil« anvendes til formålet).
Har du et komplet overblik over hvor din virksomheds AD-kronjuveler er, og hvem der har adgang til dem?
En “Domain Admin” logger kun på Domain Controllere, ikke?
Det sidste sikkerhedsproblem jeg her vil nævne, er desværre ret almindeligt i dagens Danmark – og resten af verden for den sags skyld.
Det er således, at enhver lokal administrator på en given Windows maskine (klient eller server), hvor en bruger forinden har været logget på som “Domain Admin”, har adgang til sidstnævnte administrators adgangskode, igen i form af en hashværdi. En lokal administrator kan tiltvinge sig adgang til maskinen hukommelse, hvor login-sessioner gemmes.
Det vil med andre ord sige, at databaseadministratoren, som ellers kun er lokal administrator på f.eks. “SQLSERVER1″, kan opsnappe og genanvende adgangskoder for de administratorer på domænet, som måtte være – eller har været – logget på “SQLSERVER1″, indtil denne genstartes.
Der er ganske vist lidt ændringer i dette scenarie med Windows 8.1 og Windows Server 2012 R2, men det kommer jeg tilbage til i et kommende indlæg dedikeret til »Pass-the-Hash« angreb og »Credential Hygiene« konceptet.
Igen kan det være sundt at stille sig selv nogle spørgsmål: Er det muligt at få en “Domain Admin” til at logge på applikations- eller databaseservere i dit miljø – eller en klient for den sags skyld (typisk IT-support/Helpdesk) – eller har man allerede garderet sig imod dette scenarie? Kører der »services« eller »scheduled tasks« i “Domain Admin” kontekst på den slags servere? Hvis en “Domain Admin” har været logget på andet end en Domain Controller, bliver den pågældende computer så genstartet umiddelbart efter sessionens ophør?
Afrunding
I dette indlæg har jeg gjort rede for, at det ikke er helt så enkelt at afgøre, hvem der er administrator i et givet AD domæne, på grund af typiske uhensigtsmæssigheder i implementeringen af AD og tilhørende administrative praksis.
Så hvis du sidder som IT-ansvarlig i en virksomhed, hvor AD er central container for alle medarbejderes identitet, og du ikke har helt styr på alle ovenstående problemstillinger, så lad mig lige spørge dig igen: hvor mange administratorer findes der egentlig på dit domæne? 
I kommende indlæg på denne blog vil jeg komme ind på detaljerne i flere af de ovenfor berørte sårbarheder og angrebstyper. Der kommer vi lidt dybere ned i teknikken. Stay tuned!
Leave a Reply