jekob heidelberg bloghoved

Få kontrol over de hoppende og ustyrlige lokale administratorer

Trods titlen handler dette indlæg ikke om, hvorvidt organisationens almindelige brugere er gjort til lokale administratorer eller ej. Dét sprængfarlige emne har jeg allerede behandlet i indlægget ”Smid nu de lokale administratorer på porten!” – og min, såvel som Microsofts og alverdens sikkerhedsfirmaers, anbefaling er uændret og står vist rimelig klar.

Nærværende indlæg handler derimod om, hvordan man bedst håndterer den lokale ”Administrator” konto, som er indbygget i Windows operativsystemet, både hvad angår tilhørende adgangskode(r) og tildelte rettigheder.

Kontoen er historisk set hadet af systemadministratorer pga. dens uhåndterbarhed, og elsket af hackere pga. den vidtrækkende anvendelighed, men det kan og bør stoppes nu!

Nogle almindelige scenarier

Der er mange måder at holde styr på disse lokale Administrator konti, der er tildelt SID ”S-1-5-*-500” (uanset omdøbning), hvor * udgør en maskin-individuel GUID-værdi. Hvilken metode der er den rigtige, er svært at sige, idet det afhænger meget af organisationens behov og konkrete situation, herunder foretrukne udrulningsværktøjer og management-teknologi.

Man kan derimod ret entydigt sige noget om, hvad der er forkerte løsninger ud fra et sikkerhedsmæssigt perspektiv, og som penetration tester møder jeg desværre stadig en del af dem. Næsten alt for mange til, at det er en særlig udfordring at agere angriber i et gennemsnitligt Windows-miljø, men det er i bund og grund ikke operativsystemets skyld.

Jeg ser eksempelvis stadig organisationer, der vælger at udrulle med én standard adgangskode for Administrator kontoen, som så genanvendes på samtlige klienter - og sommetider også servere (!); andre udruller med unikke adgangskoder (pr. maskine), i visse tilfælde f.eks. genereret ud fra maskinens serienummer; andre igen vælger at sætte et stærkt engangskodeord under udrulning, deaktivere kontoen og glemme alt om den; andre har dyre password management systemer til at håndtere løbende kodeskift osv.

Af ovenfor nævnte ”løsninger” på problematikken, er den første at regne for komplet uforsvarlig, eftersom en kompromittering af én klient, meget hurtigt fører til kompromittering af samtlige Windows maskiner i miljøet og Active Directory (AD) domænet som sådan, afhængigt af netværkssegmentering og konfiguration af host-firewalls. En angriber hopper oftest uhindret fra maskine til maskine, indtil der opnås adgang til en, hvor der er en Domain Admin logget på, hvorefter det i en vis forstand er ”Game Over” (kort sagt: Mimikatz).

Identiske lokale administrator konti er med andre ord en rigtig dårlig idé.

Jeg vil nedenfor komme tilbage til den opdatering, Microsoft udsendte sidste år for at imødegå denne ”hoppende” trussel, også kendt som ”lateral movement” jf. ”Mitigating Pass-the-Hash and Other Credential Theft, version 2”, ligesom jeg vil komme ind på Microsofts nye gratis password management løsning, men først lige et par ord mere om de nævnte almindelige scenarier.

Unikke løsninger, der fejler

At have unikke adgangskoder, hvordan man så end påtrykker dem klienter og servere, er klart en fordel, men kun såfremt der ikke er et (gennemskueligt) mønster, de genereres ud fra, f.eks. computernavn og serienummer. Det skal nemlig siges, at lokale adgangskoder kan udlæses af registreringsdatabasen i klartekst (!) relativt enkelt, så snart man har opnået SYSTEM rettigheder.

Under en penetration test opdagede jeg eksempelvis, at organisationen havde sat adgangskoden for Administrator-kontoen ved at generere en hash-værdi af computernavnet. Umiddelbart lyder det smart, men en erfaren angriber genkender hurtigt en hash-værdi og det tager ikke nødvendigvis lang tid at bryde (f.eks. med hashcat og en custom wordlist), og hvis nogen - blot én gang - skulle få kendskab til den anvendte logik og algoritme (f.eks. tidligere medarbejdere, insidere eller via social engineering), så kan de gætte sig til resten og slaget er tabt.

Vælger man en metode til at sætte helt unikke og (relativt) tilfældige kodeord, står man tilbage med valget mellem at gemme det et (centralt) sted eller at ”smide det ud”. Gemmer man det, f.eks. fordi man vurderer, at det er essentielt at man senere kan logge på med den lokale Administrator konto, så skal adgangskoden transporteres sikkert (krypteret i transit) til en sikret central database eller lignende, hvor privilegerede brugere kan slå dem op. Jeg har set en del mere eller mindre fejlede og hjemmelavede script-løsninger i den forbindelse.

En mulig omgåelse af problemet

Man kan undgå meget bøvl, hvis man helt giver afkald på muligheden for nogensinde at tilgå maskinen med den lokale Administrator konto. Nogle organisationer vælger at ”glemme” alt om den lokale Administrator konto, der for mange først er relevant (igen) i det tilfælde, at man af den ene eller den anden årsag ikke har forbindelse til domænet, herunder offline restore scenarier, eksempelvis (live) forensics og malware/ransomeware udbrud.

I værste fald kan man – såfremt man har fysisk adgang til maskinen – ”hacke” den lokale Administrator konto vha. forskellige metoder, også hvis der er aktiveret BitLocker, hvilket blot kræver adgang til recovery-information, der bør befinde sig i Active Directory.

