SPN-hacking: derfor er det så vigtigt, at dine servicekonti har ekstra stærke adgangskoder!
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.
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).
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.
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.
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.
