Windowsauthenticatie verdient de aandacht

Transcriptie

1 In het kort: Kijk kritisch naar de bestaande instellingen en de werking van authenticatie binnen de infrastructuur. Het LMprotocol heeft afgedaan. Windowsauthenticatie verdient de aandacht R o b Fa b e r Al een tijdje is er veel gedoe rond NTMLv1 NTLMv2 en is er de ergernis dat de oude NTLM beperkte veiligheid biedt. Niet iedereen weet dit. Hoog tijd voor een helder verhaal. Om toegang te krijgen tot resources op een Microsoft Windows besturingssysteem is het noodzakelijk u te authentiseren door een geldig account en bijbehorend password te hebben of door certificaten, smart cards en tokens met pincode te gebruiken. Zonder authenticatie is er eenvoudigweg geen toegang tot onderdelen van de infrastructuur zoals servers, services, printers en fileshares. Zowel eindgebruikers als computersystemen hebben dus een aanlogprocedure te doorlopen om zich succesvol aan te melden waarna het feitelijke werk kan plaatsvinden. En juist die authenticatie bij Windows kent de nodige ruwe kantjes. Moet ik nu wel of niet NTLMv2 gebruiken als protocol? Hoe verloopt het proces van aanloggen dan precies? Welke policy's moet ik instellen? Wat is het verschil tussen lokaal aanmelden en juist over het netwerk? Wat is veilig en verstandig en wat kan ik verbeteren aan de instellingen binnen mijn Windows infrastructuur? Aanmaken en opslaan van inlog-namen en passwords Het gebruik van gebruikersnaam met passwords is zeer wijd verbreid en een veel gebruikt beveiligingsmiddel. Aanvullend zijn er allerlei opkomende technologieën zoals biometrie, dat steeds meer een belangrijk onderdeel wordt van de informatiebeveiliging. Binnen een gemiddelde implementatie van een Windows omgeving is het vaak voldoende als gebruiker zich authenticeert met een geldig account en password. De database waarin de accounts staan opgeslagen, kan op verschillende plekken worden bewaard. Als eerste kan een account lokaal op de machine zijn aangemaakt in de Security Accounts Manager (SAM). De SAM is een database waarvan de plek is terug te vinden binnen het Windows Operating System als verwijzing in de registry. De passwords worden niet leesbaar opgeslagen maar in de vorm van hashes (bij velen wel bekend als LM, NTLM hash). Door een wiskundige berekening te gebruiken, zal het password versleuteld worden tot een nieuwe waarde: de hash. Het "hashen" van passwords is slechts in één richting mogelijk. We kunnen dit proces dus niet omdraaien en terug gaan redeneren 24 mei 2010 TechNet Magazine

