Wachtwoord encryptie binnen Active Directory 2003

[dominion99]

Ik ben op zoek naar informatie hoe binnen Active Directory 2003 de wachtwoorden opgeslagen worden.

Met andere woorden, welke encryptie methode gebruiken ze.

Ik wil dit niet gaan kraken of misbruiken, maar een klant van mij heeft deze vraag gesteld (voor productafweging).

Ik heb wel informatie kunnen vinden op technet, daar stond iets over MD4, maar ik kon niet achterhalen of die informatie ook nog geldig was voor Active Directory 2003.

[Verwijderd]

Active Directory == Active Directory. Als dat stukje ging over Active Directory zal dat nog steeds gelden voor Windows Server 2003.

[Question Mark]

Ik denk eerlijk gezegd niet dat MS complete white papers op hun website plaatst met daarin de complete encryptie van usernames en passwords

Heb je je klant ook gevraagd waarom hij dit wil weten? Ook al zou de AD-database "onkraakbaar" zijn, dan nog staan er op elke member-server lokaal usernames en paswoorden... Eea ander is ook afhankelijk van domein- en netwerksituatie. Als er nog een NT4 machine in het domein hangt, wordt er geen gebruik gemaakt van Kerberos als authenticatieprotocol tussen DC en NT4 machine, maar wordt teruggegaan op NTLM. Dit betekend dat er een 'eenvoudige' challenge en response over het netwerk gaan. Afhankelijk van de netwerkstuctruur is dit eenvoudig te snifferen.

Ik heb het idee dat je klant zich zorgen maakt om security. Op zich een goed teken, het is alleen de taak van de consultant om de klant te wijzen op andere risico's. Beveiliging van (in dit geval Windows) systemen is meer dan alleen een AD-database.

[dominion99]

Verwijderd schreef op 02 november 2004 @ 16:52:
Active Directory == Active Directory. Als dat stukje ging over Active Directory zal dat nog steeds gelden voor Windows Server 2003.

Er zijn wel degelijk verschillen tussen Active Directory 2000 en Active Directory 2003

[Verwijderd]

dominion99 schreef op 02 november 2004 @ 19:43:
[...]

Er zijn wel degelijk verschillen tussen Active Directory 2000 en Active Directory 2003

Dat is zo. Maar in dergelijke zaken zullen geen/weinig wijzigingen zijn aangebracht in verband met compatibiliteit.

[dominion99]

Question Mark schreef op 02 november 2004 @ 18:38:
Ik heb het idee dat je klant zich zorgen maakt om security. Op zich een goed teken, het is alleen de taak van de consultant om de klant te wijzen op andere risico's. Beveiliging van (in dit geval Windows) systemen is meer dan alleen een AD-database.

Ik begrijp dat MS de details ook niet bekend zal maken.

De klant wil een afweging maken tussen verschillende producten, en daarom willen ze dus weten hoe die producten omgaan met bijvoorbeeld wachtwoorden (hoe die dus worden opgeslagen)

[ Voor 59% gewijzigd door dominion99 op 02-11-2004 19:50 . Reden: C/P foutje ]

[dominion99]

Verwijderd schreef op 02 november 2004 @ 19:45:
[...]
Dat is zo. Maar in dergelijke zaken zullen geen/weinig wijzigingen zijn aangebracht in verband met compatibiliteit.

Daar heb je ook weer gelijk in, maar ik had vandaag iets gelezen over een ADMT tool, die gebruikers migreerde naar AD 2003 (volgens mij was er ook iets met wachtwoorden, maar ik kon het niet terugvinden)

[ Voor 2% gewijzigd door dominion99 op 02-11-2004 20:00 . Reden: "het" added ]

[Yalopa]

Iets over de verschillende mogelijkheden:
http://www.microsoft.com/...ures/dirlist.asp#heading9

Kerberos authenticatie (de veilige manier in AD)
http://www.microsoft.com/...in/security/kerberos.mspx

Je kan elke andere communicatie verbieden dmv gpo..

Question Mark schreef op 02 november 2004 @ 18:38:
Ik denk eerlijk gezegd niet dat MS complete white papers op hun website plaatst met daarin de complete encryptie van usernames en passwords

