jekob heidelberg bloghoved

Sådan piller en hacker Ntds.dit fra hinanden

I et tidligere blogindlæg fortalte jeg bl.a. om det vigtige i at beskytte sine »Ntds.dit« filer, som udgør Active Directory (AD) databasen. Nu vil jeg lige vise, hvordan en angriber relativt nemt kan konvertere en sådan fil til yderst brugbar information. Det har aldrig været lettere.

Få filerne ud

Først skal vi lige have en kopi af 2 nødvendige filer fra en Domain Controller (DC), i mit tilfælde er det en Windows Server 2012 R2:

  • Ntds.dit under C:\Windows\NTDS og
  • SYSTEM under C:\Windows\System32\config

Dette er der, som jeg tidligere har været inde på, en del metoder til at klare, også selvom begge filer er låst af operativsystem-processer, så længe systemet er i drift.

Til dette eksempel benytter jeg den indbyggede kommando »ntdsutil«, der er beregnet til bl.a. sikkerhedskopiering og vedligeholdelse af AD-databasen.

Som det kan ses, genereres de relevante filer automatisk. Det tager kun få sekunder.

Illustration: Privatfoto

Så langt så godt. Filerne kan herefter kopieres til en anden maskine, Windows eller Linux, idet resten kan foregå "offline".

Pak hashen ud

Der findes en lang række værktøjer og scripts til at trække relevant data ud af »Ntds.dit«. For nemhedens skyld vil jeg her benytte ntds_decode til Windows fra insecurety.net. Det er næsten for nemt.

En betydelig svaghed ved ADs måde at opbevare adgangskoder på er, at de desværre ikke optræder som "saltede" værdier. De er beskyttet af en nøgle der ligger i SYSTEM-hive filen, men efter disse er trukket ud, kan den hurtigste cracking-teknik, de såkaldte rainbowtables, anvendes uden videre. Det betyder også, at adgangskoden "Password1" (som brugeren "per" nedenfor), vil få samme LM- eller NT-hash-værdi uanset hvilket Windows OS eller AD domæne der angribes, nemlig 64f12cddaa88057e06a81b54e73b949b.

Jeg har placeret »Ntds.dit« og »SYSTEM« filerne i samme mappe som »ntds_decode.exe« på en virtuel Windows 7 klient, og kører nu kommandoen:

ntds_decode.exe -s SYSTEM -d Ntds.dit

Som det kan ses, udtrækkes hash-værdier af alle AD-brugernes adgangskoder og eksporteres til filen »hashes.txt« i PWDump format:

[brugernavn]:[uid]:[LM-hash]:[NT-hash]:[kommentar]:[homedir]:

LM-hash værdien er for alle brugernes vedkommende "aad3b435b51404eeaad3b435b51404ee", reelt 2 gange aad3b435b51404ee, som betyder at LM-hash ikke anvendes på det givne system. Man må derfor satse på at anvende NT-hash værdierne, hvilket er normalt efter Windows XP.

LM er nemlig tusind gange lettere at knække for en hacker, så det er vigtigt at få det afskaffet fuldstændig. Jeg vil ikke gå mere ind i detaljerne omkring dette i nærværende indlæg.

Crack eller send hashen videre

Nu kan en angriber enten (1) benytte de udtrukne hash-værdier som de er, nemlig til et såkaldt »Pass-the-Hash« (PtH) angreb, eller (2) disse værdier kan udsættes for forskellige typer crypto-angreb, f.eks. vha. bruteforce-, dictionary- eller rainbowtableangreb (eller hybrider heraf). Der findes masser af gratis og effektive værktøjer til den slags operationer, tja selv cloud-tjenester.

Uanset hvilken metode angriberen anvender, vil vedkommende kunne logge på domænets systemer, herunder dokumenthåndterings- og regnskabssystemer, som en hvilken som helst bruger. Forskellen er blot om vedkommende kender klartekst adgangskoderne eller kun hash-værdierne.

Med klartekst adgangskoder har angriberen flest muligheder, idet hun f.eks. kan logge på direkte på konsollen (hvis man får adgang til en fysisk maskine) og/eller gætte brugernes eventuelle adgangskode-systemer, som måske også anvendes til andre systemer end AD.

Selv fjernskrivebord (RDP) findes der værktøjer (f.eks. »freerdp-x11«) til at anvende PtH teknikken, så man kan sådan set godt få en fuld "desktop" hvis det ønskes.

Med hash-værdierne kan angriberen bruge tools som Mimikatz, WCE og Metasploit/Meterpreter til at få adgang til andre systemer på netværket med »Single Sign-On« (SSO) teknik.