2 vanuit een hash wat het originele password is geweest. De hashes van versleutelde passwords worden allemaal opgeslagen in de SAM. De SAM database kan gevonden worden op de volgende plaatsen op een Windows machine: C:\%SystemRoot%\System32\config\ of in de registry door eerst de registry editor te starten en daarna te gaan naar: \HKEY_LOCAL_MACHINE\SAM De tweede mogelijkheid is dat een gebruiker binnen de context van een Microsoft-infrastructuur en een Windows domein werkt. In dat geval is er veelal sprake van een domain account die binnen een Active Directory domein is aangemaakt. Het gebruikers account zal in dat geval opgeslagen worden in de Active Directory database. De gebruiker is dan terug te vinden als een user object in de Active Directory. Dit object heeft diverse attributen of velden waarin gegevens worden opslagen van de gebruiker zoals de user-naam. Het bijbehorende password zal worden opgeslagen bij het object "user" in het unicodepwd attribuut. Ook hier staat het password niet onbeschermd opgeslagen maar versleuteld. Het unicodepwd attribuut kan alleen worden aangemaakt of gewijzigd onder specifieke condities en kan niet zomaar worden uitgelezen. Overigens hebben niet alleen eindgebruikers (users) geldige accounts nodig. Deze zijn ook noodzakelijk voor Windows systemen zelf zoals computers. Dit houdt in dat ook machines die toegang krijgen tot een Active Directory domein, machine-account aangemaakt moeten zijn. Maar het is niet noodzakelijk om als gebruiker steeds na het opstarten een wachtwoord in te voeren ten bate van de computer. De authenticatie wordt namelijk door het Operating System verzorgd. Vormen van authenticatie De authenticatiemethode van eindgebruikers kan verschillen per Windows platform. Daarbij speelt een aantal factoren een rol. Gebeurt het aanloggen bijvoorbeeld vanaf een werkstation waarbij deze over het netwerk contact probeert te leggen met een server óf kruipt een beheerder achter de console van de server zelf? De belangrijkste en meeste gebruikte varianten zijn: Interactive Er is sprake van "interactive" als een gebruiker lokaal op een machine een aanlogpoging doet. Het maakt in dat geval niet uit of we een lokaal account gebruiken (alleen aanwezig op die machine in de SAM database) of dat er sprake is van een domainaccount waarbij we aanloggen op een Windows Active Directory domein. Network Aanloggen met kenmerk network zal van toepassing zijn als een eindgebruiker toegang zoekt tot bijvoorbeeld een server over het netwerk vanaf zijn werkstation. Er zijn dan verschillende authenticatie protocollen en netwerkprotocollen mogelijk zoals het gebruik van Kerberos, Secure Socket Layer/Transport Layer Security (SSL/TLS) en het is nog steeds mogelijk NTLM en NTLMv2 te gebruiken voor compatibiliteit naar legacy systemen. We kunnen de gekozen variant bij aanloggen inspecteren door een kijkje te nemen in het securitylog. Standaard kennen Windows machines een eventlog / securitylog waarin alle aanlogpogingen worden vastgelegd. Dit is makkelijk bij het opsporen van fouten maar ook voor het napluizen van ongeoorloofde toegangspogingen ten bate van forensisch onderzoek na een hack of hackpoging. In de logs worden vastgelegd om welk type aanloggen het ging, met daarbij nog een aantal andere kenmerken de van belang kunnen zijn. In het voorbeeld van figuur 1 is terug te vinden dat bij het bij deze inlogpoging om een type 2 ging. Dit is een interactive logon. Een Windows logon van type 3 verschijnt in de log wanneer een gebruiker een machine over het netwerk benadert, een network -logon dus. Figuur 1: Type 2 logon: het aanloggen vastgelegd in het eventlog Door de jaren heen is het authenticatiemechanisme binnen een Windows omgeving veelvuldig aan verandering onderhevig geweest. TechNet Magazine mei

3 Grofweg zagen we sinds de jaren '80 van de vorige eeuw dan ook voorbijkomen: LM authenticatie Werd voornamelijk gebruikt door Windows 95, 98 en ME en is gebaseerd op DES cryptologie NTLM authenticatie Werd standaard gebruikt tot Windows NT service pack 3 en is gebaseerd op DES en MD4 NTLM v2 authenticatie Is in gebruik sinds Windows NT service pack 3 en is gebaseerd op MD4 en MD5 Kerberos Is geïntroduceerd vanaf Windows Het protocol is ontwikkeld door het MIT en voor algemeen gebruik beschikbaar gesteld aan het einde van '98 Het LM authenticatieprotocol of LAN Manager is inmiddels erg oud. Het is zo'n 20 jaar geleden als authenticatie mechanisme ontworpen ten behoeve van MS-DOS en Windows 3.1 en is naar IT maatstaven bejaard. Vandaag de dag voldoet het protocol dan ook niet meer. Toch zijn velen onder ons zich hier niet van bewust. LM kent meerdere zwakke plekken als het om veiligheid gaat. Kenmerken van LM zijn: - passwordlengtes beperken zich tot een maximale lengte van 14 karakters - kortere passwords worden met "padding" aangevuld met lege ruimte - letters in het password worden in hoofdletters omgezet - het password wordt in twee delen gesplitst van elk zeven karakters - de twee delen worden versleuteld met DES en vervolgens weer aan elkaar geplakt - de "hash" wordt vervolgens opgeslagen in de SAM database als LM hash In tekening 1 is te zien hoe het versleutelen van passwords in zijn werk gaat met LM. Tekening 1: Het hashen van passwords met LM Toch werd LM tot voor kort nog standaard gebruikt binnen authenticatieprocessen. Gelukkig is het tij aan het keren omdat LM door kwaadwillenden makkelijk misbruikt kan worden en daarmee een risico voor de infrastructuur is. Zoals we hiervoor hebben geschetst, zal een password door LM worden omgezet naar hoofdletters en daarna worden opgesplitst in twee delen van zeven karakters. Het omzetten in hoofdletters zal het aantal mogelijkheden en combinaties al drastisch verkleinen en het makkelijker maken een wachtwoord te achterhalen. Om precies te zijn kan nuttig gebruik worden gemaakt van slechts 140 verschillende tekens. Daarbij is het veel gemakkelijker om de versleuteling van deze passwords te kraken omdat er effectief geen sprake is van één lang password maar twee kortere passwords van slechts zeven karakters. Deze twee karakterreeksen worden omgezet naar een hashwaarde ofwel de LM-hash. Dit maakt het makkelijker voor een aanvaller omdat het significant minder tijd in beslag neemt om dergelijke kortere passwords te kraken. Langere en complexe wachtwoorden zijn veiliger en veel moeilijker te achterhalen. Hierover later meer. Hashing als zodanig is een methode om een hoeveelheid karakters zoals een ingevoerd password om te zetten naar een over het algemeen versleutelde waarde met een vaste lengte. De hash wordt gegenereerd door een wiskundige formule die de kans op een gelijke uitkomst (gelijke hash) tot een minimum beperkt. Bij hashing zal naast de ingevoerde karakters (zoals het password zelf) en het versleutelingalgoritme in de regel ook nog een sleutel worden gebruikt om het ingevoerde password extra complex te maken. Hashing speelt een belangrijke rol in security-land en wordt bijvoorbeeld ook gebruikt om vast te stellen of er niet geknoeid is met een bericht. Bekende methodes zijn: Message Digest 2 (MD2), MD4, MD5, Secure Hashing Algorithm (SHA) en Hash Based Authentication Code (HMAC). De LM-versleuteling is hash-technisch gezien eigenlijk helemaal geen zuivere hashingmethode. LM gebruikt alleen de ingevoerde tekens (het password) zelf als sleutel voor de encryptie. Daarbij wordt dus het password rechtstreeks versleuteld met het DES algoritme zonder toevoegingen van extra complexiteit. Daarnaast zal bovendien een korter password dan de maximaal te gebruiken 14 karakters worden aangevuld met lege ruimte. Hierna zal een 26 mei 2010 TechNet Magazine

