jekob heidelberg bloghoved

Undgå dårlige adgangskoder i Active Directory

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.

Nedenstående tegning illustrerer konceptet.

Illustration: Privatfoto

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.

Scriptet eksekveret med "-Verbose" udskriver løbende status til konsollen.

Scriptet kan skrive brugernavne for de brugere, som har dårlige adgangskoder til en CSV fil.

Scriptet kan skrive en logfil med løbende status, herunder detaljeret (verbose) information.

Bemærk som nævnt, at mit script antager, at DSInternals modulet er korrekt installeret på den eksekverende maskine.

Et par advarsler her til sidst.

  1. 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.

  2. 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å.

  3. 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.

Mit PowerShell script kan hentes her: Get-bADpasswords.

I håbet om flere sikre Active Directory miljøer derude!

/Jakob

Kommentarer (15)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Povl H. Pedersen

Det er trivielt som Domain Admin at dumpe alle AD passwords, og bruge OCLHashcat til at knække dem, gerne suppleret med wordlists.

Har gjort det nogle gange. Har dog altid holdt brugere og passwords i hver sin fil, så man skal kombinere dem for at have en 1:1. Og dermed kan jeg undlade at gøre mig bekendt med den enkelte brugers password.

Men det er ikke der problemet er. Problemet er et awarenes issue. Startende med Helpdesk, som skal lære at brugerne skal tildeles tilfældigt unikke passwords. Ellers ender man med hundredevis af brugere med samme password, om aldrig har været logget på. Eller lås brugere der skal skifte password, men som ikke har været logget på.

Awarenes er langt bedre end regler og løftede pegefingre, og resulterer ikke i samme grad af upopularitet. Knækkede passwords, eller bare tæl antal sammenfaldende hashes, og så har man argumentet til HelpDesk eller en kampagne.

For det store problem er måske ikke en bruger med Sommer2015, problemet er hvis 10, 20 eller 100 brugere har det samme password (uanset hvad det så er). For så bliver det kendt.

  • 0
  • 0
Jakob H. Heidelberg

Det problem, som nærværende værktøj adresserer, er, (regelmæssigt) at identificere brugere med de dårligste adgangskoder, nemlig de koder som er blandt de aller første gæt for en angriber. Det er ofte ekstremt nemt at få den første bruger ad denne vej - selv i nogle tilfælde med direkte adgang via ekstern OWA m.v. Det skal selvfølgelig bruges fornuftigt sammen med eksisterende awareness tiltag og kan nemt udbygges/tilrettes efter behag.

Lad mig tilføje, at awareness desværre aldrig kan stå alene. Man er nødt til at kontrollere. Nærværende værktøj udgøre en fast kontrol af om brugerne/admins/helpdesk faktisk gør som man har aftalt.

Fuldstændig enig i, at nyoprettede brugere - og folk der får nulstillet adgangskoder - skal have unikke og stærke adgangskoder. Det er en meget dårlig praksis at starte med Velkommen1, Start123, [firmanavn]+[årstal] osv., som man desværre stadig ser derude. De bør være blandt de adgangskoder man søger efter fast - og konti kan evt. låses, nulstilles eller sættes til at skift kode ved næste login.

Din ide med at analysere på flere forekomster af samme adgangskode/hash er en fin ting lige at inkludere, selvom det måske falder lidt udenfor det oprindelige scope.

  • 0
  • 0
Lasse Mølgaard

Jeg kan godt finde på password, der er tilpas besværligt at knække, men selv jeg har mine grænser for hvor let jeg kan huske mit password, når det skal udskiftes efter 60 dage.

Der er da sket mere end 1 gang, at jeg har måtte kontakte IT for at få nulstillet mit password. :-)

... og så ender man til sidst i ren protest med at lave simple passwords, fordi jeg skulle gerne kunne huske mit password efter jeg har holdt en kort ferie.

Alternativt skal jeg skrive mit password ned et eller andet sted, og det kan vi hurtigt blive enige om er en dårlig ide? :-)

  • 0
  • 0
Jakob H. Heidelberg

Det er ikke noget problem at man i ny og næ glemmer sin adgangskode efter ferien, såfremt helpdesk er grundige med at tjekke brugerens identitet inden de nulstiller kontoen (ellers oplagt Social Engineering angreb).

I øvrigt er det ikke svært at lave lange adgangskoder som er nemme at huske - lange koder kan rent faktisk godt være simple!

Og sidste pointe: hellere skrive adgangskoden ned og opbevare den fysisk sikkert på ens person (ligesom ens NemID kort), end at benytte "Sommer2015". Det er ikke en anbefaling, men hvis man absolut skal vælge, så ville jeg vælge den nedskrevne kode.

  • 1
  • 0