Juist wel, dergelijke whitepapers helpen de klant immers te overtuigen van de veiligheid van het systeem.

[Verwijderd]

Maak je geen illusies over de encryptie van de wachtwoorden in AD. Deze is in enkele minuten te kraken met de juiste programma's. Vertel dit eerlijk aan de klant maar zeg ook dat je met een goed doordacht en pro-actief securitybeleid het de potentiele hacker heel moeilijk kunt maken.
Mijn ervaring is dat de klant dit veel meer waardeert dan een gelikt verkooppraatje. Wijs ze er ook op dat er anders misschien een vals gevoel van veiligheid ontstaat en dat is funest voor elke vorm van beveiling.

[Verwijderd]

Verwijderd schreef op 02 november 2004 @ 23:42:
Maak je geen illusies over de encryptie van de wachtwoorden in AD. Deze is in enkele minuten te kraken met de juiste programma's. Vertel dit eerlijk aan de klant maar zeg ook dat je met een goed doordacht en pro-actief securitybeleid het de potentiele hacker heel moeilijk kunt maken.
Mijn ervaring is dat de klant dit veel meer waardeert dan een gelikt verkooppraatje. Wijs ze er ook op dat er anders misschien een vals gevoel van veiligheid ontstaat en dat is funest voor elke vorm van beveiling.

Binnen enkele minuten?

Ben ik nog nooit tegengekomen eerlijk gezegd. Heb je daar wat meer informatie over? Geen programma's o.id., want dat is natuurlijk niet de bedoeling. Maar meer van hoe je bij de database kan komen waar ze in staan. Want daar kom je niet zomaar bij.

[Verwijderd]

Verwijderd schreef op 02 november 2004 @ 23:47:
[...]


Binnen enkele minuten?

Ben ik nog nooit tegengekomen eerlijk gezegd. Heb je daar wat meer informatie over? Geen programma's o.id., want dat is natuurlijk niet de bedoeling. Maar meer van hoe je bij de database kan komen waar ze in staan. Want daar kom je niet zomaar bij.

Ik heb hier een programma dat remote een dump kan maken van het wachtwoordenbestand. Die gecrypte wachtwoorden kan ik daarna door een ander programma halen.
Onderstaande een screendump van een realworld "test" die ik deed bij een grote automatiseerder in onze hoofdstad:

------------------------------------------
plaintext found: 299 of 329 (90.88%)
total disk access time: 209.57 s
total cryptanalysis time: 1930.78 s
total chain walk step: 1406453930
total false alarm: 607882
total false alarm step: 515755109

In dit geval zijn dus 299 van de 329 passwords gedecrypt in ongeveer 32 minuten tijd. Ik had een hogere succesrate kunnen halen als ik andere tabellen had gehad, maar die pasten wegens ruimtegebrek niet op mijn laptop. Dit vond ik al met al toch een mooi resultaat en de administrator zat er ook bij ;-).
Zou ik slechts 1 account willen decrypten kost dit max 3 a 4 minuten.
Bovenstaande decryptor werkt ook met: Cisco Pix, LanMan, MD2, MD4, MD5, Mysql, SHA1, etc...

Het is net als met autorijden. De autoverkoper die je verteld dat je met zijn auto nooit een ongeluk zult krijgen liegt. Vertel liever wat ze kunnen doen om dat risico zo veel mogelijk te verkleinen.

[JoetjeF]

Nu weet ik wel dat Windows standaard Kerbos encrypty gebruikt (uiteraard een aangepaste vorm, het zou eens aan de standaard voldoen), maar volgens mij maakt het in W2K3 gebruik van een goede Hash algoritme.

Dit zou, in combinatie met een public/private key nagenoeg onbreekbaar moeten zijn. Of mis ik iets?

[paulhekje]

@MrMenor: In het voorbeeld van 3 a 4 minuten tijd om een wachtwoord te kraken ga dus uit van fysieke toegang tot de server waar AD op staat of toegang als beheerder over het netwerk?
Als je deze mogelijkheid niet hebt kun alleen met dictionary/brute force wachtwoorden raden. Met de juiste policy duurt dat erg lang.

[dominion99]

Ok, ik denk dat ik met deze antwoorden wel redelijk uit de voeten kan.