4 aantal voorbeelden getoond worden van versleutelde passwords: rvdijk:1033: efd34b4e78f4ead2-aad3b435bb51404ee pjans:1115: f45a32d60f6d32c8-aad3b435bb51404ee guest:< >: aad3b435bb51404ee-aad3b435bb51404ee We zien telkens een overeenkomst bij de versleutelde wachtwoorden van deze gebruikers. Wat daarbij meteen opvalt is dat het deel aad3b435bb51404ee telkens terugkomt. Kijken we nu naar de wachtwoorden van de eerste twee gebruikers dan is het laatste deel hetzelfde. We spraken eerder over het feit dat LM het wachtwoord verdeelt in twee stukken en lege delen zal opvullen tot 14 karakters (2x7). In dit voorbeeld is dus het eerste deel 7 karakters en het tweede deel... leeg! Dus zal dit opgevuld worden en resulteren in dezelfde waarde. Dit betekent dus dat het wachtwoord van deze gebruiker niet langer is dan 7 karakters. Bij gebruikersaccount guest zien we zelfs twee maal de waarde aad3b435bb51404ee terug komen. Een hacker kan op voorhand op basis van de hash-waarde de conclusie trekken dat de gebruiker "guest" helemaal geen wachtwoord heeft. Tot zover het onveilige LM. Het NTLM authenticatieproces Na het bekend worden van de zwakheden van LM en het feit dat er gerichte aanvallen kunnen worden uitgevoerd, werd LM opgevolgd door NTLM. In basis is NTLM (later ook NTLMv1 genoemd) hetzelfde van opzet als LM en is alleen het gebruikte versleutelingsmechanisme anders ten opzichte van LM. Simpelweg omdat de ingevoerde passwords nu worden versleuteld met een nieuwe methode: MD4 (in plaats van DES zoals bij LM het geval is). Tekening 2: Authenticatie met NTLM password van de gebruiker en terugzenden aan de domain controller. 5. De domain controller vraagt nu de hash die is vastgelegd voor deze gebruiker op in de Active Directory. 6. De domain controller gebruikt nu deze opgevraagde hashwaarde vanuit de Active Directory om de tekenreeks die het eerst verstuurde zelf te encrypten. Daarna zal het resultaat daarvan worden vergeleken met de ontvangen waarde van de gebruiker. Komen deze twee waarden overeen dan is er een succesvolle authenticatie. In basis maken Windows systemen met NTLMv1 dus gebruik van dezelfde authenticatie methode, alleen de password versleuteling (de hash) is dus verschillend. Bij oudere systemen wordt de LM-hash nog toegepast en bij nieuwe systemen zal NTLM worden gebruikt waarbij niet meer de LM-hash maar de NT-hash wordt gebruikt. Windows besturingssytemen tot Windows Server 2003 slaan telkens nog twee verschillende password-hashes op en gebruiken deze ook binnen de authenticatieprocedure. Zowel de de onveilige LM-hash als de NT-hash staan tot Windows Server 2003 opgeslagen. Windows 7 en Windows Server 2008 hebben de mogelijkheid voor gebruik van beide varianten maar de onveilige LM-hash zal standaard niet meer worden opgeslagen en worden Figuur 2: importeren van de SAM database met Cain In tekening 2 is weergegeven welke stappen er worden doorlopen als een eindgebruiker zich aanmeldt bij een domain controller middels NTLM. Dit verloopt via de volgende stappen: 1. Er zal een onderhandeling plaatsvinden over het te gebruiken authenticatieprotocol. 2. Via het werkstation worden de user naam, de domeinnaam verzonden naar de domain controller. 3. De domain controller zal een 16 bytes lange willekeurige tekenreeks terugzenden. Dit wordt ook wel de "nonce" genoemd. 4. Het werkstation zal nu deze ontvangen tekenreeks encrypten met de hash van het TechNet Magazine mei