Lasse Mølgaard

Men et-eller-andet sted syntes jeg også de krakilske password politikker skal stå lidt mål med hvad man forsøger at beskytte.

Når man stort set kun har minimal adgang til netværket, så er en politik om ofte skifte password en smule overkill. Var det ikke bedre med to-faktor validering? Man skal stadigvæk huske en besværligt password og derudover indtaste sekundær kode, der skifter hele tiden.

Om det er en elektronisk nøglering, tilsendt SMS eller noget andet, er teknikaliteter.

  • 0
  • 0
Jakob H. Heidelberg

Password politikker bør helt sikkert være differentierede, således at brugerkonti med flest beføjelser rammes af de skrappeste krav. Der har eksisteret mulighed for at lave fine-grained password plicies i Active Directory i snart 10 år rundt regnet. Det anvendes bare ikke særlig ofte, mærkeligt nok.

To-faktor validering er en helt anden snak - og noget dyrere i praksis i relation til Active Directory og Windows miljøer. Her taler vi smartcards, som dog også kan lave virtuelt disse dage, med anvendelse af TPM-chips på bundkortet. Hvorvidt det i praksis er en ægte 2nd faktor er en anden diskussion.

Vi slipper dog ikke for adgangskoder lige foreløbig... Og så er det heller ikke sværere at lave en stærk kode. At mange misforstår at "stærk" med "kompleks" er en helt anden sag.

  • 1
  • 0
Anders Probst

Hvor er det der er behov for at være særlig opmærksom omkring passwords ?

Enig med Jakob i at Fine Grained Password Policies i AD er en overset feature - ok den har sine begrænsninger, men tænk over hvor fedt det er at kunne styre sine interne adgange ud fra hvor høje privilegier de anvender.

Jeg vil mene, at AD servicekonti som ofte er tildelt ekstra (privilegerede) rettigheder bør være i høj risiko vurdering... Hvorfor ?

Vi tildeler (for) ofte disse privilegier og sætter passwordudløbet til uendeligt - mange gange fordi leverandører af softwareløsninger opererer med de højest tænkelige privilegier - så virker alt - og alle er glade. Og - puha - hvem tør efterfølgende røre ved en service konto der driver et vigtigt system - nu er det jo implementeret ???
Og hvad med passwordet? - Det må/kan ALDRIG skiftes!

En QuickWIN løsning:

Den nemme måde at begrænse de umiddelbare risici der er forbundet med service accounts som er medlem af " Domain Admins" eller lign., er at forhindre muligheden for at anvende disse konti kan logge på interaktivt - dvs. så kan de i det mindste ikke misbruges til at logge på via en konsol, RDP, eller anden direkte tilgang til et system.

Dette kan gøres relativt enkelt i Active Directory via en Group Policy, men bør naturligvis testes af inden det slippes løs i et produktionsmiljø.

  • 2
  • 0
Jakob Dahl

Jeg er ikke overbevist om at det øger sikkerheden at sætte en udløbsdata for passwords på 60 eller måske 90 dage hvis vi snakker om brugere med almindelig domain user adgang. Awareness og vilje er nævnt tidligere i tråden, jeg tror det er nemmere at overbevise brugerne om at de skal lave et godt password hvis de får lov at beholde det i 180 dage. Og så er det vigtigt at lave single-signon på sine systemer så brugerne ikke skal tampe det password ind hele tiden og så igen.

  • 0
  • 0
Jakob H. Heidelberg

Jeg er ikke overbevist om at det øger sikkerheden at sætte en udløbsdata for passwords på 60 eller måske 90 dage hvis vi snakker om brugere med almindelig domain user adgang.

Hej Jakob,

Tak for din kommentar. Jeg ved ikke om det er til nogen bestemt deltager i kommentartråden eller mit oprindelige indlæg, men vil blot henlede opmærksomheden på dette indlæg, hvor netop den med udløb behandles: https://www.version2.dk/blog/adgangskoder-670319

Mvh
/Jakob

  • 0
  • 0
Jakob Dahl

Jeg ved ikke om det er til nogen bestemt deltager i kommentartråden eller mit oprindelige indlæg


Det var nok mest til Lasse og det med de 60 dage, men jeg kunne nok gjort have gjort mere ud af at citere det. Jeg havde ikke lige set dit andet indlæg men det er lidt min kæphest at både revision og administratorer helt bevidstløst bare bruger kravet om de 90 dage uden at tænke på hvad det betyder. Så det var måske en kommentar til et blogindlæg jeg ikke havde læst :)

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