Jeg vil ikke her gå i detaljen med Cached Credentials, det skal blot nævnes, at de udgør en anden mulig ”bagdør”. Se f.eks. mere om dette her: Cached domain logon information. Men, insisterer man på at have en aktiveret lokal Administrator konto, og/eller har man sikkerhedskrav der foreskriver, at adgangskoder på lokale konti skal skiftes jævnligt, så kan det nu også gøres forholdsvis enkelt og sikkert – uden ekstra licensomkostninger.

Microsoft til undsætning – bedre sent end aldrig

Med funktioner introduceret med Group Policy Preferences (GPP) så det først ud til, at Microsoft havde løst problemet med administrationen af disse lokale konti, men som jeg skrev i ”Historien om en feature der aldrig skulle have været der”, så viste det sig at være en meget usikker implementering (hackere elsker det).

Microsoft kom dog her i maj 2015 stærkt tilbage med en løsning, nemlig den såkaldte Local Administrator Password Solution (LAPS), der er en videreudvikling og officielt supporteret version af ”Local admin password management solution”, som har ligget til fri download på MSDN gennem flere år. Den kom bare aldrig rigtig til sin ret, nok mest fordi den ikke var supporteret af Microsoft.

Med den nye LAPS løsning foregår administrationen af de lokale Administrator konti relativt nemt, efter det først er sat op (kræver en skema-udvidelse i AD og kørsel af nogle scripts). Det fungerer kort fortalt vha. en ny Client-Side Extension (CSE) på Windows klienter (Windows 7 og senere) og servere (Windows Server 2003 SP2 og senere), centrale gruppepolitikker og nogle sikkerhedsindstillinger på givne objekter i AD.

Maskinens lokale CSE holder løbende øje med, om det er tid til at skifte adgangskoden. Det gøres ud fra maksimums-alderen for adgangskoder, der defineres i en tilhørende gruppepolitik. CSE’en genererer en unik og (relativt) tilfældig adgangskode, der lever op til den definerede politik for kompleksitet og længde, sætter den lokalt og opdaterer computerobjektet i AD over en krypteret forbindelse (Kerberos v5). Herefter kan udvalgte privilegerede brugere aflæse den definerede adgangskode og hvornår den udløber igen.

Illustration: Privatfoto

Det er ganske smart og løser mange problemer, langt om længe - og jeg vil kraftigt anbefale, at man overvejer at implementere LAPS, men vi skal også lige se på en anden mulighed for at sætte en (ekstra) forhindring op for de hoppende lokale administratorer.

Isolering ved at fratage rettigheder

Microsoft frigav for lidt over et år siden KB2871997, som indeholdt en række forbedringer af sikkerheden i Windows-baserede miljøer, og selvom de fleste organisationer (forhåbentlig) efterhånden har fået rullet opdateringen ud, så har man ikke nødvendigvis fået aktiveret de indstillinger, der højner sikkerheden markant i tilfælde af kompromittering af enkelte maskiner.

Specifikt tænker jeg her på anvendelsen af 2 nye ”well known” Security Identifiers (SID), der nu er del af operativsystemet. Den første er “Local account” (S-1-5-113), som enhver lokal brugerkonto nedarver implicit, og den anden er “Local account and member of Administrators group” (S-1-5-114), som enhver lokal konto, som er medlem af administrator gruppen, nedarver implicit.

Disse SID’er er introduceret for at gøre det nemmere, at forhindre lokale konti i at blive anvendt til angreb via netværket (bl.a. typisk for Pass-the-Hash angreb). Nu kan man således nemt konfigurere en gruppepolitik på organisationens maskiner, som forhindrer lokale brugerkonti i at logge på fra netværket (type 3 & 8 logon) og anvendelse af fjernskrivebord/Remote Desktop (type 10 logon).

Tidligere skulle man vælge de enkelte lokale brugerkonti eksplicit, hvis man forsøgte at forhindre nævnte funktionalitet, hvilket var et større arbejde pga. de maskin-individuelle SID'er. Nu kan man på få minutter udfærdige en central gruppepolitik, som blokerer angreb via netværket udført med (stjålne) lokal administrator eller bruger logon-oplysninger (credentials), så længe KB2871997 er installeret.

Jeg vil derfor hermed opfordre til, at man kontrollerer, om de inkluderede sikkerhedsfunktioner efterhånden er implementeret korrekt – herunder i øvrigt muligheden for at fjerne (visse) klartekst credentials fra LSASS hukommelsen. Her er det heller ikke nok, at man opdaterer operativsystemet - der kræves manuel handling.

En sidste bemærkning

Lad mig lige her på falderebet advare mod en beslægtet problematik. Selvom jeg indledte med hævde, at jeg ikke ville behandle organisationens almindelige brugere, der af den ene eller anden grund er tildelt lokale administrator rettigheder, så kan jeg alligevel ikke lade være.

Én ting er, at man overhovedet tillader det - en anden ting er, hvordan man implementerer det.

Jeg møder stadig (!) miljøer, hvor man gør brugere til lokale administratorer via én gruppe i AD, som er medlem af den lokale ”administrators” gruppe på klienterne. Det bevirker bare, at enhver bruger i denne gruppe, er administrator af samtlige Windows klienter i miljøet. I praksis er det næsten lige så godt som at være Domain Admin.

Det bør altså også stoppes – og det kan kun gå for langsomt.

Relevante links

Kommentarer (1)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Log ind eller Opret konto for at kommentere
IT Company Rank
maximize minimize