5 Figuur 3: onderscheppen van de LM hash met Cain gebruikt binnen authenticatie verzoeken vanwege de eerder genoemde zwakheden. Hoe we dit kunnen beïnvloeden door bijvoorbeeld policies in te stellen, bespreken we later in dit artikel. Wachtwoorden achterhalen Zoals eerder aangegeven, is het genereren van een hash-waarde een eenrichtingsverkeer. Hoe is het dan toch mogelijk dat wachtwoorden achterhaald kunnen worden? Dat kan op verschillende manieren en we zullen hierna een aantal voorbeelden geven. We gebruiken hiervoor het programma "Cain" wat via te downloaden is. Het programma wordt veel door penetration testers / ethical hackers gebruikt om te zoeken naar zwakke plekken in de beveiliging binnen de IT infrastructuur. We kunnen met dit programma de SAM database zelf importeren (zie figuur 2) of netwerkverkeer afluisteren en daaruit authenticatie verkeer filteren om vervolgens de opgevangen hashes proberen te kraken. In figuur 3 is te zien hoe Cain authenticatieverkeer heeft onderschept en in het voorbeeld is een LM-hash te zien. Vervolgens kunnen we deze hash-waarde proberen te ontcijferen (figuur 4). Door één voor één de hash van alle mogelijke tekencombinaties te vergelijken met hashes in de toegangslijst. Dit noemen we ook wel een brute force attack: Met rekenkracht alle mogelijke combinaties onderzoeken. In plaats van hash-waarden telkens opnieuw te berekenen en te testen, kunnen de hash-waarden van een grote hoeveelheid wachtwoorden ook vooraf worden berekend en in een omvangrijke lijst opgeslagen, een zogenoemd woordenboek. Met zo n lijst kan efficiënt worden teruggezocht. De hashwaardes kunnen immers nu op een slimme, snellere manier worden opgezocht in de van tevoren gevulde tabel. Door deze aanpak hoeft slechts een klein deel van de varianten te worden uitgeprobeerd. Zo n lijst omvat wel al snel enkele gigabytes aan informatie: de rainbow-tabel. Afhankelijk van de complexiteit van het wachtwoord en de capaciteit van de pc, duurt het kraken nog maar minuten of zelfs seconden. Dit is ook wel bekend als een rainbow table atttack. Er is een aantal aanvalstechnieken gericht zich rechtreeks op specifieke zwakheden in de gebruikte encryptiemethode. Deze catagorie aanvallen is bekend onder de naam cryptoattack. Het is mogelijk de hash-waarde niet te kraken maar deze te injecteren in een authenticatieverzoek. Deze methode werd diverse keren gedemonstreerd door Marcus Murray van TrueSec security met het programma msvctl. Een combinatie van al deze methoden is ook mogelijk. Dus bijvoorbeeld een woordenboek aanval combineren met brute rekenkracht. Figuur 4: het kraken van hashes met Cain Dit kan door een aantal methodes: Door snel achter elkaar passwords te proberen, te versleutelen en daarna te kijken of de hashwaarde overeenkomt. Zijn de waardes gelijk, dan hebben we het password gevonden. Dit noemen we ook wel een woordenboek aanval of dictionary attack. NTLMv2 Helaas is gebleken dat ook NTLM niet veilig genoeg is. NTLM versie 2 of kortweg "NTLMv2" werd de opvolger van NTLM en is door Microsoft uitgebracht nadat er tools beschikbaar kwamen zoals "L0phtCrack", een passwordkraakprogramma van L0pht Heavy Industries of Cain, software die het makkelijk maakt om hashes te kraken en passwords te achterhalen. NTLMv2 is een sterke verbetering ten opzichte van eerdere protocollen, omdat er een nieuwe versleutelingmehodiek wordt gebruikt en er meer gegevens in het authenticatieproces worden opgenomen. Het aanloggen van de gebruiker gebeurt met zijn gebruikersnaam (username), password en een Windows domein. De gebruikersnaam en het domein worden opgeslagen. Van het password wordt "on the fly" 28 mei 2010 TechNet Magazine