Trouwens, ik lees veel over een utitlity syskey, deze kan de wachtwoorden encrypten binnen AD en SAM. Dit weerhoud een programma niet om het wachtwoord te kraken, maar hij is er iig wel veel langer mee bezig.

[Verwijderd]

Verwijderd schreef op 03 november 2004 @ 00:10:
[...]

Ik heb hier een programma dat remote een dump kan maken van het wachtwoordenbestand. Die gecrypte wachtwoorden kan ik daarna door een ander programma halen.
Onderstaande een screendump van een realworld "test" die ik deed bij een grote automatiseerder in onze hoofdstad:

------------------------------------------
plaintext found: 299 of 329 (90.88%)
total disk access time: 209.57 s
total cryptanalysis time: 1930.78 s
total chain walk step: 1406453930
total false alarm: 607882
total false alarm step: 515755109

In dit geval zijn dus 299 van de 329 passwords gedecrypt in ongeveer 32 minuten tijd. Ik had een hogere succesrate kunnen halen als ik andere tabellen had gehad, maar die pasten wegens ruimtegebrek niet op mijn laptop. Dit vond ik al met al toch een mooi resultaat en de administrator zat er ook bij ;-).
Zou ik slechts 1 account willen decrypten kost dit max 3 a 4 minuten.
Bovenstaande decryptor werkt ook met: Cisco Pix, LanMan, MD2, MD4, MD5, Mysql, SHA1, etc...

Het is net als met autorijden. De autoverkoper die je verteld dat je met zijn auto nooit een ongeluk zult krijgen liegt. Vertel liever wat ze kunnen doen om dat risico zo veel mogelijk te verkleinen.

alleen om een remote dump te maken heb je admin rechten nodig. weer een fabeltje dus!

[Verwijderd]

paulhekje schreef op 03 november 2004 @ 07:50:
@MrMenor: In het voorbeeld van 3 a 4 minuten tijd om een wachtwoord te kraken ga dus uit van fysieke toegang tot de server waar AD op staat of toegang als beheerder over het netwerk?
Als je deze mogelijkheid niet hebt kun alleen met dictionary/brute force wachtwoorden raden. Met de juiste policy duurt dat erg lang.

precies. buiten dat heeft tie slechts 90% gekraakt. ik kan uit ervaring vertellen dat de laatste 10% komt doordat daar speciale tekens in de pw's gebruikt worden. >> complexiteit van pw's aanzetten werkt echt super.

[Verwijderd]

paulhekje schreef op 03 november 2004 @ 07:50:
@MrMenor: In het voorbeeld van 3 a 4 minuten tijd om een wachtwoord te kraken ga dus uit van fysieke toegang tot de server waar AD op staat of toegang als beheerder over het netwerk?
Als je deze mogelijkheid niet hebt kun alleen met dictionary/brute force wachtwoorden raden. Met de juiste policy duurt dat erg lang.

In bovenstaande geval had ik alleen maar toegang tot het netwerk, geen fysieke toegang tot de servers. Deze stonden in een (fysiek) zwaar beveiligde colo ruimte. Ik wil niet te veel uitweiden over hoe mijn toegang tot stand kwam, maar ik had geen adminrechten maar alleen een IP en een gateway.

alleen om een remote dump te maken heb je admin rechten nodig. weer een fabeltje dus!

Blijf dromen

precies. buiten dat heeft tie slechts 90% gekraakt. ik kan uit ervaring vertellen dat de laatste 10% komt doordat daar speciale tekens in de pw's gebruikt worden. >> complexiteit van pw's aanzetten werkt echt super.

Helaas voor jou, zoals gezegd had ik niet de juiste tabellen bij me, deze zijn nogal groot en bovendien zat daar al het admin password tussen. Bovendien ging het mij slechts om het "Proof of Concept". Ik kon ter plekke dus alleen wachtwoorden cracken met cijfer- en lettercombinaties. Ik heb ook tabellen voor passwords met speciale tekens:

code:

