TSTC LIVE

Waar Microsoft vorige maand nog met het nieuws kwam dat alle nog lopende MCSA en MCSE examens per 30 juni 2020 zouden ophouden te bestaan, hebben ze nu ivm de corona/covid-19 uitbraak besloten deze termijn te verlengen tot 31 januari 2021.

Net nu we een beetje gewend zijn aan de nieuwe role-based Microsoft certificeringen, gooit Microsoft het roer voor wat betreft de Azure Administrator Associate (AZ-100 & AZ-101) certificering alweer om.

Van 22 t/m 26 oktober 2018 heb ik (Microsoft trainer Marco Dufour) namens TSTC deelgenomen aan de Microsoft MCT Global Summit 2018 in Duitsland. Naast diverse technische sessies was er ook veel informatie over de weg die Microsoft inslaat met de nieuwe rolebased certificeringen. In deze blog geef ik een overzicht van de informatie die Microsoft Learning ons die week gaf.

Microsoft heeft de veelgehoorde kritiek ter harte genomen dat men voor het behalen van een Azure (MCSA / MCSE Cloud Platform) certificering veel meer moest weten dan strikt noodzakelijk voor de meeste gerelateerde functies. Eind dit jaar en in de loop van 2019 wordt een compleet vernieuwd programma uitgerold met nieuwe certificeringen gebaseerd op zg. job roles. Dit houdt tevens in dat de nu nog lopende 70-532, 70-533 en 70-535 examens (en trainingen) per 31 december 2018 komen te vervallen. Reeds gecertificeerde professionals kunnen met behulp van speciale transitie examens upgraden naar de nieuw gelanceerde titels. 

Vorige week lanceerde Microsoft vier nieuwe MCSE certificeringen en maakte daarbij direct het vervallen van de huidige MCSE titels bekend (per 31-3-2017). De nieuwe titels sluiten één-op-één aan op de ‘Centers of Excellence’ die in het Microsoft Partner Network worden gebruikt om technische competenties aan te duiden en moeten daarbij bijdragen aan de herkenbaarheid bij zowel Microsoft Partners als hun klanten.

Phishing, identity theft, credential theft, impersonation, data leakage. Het zijn allemaal termen binnen IT security die op de één of andere manier te maken hebben met het verkrijgen c.q. misbruiken van credentials. Wij proberen onze gebruikers goed voor te lichten, vaak aan de hand van awareness sessies, over de gevaren van zwakke wachtwoorden, het inloggen op onveilige websites, hergebruik van wachtwoorden etc.

Het gevaar schuilt echter niet alleen bij de gebruiker. Het wachtwoord moet immers ook bekend zijn bij de authenticerende computer (lokaal of remote, zoals bij Active Directory). Hoe gaat Windows vervolgens om met wachtwoorden van ingelogde gebruikers?​ Programma’s zoals Mimikatz laten zien dat iemand die kwaad wil eenvoudig wachtwoorden of wachtwoord hashes van ingelogde gebruikers kan achterhalen en erger dan dat. Microsoft heeft met Isolated User Mode een goede stap gezet om aanvallen à la Mimikatz en “pass-the-hash” te voorkomen. In dit artikel ga ik in op deze nieuwe feature en leg uit hoe Windows 10 ervoor zorgt dat kwaadwillenden dankzij Isolated User Mode geen mogelijkheid meer hebben tot het verkrijgen van wachtwoorden en wachtwoordhashes die in het geheugen van Windows 10 vastgehouden worden.

User mode / Kernel mode

Om te begrijpen hoe Isolated User Mode werkt en waar het voor is, gaan we eerst kijken hoe programma’s normaliter met elkaar communiceren.

In Windows heb je de User mode, dit staat ook wel bekend als ring 3 (afb. 1), waarin de applicaties draaien die wij starten. Een applicatie bestaat uit het programma zelf plus de libraries die door de applicatie aangeroepen worden. Wanneer een programma gestart wordt, zal dit in het geheugen geladen worden en krijgt het een process id toegekend. De applicatie (het proces) krijgt ook een stukje van het intern geheugen aangereikt, een private virtual address space, zodat hij in het geheugen kan worden geladen.

Stel dat er twee applicaties draaien, ieder met zijn eigen process id. Is het dan mogelijk dat het ene proces toegang heeft tot de virtual address space van een ander proces? Nee. Een applicatie heeft alleen toegang tot zijn eigen geheugenadressen.

Figuur 1; bron: blog.codinghorror.com

Maar wat draait er nou precies in Kernel mode (dit is ring 0)? Uiteraard draaien hier de basale besturingssysteem onderdelen. Verder draaien er in de kernel ook kernelmode drivers. Het is belangrijk te weten dat alle processen die in Kernel mode draaien, één enkel virtual address space delen!!! Oftewel, een kernel mode driver kan in principe bij alle andere code van de drivers én van het besturingssysteem. Een slecht geschreven driver zou daardoor de stabiliteit van jouw Windows omgeving onderuit kunnen halen en de computer laten crashen.

Ringen 1 en 2 worden eigenlijk niet gebruikt.

Wanneer een programma een deel van het geheugen wil benaderen dat niet van hemzelf is, dan kan hij een interrupt genereren voor een API (Application Programming Interface). De processor zal dan in kernel mode schakelen om die API te starten, welke op zijn beurt bijvoorbeeld het commando ReadProcessMemory uit kan voeren. Dat commando mag enkel in Kernel mode uitgevoerd worden. Daarna schakelt de processor terug naar User mode en kan de applicatie de ontvangen informatie verwerken.