6 we ook te maken met drie onderdelen die betrokken zijn in het authenticatieproces, te weten: Tekening 3: het kraken en raden van passwords een hash berekend en tijdelijk bewaard. Passwords worden niet opgeslagen. Als men vervolgens een service op een server aanroept en wil authenticeren, stuurt de client de inlognaam naar de server. De server stuurt een willekeurig nummer naar de client, ook wel de "challenge" genoemd. Vervolgens zal de client versleuteld de challenge samen met een hash van zijn password terugsturen naar de Domain Controller, dit is de response. De domain controller kan met behulp van de verkregen gebruikersnaam de bijbehorende password-hash opzoeken in de Active Directory database. De Domain controller kent dus de gebruikersnaam, de passwordhash en de challenge. Hiermee kan de response opnieuw worden berekend op de Server. Als de verkregen waarde hetzelfde is als de ontvangen response, is de authenticatie succesvol. De client-zijde maakt dus in tegenstelling tot eerdere protocollen ook gebruik van een zogenaamde "challenge". Binnen NTLMv1 maakte alleen de server hiervan gebruik in het authenticatieproces. Daarnaast worden zogenaamde "timestamps" gebruikt op verstuurde berichten. Er wordt een tijd meegegeven aan het bericht. Dit maakt het veel moeilijker om pakketjes af te luisteren of te injecteren op het netwerk, of pakketjes aan te passen en deze opnieuw te versturen, ook wel bekend onder "replay attacks". NTLMv2 is dus veel veiliger dan LM en NTLM en toch worden deze laatste twee nog steeds veel gebruikt binnen Windows infrastructuren. Kerberos Tenslotte heeft Microsoft Kerberos neergezet als hét standaard authenticatie protocol voor Windows Active Directory domeinen en als vervanger van eerdere protocollen zoals NTLM en NTLMv2. Kerberos heeft de voorkeur als een gebruiker en computer onderdeel is van een Windows domein. Kerberos deed zijn intrede met de komst van Active Directory (Windows 2000). Kerberos is een afgeleide van Cerberus, de hond met drie koppen die in de oudheid de ingang van de onderwereld bewaakte. In het geval van Kerberos-authenticatie hebben Een client, de server of service waartoe toegang wordt gevraagd, en het Key Distribution Center ofwel de KDC. De KDC is een partij die door zowel de client als de server of service wordt vertrouwd. De Domein Controller binnen een Active Directory domein heeft de rol van KDC. Als een gebruiker vanaf zijn of haar werkstation toegang wil tot een folder op de server, dan zal er eerst een communicatiekanaal moeten worden opgezet. Voor deze communicatie wordt een sleutel gegenereerd, die alleen geldig is voor de duur van de communicatie. Dit gaat als volgt: De gebruiker voert zijn gebruikersnaam en password in. Het werkstation zal het password versleutelen en doorgeven aan het Kerberos-proces. Het Kerberos-proces zal de password-hash gebruiken om een authenticatieverzoek aan te maken met een timestamp en dit verzoek doorgeven aan de KDC. De KDC ontvangt het verzoek tot authenticatie en zal het timestamp controleren en vergelijken met de eigen tijdklok. De Kerberos-policy is standaard vijf minuten, vandaar dat de systeemtijd niet te veel mag afwijken in een Windows Active Directory domein omdat aanloggen dan niet meer mogelijk is. Als het verschil te groot is, zal het verzoek worden afgewezen. De KDC gebruikt nu het in de Active Directory opgeslagen hash van het versleutelde password om dezelfde berekeningen uit te voeren als de client. Is dit gelijk, dan is er succesvolle authenticatie De KDC stuurt nu een Ticket Granting Ticket terug naar het werkstation. Dit is te vergelijken met een geldige toegangskaart. Vervolgens zal de TGT gebruikt worden om toegang te krijgen door nu een session ticket aan te vragen bij de KDC. Dit is noodzakelijk om toegang te krijgen tot het werkstation. De KDC zal het gestuurde verzoek en ticket controleren en ziet dat het eerder werd voorzien van een digitale handtekening afkomstig van de KDC zelf. Na nog enkele controles zal een session ticket worden gestuurd naar het werkstation waarmee de gebruiker toegang krijgt. Elke keer als nu toegang naar een server of service nodig is, zal er een session-ticket noodzakelijk zijn en door de KDC enkele controles worden uitgevoerd zoals de controle of er toegang tot de gevraagde service is toegestaan. Is dit het geval, dan zal telkens een nieuwe TechNet Magazine mei

