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.
Et problem med Active Directory (AD) og tilhørende adgangskodepolitikker er, at selvom krav om adgangskodekompleksitet er slået til, så finder angribere (herunder penetration-testers) nemt dårlige bruger-adgangskoder, som IT administratorer eller sikkerhedsansvarlige ikke har mulighed for at opdage “out-of-the-box”.
Simple og meget udbredte adgangskoder, så som “Sommer2015”, “Oktober2015”, “Password1”, “[firmanavn]+[årstal]” o.s.v., lever alle op til almindelige krav om længde og kompleksitet, men i praksis er det utrolig dårlige koder, som vil være de første, en angriber vil forsøge med.
Brute-force og NTDS.DIT angreb
Et såkaldt “brute-force” angreb kan foretages ved enten at angribe én given bruger og forsøge med en hulens masse forskellige adgangskodekombinationer. Det vil i mange miljøer føre til at brugeren lukkes ude, og angrebet slutter efter få forsøg.
En bedre version af “brute-force” angrebet forsøger én velkendt og udbredt adgangskode, f.eks. “Sommer2015”, mod samtlige brugere i miljøet (også kaldet “password spraying”). Dette leder ofte til, at angriberen kan logge på miljøet med en af disse brugerkonti, idet der sjældent er noget, der beskytter mod den form for angreb (som dog kan opdages, såfremt man overvåger korrekt).
Jeg har tidligere nævnt en metode til at opnå indblik i anvendte adgangskoder, hvor man offline angriber NTDS.DIT filen. Det er en lidt tung og manuel proces. Med et nyere PowerShell modul er det dog muligt at foretage en analyse “on-the-fly” – selvfølgelig under forudsætning af, at man har (opnået) de rette rettigheder (svarende til ‘Domain Admin’ eller ‘Domain Controller’). Dette nye modul tilbyder med andre ord funktionalitet som DCSync, der for nylig er inkluderet i Mimikatz.
Get-bADpasswords
Jeg har udviklet et simpelt script, Get-bADpasswords, som udnytter denne funktionalitet til at gøre det muligt for IT-administratorer og sikkerhedsansvarlige, at opdage dårlige adgangskoder – forhåbentlig før angribere gør det.
En Domain Controller kontaktes og anmodes om at udlevere brugernavne og adgangskode hash-værdier (NT hash) for alle aktive brugere (under en given naming context).
Scriptet henter, fra en eller flere tekst-filer (wordlists), dårlige eller uacceptable (non-compliant) adgangskoder i miljøet, som så hashes (NT hash), så de kan sammenlignes med output fra AD.
Her ses et eksempel på indholdet af en sådan wordlist, der bør tilrettes den enkelte organisation, sprog osv.
Michael Grafnetter, som har udviklet DSInternals modulet, har endnu ikke frigivet kildekoden. Derfor skal man, såfremt man afvikler modulet i et produktionsmiljø, stole (blindt) på hans kode. Michael har dog sagt til mig, at han vil frigive koden sidst på året, når han har haft til til at rydde lidt op i den. Tak til Michael for hans store arbejde og hjælp.
Det er nok en god ide at få en godkendelse af HR og/eller juridisk afdeling, såfremt der måtte være indvendinger mod, at administratorer eller sikkerhedsansvarlige potentielt kan se brugeres adgangskoder. Det skal jeg ikke gøre mig klog på.
Dette script fungerer “after the fact”, dvs. efter at brugere har anvendt en dårlig adgangskode. Der er i Windows en mulighed for at skrive Password Filters, som forhindrer at de overhovedet anvendes (afhængigt af scenarie), men det er en helt anden sag.
Print Mail PDF
78ECDC40-341C-4CF9-9129-D5CF7EA6A58A@riseolsen.dk” class=””>
03A3FC8D-825A-4719-B273-009E64FD5572@riseolsen.dk” class=””>
7BFD715D-A6D8-45F1-8211-832CD99A87CB@riseolsen.dk” class=””>
F8ABD8CB-7BD3-4752-82B0-97432C1B902A@riseolsen.dk” class=””>
4BD33F40-AB48-486C-B2A1-8313900EE961@riseolsen.dk” class=””>