Lsass

Van alle processen die Windows standaard draait, is lsass (Local Security Authority Subsystem Service ) één van de meest interessante. Althans, vanuit de ogen van de hacker. De virtual address space van lsass bevat namelijk de wachtwoord hashes van alle ingelogde gebruikers. Dankzij Pass-the-hash technieken heeft een aanvaller voldoende aan de hash van het wachtwoord om te authenticeren. Dat doet lsass per slot van rekening op exact dezelfde manier…

Met Windows 8.1 heeft Microsoft bij de introductie van een speciale Active Directory groep genaamd Protected Users voor gezorgd dat lsass de wachtwoorden en hashes opruimt en er zo min mogelijk in het geheugen te vinden zijn (fig. 2).

Figuur 2; bron: dirteam.com

Verder kan het lsass proces middels een registry aanpassing als protected process gaan draaien, waardoor wachtwoorden en hashes alleen zo lang bewaard worden in het geheugen, als nodig is. Hierdoor wordt het oogsten van wachtwoorden en hashes alweer wat lastiger. Mocht je meer over de technieken in Windows 8.1 willen weten, open dan de bron die bij figuur 2 staat vermeld.

Address translation

We zijn nu bijna op het punt beland waarop we kunnen zien wat Isolated User Mode voor ons betekent. Hiervoor moet echter wel helder zijn wat het begrip “address translation” inhoudt.

Wanneer twee processen op dezelfde manier geschreven zijn en beide willen naar hetzelfde geheugenadres gaan, bijvoorbeeld adres 5000, dan zou dat niet kunnen. Zij verwijzen dan ook naar een virtual address space. Ieder proces heeft zijn eigen pagetable die de virtual address space vertaald naar de physical address space. Wanneer beide processen het adres 5000 opzoeken in hun pagetable, zullen beide er een ander fysiek adres uit krijgen dat echt correspondeert met het juiste, echte geheugenadres. Daarnaast krijgen de processen ook te horen welke toegang ze krijgen tot dat geheugenadres: read, write, execute.

Wanneer je Hyper-V draait, komt er onder de kernel nog iets anders te draaien: de hypervisor. Dit wordt tegenwoordig ook wel Ring -1 (min 1) genoemd. Wanneer een virtual machine (VM) toegang wil hebben tot het fysieke geheugen, werkt bovenstaand proces nog steeds op dezelfde manier. Echter, nu noemen we het physical address ineens de Guest Physical Address (GPA). De GPA is niet het echte fysieke adres, omdat we nu te maken hebben met een gevirtualiseerde omgeving. Daarom wordt de GPA gemapped naar het fysieke adres, wat nu het System Physical Address (SPA) heet. Het systeem dat hiervoor gebruikt wordt, heet Second Level Address Translation (SLAT). Diverse processoren hebben een feature die SLAT efficiënter laten plaatsvinden. Server 2012 R2 Hyper-V had nog een software shadow page table, die hardwarematige SLAT ondersteuning niet verplichtte (tenzij RemoteFX nodig was), maar de Hyper-V implementaties in Windows 8, 8.1, 10 en Server 2016 vereisen dat de processor SLAT ondersteunt.

Isolated User Mode

In Windows 10 gaat Microsoft een flinke stap verder in het beveiligen van lsass. Nu wordt gebruik gemaakt van een nieuwe feature in Client Hyper-V: Virtual Secure Mode. Nu krijg je naast de gewone Kernel mode nog een Secure Kernel mode. Beide hebben hun eigen pagetable, maar nu ook hun eigen SLAT… Stel dat vanuit beide kernels dezelfde GPA uitgegeven wordt, dan zal iedere SLAT hetzelfde SPA uitgeven, maar wel met een ander access level. Zo kan de “oude” kernel mode wel access krijgen, maar dan met de mededeling: geen read, geen write, geen execute.

Wanneer een proces in de normale kernel mode toegang wil hebben tot lsass en diens geheugenadressen, dan gaat dit verzoek via de secure kernel mode en vindt er een controle plaats om te voorkomen dat er acties uitgevoerd worden die ervoor zouden kunnen zorgen dat er toegang verkregen zou kunnen worden tot de geheime informatie. De code wordt “sanitized”.

Om de secure kernel zo veilig mogelijk te maken, heeft Microsoft gepoogd alle soorten van aanvallen te blokkeren die hackers uit kunnen voeren. Zo zorgt het uitschakelen van de isolated user mode ervoor, dat alle wachtwoorden en encryptiesleutels worden gewist. Een hacker heeft er dus niks aan om die feature uit te zetten: hij komt niet bij de gewenste informatie!

Naast het beschermen van het lsass proces, bevat de secure kernel ook de sleutels die gebruikt worden door vTPM. In dit artikel ga ik niet verder in op deze nieuwe feature, maar zie het als een virtuele TPM chip voor virtuele machines. Hierdoor kun je bij een Hyper-V server iedere virtuele machine voorzien van een softwarematige TPM chip ten behoeve van data encryptie.

Isolated User Mode applicaties kunnen op dit moment alleen nog gemaakt worden door Microsoft. Wellicht dat dit in de toekomst gaat veranderen, maar dit is op moment van schrijven nog onbekend.