7 session-ticket worden uitgegeven. Op basis van dezelfde TGT die bij de eerste aanmelding is gegenereerd, geeft de KDC telkens een nieuw session-ticket af voor de verschillende services. Zowel de TGT als de session ticket blijven enige tijd geldig en kunnen dus meerdere keren worden gebruikt om de sessies op te bouwen. Dit minimaliseert de belasting van de KDC, de services en de servers. Als een gebruiker de sessie zal beëindigen door bijvoorbeeld het werkstation af te sluiten of uit te loggen, zullen de tickets vervallen en is het hele proces zoals hiervoor besproken weer noodzakelijk om toegang te krijgen tot zowel het Active Directory domein als individuele servers en services. Kerberos maakt gebruik van symmetrische encryptie en is complexer en veiliger dan andere authenticatie protocollen vooral omdat beide partijen binnen de op te zetten communicatie zich telkens moeten authenticeren. Er zijn maatregelen genomen om replay attacks tegen te gaan en er is een betere encryptietechnieken gebruikt. Kerberos binnen Server 2008 en Windows Vista en Windows 7 biedt bovendien ondersteuning voor AES encryptie, op dit moment het veiligste encryptiealgorithme, NTLM biedt deze mogelijkheden niet. Een belangrijk verschil tussen NTLM en Kerberos is, dat bij de ontwikkeling van alle stappen het Kerberos-protocol is uitgegaan van een onveilig netwerk, dus een vijandige netwerkomgeving. Kerberos kent dan ook geen zwakke plekken. Kerberos is bovendien een standaard die wordt ondersteund door vele marktpartijen. Het gebruik van Kerberos als standaard authenticatie methode in een Active Directory omgeving heeft dan ook de voorkeur. Als Kerberos zo betrouwbaar en veilig is, waarom gebruiken we dan niet alleen nog dit protocol? De praktijk is vaak weerbarstig. Redenen waarom Kerberos niet afdoende is, zijn: Authenticatieinstellingen zijn niet aangepast aan de eigen situatie. Daardoor worden LM, NTLM of NTLMv2 gebruikt, terwijl het beter is de oude protocollen te laten vallen. Er is sprake van legacy-applicaties waardoor de noodzaak bestaat om oude authenticatieprotocollen te handhaven. Er zijn oude Windows systemen in de infrastructuur aanwezig die Kerberos niet ondersteunen en terugvallen op LM en NTLM noodzakelijk blijft. Er wordt toegang gezocht tot een machine buiten het Active Directory domein en daarbij is terugvallen op LM ofntlm noodzakelijk. Er is toegang nodig tot een machine in een ander Active Directory Forest en er is daarbij geen trust tussen de twee Forests. Bij toegang tot een machine wordt het ipadres gebruikt en niet de computernaam. Ook in dat geval is terugvallen op LM, NTLM noodzakelijk. Verbeteren van de beveiliging Na alle informatie in dit artikel is het tijd om de balans op te maken en te kijken hoe we nu het beste authenticatie kunnen inrichten binnen een Microsoft infrastructuur. Daarom een aantal tips. Als het werken met de LM-hash niet expliciet noodzakelijk is, zorg dan in ieder geval dat het genereren en opslaan van de LM-hash wordt tegengegaan door de juiste instellingen door te voeren. Dit kan door de policy NoLMHash toe te passen. Dit kan gevonden worden onder Network security: Do not store LAN Manager hash value on next password change. Figuur 5 toont deze instelling voor Server 2008 R2. Zorg wel dat daarna alle gebruikers Figuur 5: de LM hash policy aanpassen 30 mei 2010 TechNet Magazine