I et senere indlæg vil jeg vise hvordan, man foretager et crypto-angreb på hash-værdier med værktøjer som Oclhashcat, John the Ripper (JtR), Rcracki, Ophcrack m.v. Jeg vil også vise, hvordan man bruger sine grafikkort til at speede processen gevaldigt op med CUDA-teknologi. Ligeledes vil jeg komme ind på, hvordan man i praksis udfører et PtH angreb, og herved udgiver sig for, hvem end man måtte have lyst til.

I den gode sags tjeneste

Man kan sådan set bruge ovenstående metodik til interne »password audits«, hvis man eksempelvis har et essentielt behov for at teste, om brugernes adgangskoder er tilstrækkelig stærke, og ikke på de mest almindelige wordlists m.v. Selvfølgelig kun, hvis der foreligger en klar skriftlig aftale med virksomhed og brugere om en sådan procedure.

Selvom AD og Windows kan sættes til at forlange, at brugerne vælger adgangskoder med en vis kompleksitet og længde, så kan ualmindelig dårlige koder alligevel slippe igennem filteret. Et eksempel er kodeordet "Passw0rd", der på papiret opfylder standard krav om både længde (minimum 7 karakterer) og kompleksitet, men som står på enhver wordlist med respekt for sig selv.

Afrunding

Formålet med dette indlæg har været at demonstrere, hvor let det er at få sikkerheden kompromitteret i et AD-miljø, hvis der ikke er taget tilstrækkelige forbehold i IT-afdelingen, og virksomheden ikke prioriterer sikkerhed på både det tekniske og det proceduremæssige plan.

Det burde således stå klart for enhver, at »Ntds.dit« filer ikke bør opbevares letsindigt, hverken online eller offline, jf. indlægget Hvor mange administratorer findes der egentlig på dit domæne?.

Så budskabet til de IT-ansvarlige må alt i alt være:

  • Har du afdækket hvem der reelt har adgang til AD-kronjuvelerne i dit miljø?
  • Har du sørget for at deaktivere LM hash i dit miljø?

Reference

Kommentarer (8)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Jakob H. Heidelberg

Jeg har ellers hørt at AD er sikkert og uangribeligt og at det er derfor man skal samle al adgangskontrol der.

Sarkasme ka forekomme.

Hej Maciej
Bare for at undgå misforståelser om artiklens pointer. Jeg håber, vi er enige om, at intet IT system kan siges at være "sikkert og uangribeligt", såfremt den fysiske sikkerhed og administrative praksis, ikke er på plads (fra starten).

I bund og grund har jeg kun ét kritikpunkt af AD i sig selv i nærværende artikel, nemlig at adgangskoderne ikke gemmes vha. en salted hash algoritme. Resten af svaghederne skyldes manglende opmærksomhed omkring hvad der bør beskyttes oog hvordan det skal beskyttes.

Rune Larsen

Troede ikke, at MS i vore dage stadig har usaltede passwords i AD! I *nix-verdenen har passwords jo været saltet i årtier.

Tilsyneladende har MS begået den designfejl, at forvente, at hashes af et givent password altid er ens, hvilket udelukker random salt. Men i princippet kunne de jo fx bruge brugernavnet eller en global statisk værdi som salt.

Jakob H. Heidelberg

Brugernavn er knap så effektivt so hash, som du sikkert er enig i. De kunne fx have valgt det unikke SID en AD bruger har. Det er i teorien unikt globalt. (Fx er "administrator" sjældent omdøbt eftersom man alligevel vil kende SID'en, se fx sid2user og user2sid). Man må bare passe ordentligt på sit AD - og dermed domain controller og ntds.dit filer :-)

Der er flere ting i det designmæssige, som jeg ikke kan nå at komme ind på her i detaljen, men Single-Sign-On funktionalitet er en årsag til, at man har Pass-the-Hash problematikken. Alle systemer der tilbyder SSO lider under dette. Stjæler man et saltes hash vil man også bare kunne sende det videre, men det er selvfølgelig en lidt anden sag end 'secure storage' i sig selv.

Kristian Leth

Hej Jakob.

Synes det er en super fed artikel! og det er rart at der endelig er nogen der viser hvor sårbare IT miljøer er i dag, også på hjemmesider som IT chefer læser.
Også fedt at du gennemgår det skridt for skridt, så selv de langsomme kan se hvor kritisk og nemt dette er :)

Hvornår regner du med at gå igennem hash crackingen? - afventer spændt lige pt :)

Jakob H. Heidelberg

Hej Kristian,
Mange tak for din kommentar og interesse.

Jeg skriver nok om hash-cracking umiddelbart efter et par indlæg om pass-the-angreb og hvordan man undgår dem. Det er i hvert fald planen, men jeg har 50+ emner på "det her skal jeg også huske at blogge om"-listen ;-)

Log ind eller Opret konto for at kommentere
Brugerundersøgelse Version2
maximize minimize