user1           JcGKWkPztkpWGZ     alpha
user2           6UkfFHxdP1c5A9     alpha-numeric
user3           @w3cjd$Beu=mDr     alpha-numeric-symbol14
user4           =s4Vi9R;JN?3][     alpha-numeric-symbol32-space
user5          >.D/:s'/&8@$!;      alpha-numeric-symbol32-space

Je volgende opmerking zal dan ongetwijfeld zijn: "Maar het kost weken om 1 tabel te maken en je hebt er minimaal 4 nodig om ratio van 90% te halen".
Klopt, maar even goed zoeken en deze tabellen worden voor weinig geld te koop aangeboden.

[ Voor 2% gewijzigd door Verwijderd op 03-11-2004 16:34 . Reden: Damn.. krijg die icoontjes maar niet onder de knie ]

[Verwijderd]

mijn volgende opmerking is dat ze op dat netwerk een Null listing toestaan en ja da's een security issue, maar dat staan dicht (win2k en hoger) en is heel goed dicht te zetten bij nt4

[ Voor 30% gewijzigd door Verwijderd op 03-11-2004 17:12 ]

[Verwijderd]

Verwijderd schreef op 03 november 2004 @ 17:11:
mijn volgende opmerking is dat ze op dat netwerk een Null listing toestaan en ja da's een security issue, maar dat staan dicht (win2k en hoger) en is heel goed dicht te zetten bij nt4

Dit is nu precies mijn punt.
Even terugbladeren: topicstarter vroeg of de wachtwoord encryptie te kraken was. Mijn antwoord is een volmondig ja. Ook gaf ik aan dat je het de hacker/cracker erg moeilijk kunt maken. Dat zul je de klant moeten vertellen.
Het gaat erom dat je een "Security Awareness" (weet even geen betere omschrijving) moet kweken bij de beheerder/klant.

[LeNNy]

Wat moet ik me precies voor stellen bij een "Null Listing"? Voorkom je dat met "RestrictAnonymous=2" reg key in het register, of is dat weer iets anders?

Met wat voor een tool kun je dat uitlezen?

[alt-92]

als jij vanaf $bak naar \\server\IPC$ gaat en gewoon connecten kan heb je een issue.
Google maar eens op null sessions. Kom je zat info tegen.

restrictanonymous op 1 of 2 dicht dat gaatje weer.

[ Voor 41% gewijzigd door alt-92 op 03-11-2004 21:39 ]

[paulhekje]

Verwijderd schreef op 03 november 2004 @ 16:24:
In bovenstaande geval had ik alleen maar toegang tot het netwerk, geen fysieke toegang tot de servers. Deze stonden in een (fysiek) zwaar beveiligde colo ruimte. Ik wil niet te veel uitweiden over hoe mijn toegang tot stand kwam, maar ik had geen adminrechten maar alleen een IP en een gateway.

In welke specifieke situaties werkt dit scenario wel en niet?
Ik ben dan vooral geïnteresseerd in de minimale settings om dit uit te sluiten:
- Windows 2000 domein, standaard lek maar "veilig" met RestrictAnonymous op 1 of moet het 2 zijn?
- Windows 2003 domein, is dit standaard mogelijk?

NB: MBSA waarschuwt de beheerder ook voor de RestrictAnonymous setting.
http://www.microsoft.com/...urity/tools/mbsahome.mspx

voor de anderen een goed leesbaar artikel: http://web.mit.edu/ist/to...r/winmitedu/security.html

[ Voor 11% gewijzigd door paulhekje op 04-11-2004 08:24 ]

[mutsje]

Je kunt een active directory etc nog zo goed configureren met strong password policy minimal 25chars etc maar dan nog is de grootste thread de inside thread. Men denkt altijd dat er van buitenaf gehakt wordt (dit wordt 9 van de 10 keer tegen gehouden door de firewall(s) ) en vergeet altijd die enkele vervelende gebruiker die lokaal een programma installeerd en vrolijk aan het kraken gaat met brute force. Wil je systemen echt helemaal dicht timmeren moet je inderdaad met NSA templates gaan werken en dan creeer je een onwerkbare situatie voor in het bedrijfsleven omdat het niet backwords compatible is...default staat only kerberos en IPSEC aan als enige communicatie met de DC dan etc. Je kan niet meer remote inloggen op de server alleen nog op de console en nog veel meer.

Wil je meer weten over security hier de whitepapers.

Windows Server 2003 security guide