Servicekonti i Active Directory er ekstraordinært udsatte og sårbare overfor en bestemt type angreb, som ofte viser sig yderst effektivt til at opnå fulde administratorrettigheder i domænet. Man lykkes med det igen og igen under penetrationstest og intet afholder ondsindede angribere fra at gøre det samme.
Med en almindelig phishing mail og tilhørende simpel malware, eventuelt bare i form af et script, kan man i løbet af meget kort tid opnå Domain Admin rettigheder eller tilsvarende, med begrænset risiko for at blive opdaget. Den lidt nysgerrige interne bruger kan med lidt teknisk snilde gøre det samme.
Denne angrebsvektor har efter min mening slet ikke fået nok opmærksomhed, og helt nye værktøjer gør angrebet endnu lettere at gennemføre, hvorfor dette blogindlæg har fået prioritet over andre i bunken.
Yderligere er det noget, som man rent faktisk kan gøre noget ved, forholdsvis enkelt, og opnå væsentlige forbedringer af virksomhedens forsvarsmekanismer. Der er lavthængende frugter at plukke!
En lang historie kort
Med fare for at oversimplificere vil jeg i det følgende forsøge at abstrahere lidt fra teknikken og holde mig til de overordnede linjer.
Kort opsummeret, så kan enhver bruger i Active Directory (AD), efter indledende authentificering (1), spørge en Domain Controller (DC/KDC) hvilke tjenester (services) der findes hvor i miljøet (2). Herunder hvilke der er tilknyttet en brugerkonto og hvilke der er tilknyttet en computerkonto.
Brugerkonti relateret til Kerberos-tjenester har et såkaldt Service Principal Name (SPN) registreret i AD, der fungerer som et slags katalog over tilgængelige tjenester i domænet.
Efter at have lokaliseret en eller flere interessante servicekonti i AD, kan en angriber anmode en DC om adgang til en af disse tjenester, f.eks. Exchange eller SQL (3).
Derefter vil DCen udlevere en række autentificeringsoplysninger i en "service ticket" (TGS). Denne ticket (3) indeholder data, som kan udnyttes til at bryde servicekontoens adgangskode OFFLINE (4), dvs. uden man behøver "gætte" sig frem ved at spørge DCen igen og igen (brute force), hvilket jo oftest vil føre til låsning af kontoen.
Normalt vil en klient efter modtagelse af en TGS gå til den server, der har tjenesten installeret (Y) og anmode om adgang til f.eks. SQL, men det er ikke strengt nødvendigt.
Man kan med andre ord "cracke" adgangskoden på kraftige maskiner, fuldstændig risikofrit, uden chance for at blive opdaget. I de fleste tilfælde har man oven i købet meget lang tid til det, da klassiske servicekonti kun sjældent skifter adgangskode.
Det skal siges, at årsagen basalt set ligger i måden Kerberos fungerer på og har som sådan intet med hverken Microsoft eller Active Directory at gøre.
Protokollen er simpelthen designet sådan - og det bedste man kan gøre for at beskytte sig, er at anvende stærke adgangskoder, dvs. meget lange, komplekse og tilfældige adgangskoder (se mere nedenfor).
Rent teknisk, så er en del (server-delen) af den "service ticket", som DCen sender retur til klienten krypteret med NT-hash værdien af servicekontoens respektive adgangskode. I ovenstående tilfælde SQL serverens servicekonto. Både DC og server ventes at kende denne værdi og kan således anvende den som symmetrisk nøgle til krypteret kommunikation over netværket via klienten.
Alt hvad en angriber skal gøre, er at "gætte" eller bryde nøglen, f.eks. med brute force, maske- eller wordlist-angreb. Det kan man kun hvis adgangskoden ikke er stærk.
Jamen, vi bruger da stærke adgangskoder!?
De fleste IT-administratorer er højst sandsynligt klar over, at adgangskoder på servicekonti bør være ekstra stærke. Vi har i hvert fald sagt det til hinanden meget længe...
Vi er bevidste om, at servicekonti ofte har højere privilegier end almindelige brugere i domænet, i visse tilfælde "Domain Admin" rettigheder eller tilsvarende.
Men under de adgangskodeanalyser som vi jævnligt foretager for kunder, kan vi typisk bryde adgangskoder for 35-50% af servicekontiene i miljøet!
Det er lavt i forhold til almindelige brugere og administratorer, men tallet kunne rent faktisk være et garanteret 0% - uden voldsomt megen bøvl.
Så okay... Måske bruger du og dine kollegaer ekstra stærke adgangskoder til servicekonti, men ham der havde din stilling før dig, gjorde måske ikke.
Lidt historik om SPN-hacking
Personligt fik jeg denne angrebsvektor på lystavlen, da Tim Medin introducerede Kerberoast på Derbycon i september 2014.
Dengang var angrebet noget mere omstændigt at gennemføre end nu.
For at eksportere de nødvendige oplysninger til cracking, havde en angriber (eller pentester som mig selv) behov for Mimikatz (bare i almindelig user-mode) på maskinen, eventuelt eksekveret i PowerShell (Invoke-Mimikatz).
Alternativt kunne Wireshark, Microsoft Message Analyzer eller den indbyggede kommando NETSH anvendes, men den slags kræver lokale administratorrettigheder.
God gammeldag netværks-sniffing ("wire tapping") var en anden mulighed - og sammen med lidt Python scripts kunne man med lidt møje og besvær trække de nødvendige data (KRB5TGS) ud af PCAP trace-filerme.
Herefter kunne man forsøge at cracke med en wordlist og Kerberoast, hvilket ikke var helt optimalt.
Selve crackingdelen har kunnet håndteres effektivt offline og med GPU-kraft siden en ændring til John the Ripper (KRB5TGS) i september 2015 og hashcat siden februar 2016.
Med en ændring i PowerSploit fra september 2016 kunne KRB5TGS eksporten klares i PowerShell, uden administrative rettigheder.
For kort tid siden har Will Schroeder (Harmj0y) - i øvrigt en fantastisk White Hat, som bl.a. også står bag fremragende værktøjer som Veil-Framework, BloodHound, Empire og PowerSploit - frigivet Invoke-Kerberoast.ps1, som gør eksporten af KRB5TGS nemt og mobilt.
Det hele er næsten for nemt nu!
Hvad gør vi så for at forsvare os?
Der er flere konkrete ting, som man kan gøre her og nu:
1) Få overblikket over de udsatte servicekonti
Der er heldigvis flere måder at få overblik over præcis hvilke brugerkonti, der er knyttet til tjenester i Active Directory, f.eks.:
- Den indbyggede kommando: setspn -Q */* > allspns.txt
- GetUserSPNs.ps1
- Find-PSServiceAccounts.ps1
- Get-NetUser kommandoen i PowerView
- Det nye script: Invoke-Kerberoast.ps1
2) Sørg for at alle servicekonti med SPN har ekstra stærke adgangskoder.
Det bør i de fleste tilfælde ikke være noget problem at vælge en adgangskode på mellem 25 og 127 karakterer. Det er blot et spørgsmål om en copy-paste operation eller to.
Meld alle servicekonti ind i én sikkerhedsgruppe og associér den med en Fine Grained Password Policy (FGPP) hvor adgangskodekravene er sat højt, f.eks. minimum 25 karakterer.
Skift herefter adgangskoderne for servicekonti med svage - eller ukendte - adgangskoder.
Der findes masser af scripts til at sikre høj adgangskodestyrke (længde, kompleksitet og tilfældighed), f.eks. New-SWRandomPassword.ps1.
PS> New-SWRandomPassword -MinPasswordLength 25 -MaxPasswordLength 127
3) Ryd op i ubrugte SPN registreringer
Når man nu går servicekonti igennem, kan man lige så godt slette SPN registreringer, som ikke længere anvendes med f.eks. setspn.exe.
4) Managed Service Accounts
Undersøg muligheden for at anvende (Group) Managed Service Accounts (MSA).
Desværre er det fortsat kun få tjenester der understøtter Managed Services Accounts, f.eks. IIS, SQL og AD LDS.
5) Udnyt computerkontienes adgangskoder i stedet
Undersøg muligheden for at omstille tjenester til at køre under en af systemets indbyggede kontekster.
Computerkonti har som standard stærke adgangskoder, som automatisk skifter hver 30. dag. De er praktisk talt ubrydelige med nuværende computerkraft og kryptografiske standarder.
Undgå dog at skifte til SYSTEM hvis tjenesten kan køre under en almindelig brugers rettigheder. Det sidste er at foretrække for at mindske risikoen i tilfælde af en sårbarhed i tjenesten, jf. punkt 7.
6) Analyser Event ID 4768 (Kerberos TGS Request)
Når en klient anmoder om en "service ticket" (TGS) oprettes en event på DCen. Hvis der kommer flere fra samme klient på forskellige tjenester inden for kort tid, så er det nok værd at undersøge (læs: SIEM).
7) Lås servicekonti ned til et absolut minimum af rettigheder
Alt for ofte får servicekonti tildelt for mange rettigheder og låses ikke tilstrækkeligt ned, med f.eks. "Deny interactive logon", "Deny logon from the network" m.v.
Det kan betale sig at gå aktive servicekonti efter i sømmene og fjerne overflødige rettigheder, både lokalt og i AD.
Afslutning
Jeg håber, at nærværende indlæg kan inspirere til, at der strammes op omkring adgangskoder på servicekonti for Kerberos-registrerede tjenester rundt omkring i de danske datacentre.
God fornøjelse!
/Jakob
Referencer:
- Attacking Microsoft Kerberos: Kicking the Guard Dog of Hades
- The Hidden dangers of Service Principal Names (SPN)
- Active Directory Pentest Recon Part 1: SPN Scanning aka Mining Kerberos Service Principal Names
- Cracking Kerberos TGS Tickets Using Kerberoast – Exploiting Kerberos to Compromise the Active Directory Domain
- Kerberoasting Without Mimikatz
- Securing Windows Service Accounts (Part 1)
...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.
Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.
Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.
Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.