8 kort daarna gedwongen worden om hun password te wijzigen. Gebruik geen passwords die korter zijn dan 15 karakters. Automatisch zal dan het niet meer mogelijk zijn om LMhash te gebruiken binnen authenticatie. U vraagt dan wel een extra inspanning van uw gebruikers voor deze work-around. Zorg ervoor dat machines die voorzien zijn van een oud besturingssysteem naar nieuwere versies worden gemigreerd zodat een betere authenticatie is af te dwingen. Met Kerberos kunnen smartcards en certificaten worden gebruikt. Door gebruik van smartcards of tokens met certificaten is het mogelijk op een betere authenticatie over te stappen. Een Public Key Infrastructuur voor de uitgifte van persoonsgebonden digitale certificaten kan daarna worden gebruikt voor systemen waarop de meest gevoelige informatie is te vinden binnen uw bedrijf. Zorg ervoor dat NTLMv1 niet meer in gebruik is maar dat er standaard naar NTLMv2 wordt gekozen. NTLMv2 wordt ondersteund vanaf Windows XP, Windows Server 2003, Windows Vista, Windows Server 2008 en Windows 7. Er is eigenlijk geen excuus om dit niet te doen. NTLMv2 is bovendien ook mogelijk als er sprake van een mixed-mode omgeving. Windows Vista, Server 2008 en Windows 7 zijn standaard ingesteld om geen LM-hash meer op te slaan en alleen te werken met NTLMv2. Dit is een goede zaak. Zorg dat gebruikers hun password regelmatig wijzigen en dwing een complex wachtwoord af met de daarvoor bestemde policies. De keuze van het authenticatie protocol wat effectief gebruikt zal worden is te beïnvloeden door policies aan te passen binnen de Windows-infrastructuur. Er is hier een aantal mogelijke instellingen. In de onderstaande lijst zal het nummer corresponderen met de waarde van de LM-Compatibility registry sleutel en de corresponderende policy die geïmplementeerd kan worden. In figuur 6 zijn deze policies terug te vinden op een Windows Server 2008 machine. Er zijn in totaal 6 waarden mogelijk. 0 = Send LM and NTLM responses. Dit is de standaard instelling van Windows XP en hierbij worden LM en NTLM gebruikt. Er zal bij deze instelling geen NTLMv2 worden gebruikt. 1 = Send LM and NTLM; use NTLMv2 session security if negotiated. Hierbij zal eerst LM en NTLM worden gebruikt en alleen NTLMv2 als dit wordt ondersteund. 2 = Send NTLM response only. Dit is de standaard instelling van Windows Server Er zal eerst NTLM gebruikt worden en wanneer mogelijk NTLMv2. 3 = Send NTLMv2 response only. Hierbij zal standaard NTLMv2 authenticatie worden gebruikt en niet meer een voorkeur zijn voor LM en NTLM. 4 = Send NTLMv2 response only, Refuse LM. Hierbij zal NTLMv2 authenticatie alleen nog maar worden gebruikt op de client, maar Domein Controllers accepteren nog NTLM. 5 = Send NTLMv2 response only, Refuse LM & NTLM. Bij deze instelling kan binnen het domein alleen nog gebruik gemaakt worden van NTLMv2 authenticatie. De instellingen moeten worden bekeken vanuit het client en server perspectief. De instellingen 0, 1, 2 en 3 zullen effect hebben indien de Windows machine als een client fungeert. De instellingen onder 4 en 5 zullen effect hebben op het moment dat de Windows machine als een authenticatie server optreedt. Let op, ook andere servers en niet alleen Domain Controllers zullen authenticatie uitvoeren. Dit kan ook gebeuren met behulp van de lokale SAM database. Het advies is (indien dit mogelijk is) om te gaan voor instelling 3. Dit is vanaf Windows Vista ook de standaard instelling. Zowel uitgaand als inkomend authenticatieverkeer zal alleen nog NTLMv2 zijn, daarmee voorgoed afscheid nemend van oude, minder veilige protocollen. Figuur 6: instellen van het authenticatie niveau TechNet Magazine mei

9 Maak gebruik van complexere wachtwoorden of zelfs kleine zogenaamde passphrases, regels met woorden. Door een aantal eenvoudige maatregelen te nemen, is een wachtwoord in de regel veel lastiger te kraken. De volgende tips: o Gebruik zowel grote als kleine letters, getallen en speciale tekens o Gebruik van een bepaald patroon mag, zoals eerste twee kleine letters, een hoofdletter en daarna een getal o Gebruik getallen in passwords en gebruik ook speciale tekens, door bijvoorbeeld tijdens de invoer op het toetsenbord de Shift-toets in te drukken o Gebruik als geheugensteun een eenvoudige zin en gebruik dan alleen de eerste letters van de woorden met toevoeging van getallen en een leesteken zoals een vraagteken aan het einde van de zin Inzet van sterke authenticatie Het gebruik van passwords en complete zinnen (passphrases) is nog steeds de meest gebruikte methode om toegang te realiseren en authenticatie uit te voeren tot het Windows Platform. Als we de complexiteit van de wachtwoorden en de gebruikte protocollen op een zo hoog mogelijke standaard zetten, is dit natuurlijk nog steeds een prima methode. Helaas zien we vaak het tegenovergestelde en is het voor mensen toch ook gewoon moeilijk om met complexe passwords om te gaan. Zeker als deze ook nog eens met regelmaat moeten worden gewijzigd. We zien de laatste jaren daarom een verschuiving en opkomst van sterke authenticatie (two factor authentication). Sterke authenticatie is dat naast een password nog iets anders noodzakelijk is voor toegang. Sterke authenticatie kent dus altijd twee onderdelen zoals: Iets wat je weet zoals een pincode, password of andere tekenreeks Iets wat je in je bezit hebt zoals een speciaal token of een smartcard Iets wat een uniek biometrisch kenmerk van de gebruiker is, zoals een vingerafdruk of een irisscan Sterke authenticatie gebruikt uit deze lijst een combinatie van twee. Een voorbeeld hiervan is een smart card met pincode of een token met pincode. Tegenwoordig zien we dan ook steeds vaker het gebruik van smartcards of tokens met daarin een smartcard-chip verwerkt. Daarnaast zijn veel draagbare computers tegenwoordig al uitgerust met een vingerafdruklezer naast het toetsenbord of een sleuf voor een smartcard in de zijkant. In combinatie met een certificateninfrastructuur is het dan mogelijk om persoonlijke digitale certificaten uit te reiken aan gebruikers binnen de infrastructuur. Een smartcard kan gebruikt worden om het digitale certificaat op te bewaren en in combinatie met een pincode kunnen gebruikers toegang krijgen tot de Windows infrastructuur. Het certificaat op de smartcard is daarbij dan een unieke combinatie voor die gebruiker. Deze stap in combinatie met andere maatregelen zal een enorme verbetering in het beveiligingniveau opleveren. Conclusie Hoewel Windows Vista, Windows Server 2008 en Windows 7 standaard al verbeteringen in authenticatie bieden, zien we dit in de praktijk vaak onbenut. Het is echter zeker de moeite waard en ook noodzakelijk om kritisch te kijken naar bestaande instellingen en de werking van authenticatie binnen de infrastructuur. Het belangrijkste daarbij is dat afscheid genomen wordt van het LM-protocol. Met de voorbeelden die in dit artikel zijn gegeven, hoop ik een aantal aspecten te hebben belicht die u helpen om een aantal maatregelen nemen die de beveiliging van uw infrastructuur naar hoger niveau brengt. De mogelijkheden zijn er en het staat u vrij om te kiezen voor aanvullende maatregelen in de vorm van sterke authenticatie. Ook hier zijn de laatste jaren enorme verbeteringen geweest die het opzetten van een PKI-infrastructuuur veel gebruiksvriendelijker hebben gemaakt, zodat Kerberos gemakkelijker en goedkoper kan worden geïmplementeerd. Ro b Fa b e r, CISSP, CEH, CFI, MCTS, MCSE (rob.faber-at-icranium.com) is een Security Architect, trainer en auteur. Hij werkt op dit moment voor Achmea binnen de unit Strategy & Governance. Hij heeft meer dan 14 jaar ervaring binnen de IT en is gespecialiseerd op het vlak van Informatie beveiliging, Windows Platform Security, Ethical Hacking en Forensics. In zijn vrije tijd zeilt hij, onderneemt graag dingen met zijn gezin en deelt hij kennis op zijn website: 32 mei 2010 TechNet Magazine