Hoe krijg je grip op computer-gebaseerde privileged accounts?
Brian de Vries is consultant bij Traxion
Privileged accounts zijn de kroonjuwelen van een organisatie en ze zijn in verschillende soorten te vinden. Het grootste onderscheid in de verschillende soorten privileged accounts is te maken op basis van het gebruik. Zo zijn er de privileged accounts die gebruikt worden door de beheerders en de privileged accounts die gebruikt worden door computersystemen. Een privileged account dat gebruikt wordt door een beheerder zal in de regel gemanaged of in ieder geval bekend moeten zijn. Een overzicht creëren en managen van de privileged accounts die gebruikt worden door computersystemen is uitdagender voor een organisatie.
In een eerdere blog heb ik aangegeven dat de implementatie van een oplossing voor Privileged Account Management (PAM) meer behelst dan een tool in gebruik nemen. Dat vraagt namelijk ook om cultuurverschuivingen. In deze blog ga ik dieper in op de vereiste cultuurverschuivingen om het beheren van privileged accounts die door computersystemen worden gebruikt mogelijk te maken.
Service, applicatie, hard-coded en robotic accounts
Er zijn verschillende typen privileged accounts die door computersystemen gebruikt kunnen. De meest bekende is een serviceaccount. Dit type account wordt bijvoorbeeld gebruikt om specifieke Windows-services te draaien. Denk aan een geplande taak die dagelijks automatisch uitgevoerd moet worden. Of een service ten behoeve van een database of applicatie. Het kan ook gaan om services voor bijvoorbeeld het automatisch installeren van software-updates of andere software-agents. Een applicatie-account wordt gebruikt binnen een applicatie om bijvoorbeeld een koppeling te maken met andere bedrijfsapplicaties of databases. Een voorbeeld hiervan is BizTalk of Orchestrator. In de interne logica van deze applicaties is het mogelijk om acties in andere applicaties of op een server te initiëren. Hard-coded accounts worden voornamelijk gebruikt binnen scripts. Dit kunnen Windows Powershell-scripts zijn, C++-scripts of Java-scripts. Maar ook binnen bijvoorbeeld Windows Internet Information Services (IIS) zijn hard-coded credentials te gebruiken voor bijvoorbeeld application pools of IIS virtual directories. En tenslotte is er een opmars van zogenaamde robotic accounts, door de snelgroeiende implementaties van RPA-toepassingen. De robotic accounts worden door de RPA-software gebruikt om in te kunnen loggen in de verschillende bedrijfsapplicaties die opgenomen zijn in de RPA-processen.
Principle of least privileges toepassen
Bij het installeren, ontwikkelen of implementeren van een nieuwe applicatie of script zullen er altijd nieuwe privileged accounts aangevraagd moeten worden. Veelal wordt er dan een privileged account aangevraagd met administratorrechten. Niet omdat dit altijd nodig is, maar omdat het gemakkelijk is. Als er dan problemen ontstaan, kan het in ieder geval niet aan de rechten liggen. En in veel gevallen is het ook nog een privileged account met rechten op domeinniveau binnen de organisatie. Een domeinaccount is namelijk terug te vinden in Active Directory en daardoor is het inzichtelijker in welke privileged accounts er binnen een organisatie zijn. Tenslotte kan dat privileged account tijdens de implementatie voor meerdere doeleinden gebruikt worden. Het wordt dus niet enkel gebruikt voor een specifieke Windows-service, maar voor meerdere services of servers. Of hetzelfde account wordt als applicatie-account gebruikt om te kunnen integreren met een andere applicatie. Hoe meer rechten een specifiek privileged accounts krijgt en naarmate het account op meerdere plekken gebruikt wordt, des te interessanter het voor een aanvaller wordt om dat account te willen bemachtigen. Het is daarom van belang om bij het aanmaken en toekennen van privileged accounts goed vast te stellen waarvoor het account gebruikt gaat worden. Indien er enkel leesrechten nodig zijn voor een aantal specifieke lokale mappen, ken deze dan ook enkel toe aan een lokaal account. Moet er vanuit de applicatie nog een koppeling gemaakt worden naar een andere applicatie? Maak dan een extra account aan met die specifieke rechten. De juiste minimale rechten toekennen aan een account wordt de ‘principle of least privileges” genoemd. Het kunnen toepassen daarvan vraagt dus aan de aanvrager goed uit te zoeken welke rechten er nodig zijn. Aan de andere kant zal de uitgever van het privileged account kritisch moeten zijn bij aanvragen en de rechten juist toepassen.
Lateral movement voorkomen
In de praktijk zien we vaak dat serviceaccounts op domeinniveau zijn aangemaakt waarbij er rechten zijn toegekend op meerdere servers. Op die servers zijn weer andere domeingerelateerde serviceaccounts gebruikt die rechten geven op een andere set servers. Dit biedt een mogelijke aanvaller de gelegenheid om lateraal te kunnen voortbewegen door de infrastructuur. Het gevolg kan zijn dat de volledige infrastructuur inclusief de domain controllers gecompromitteerd raken. En dat is in sommige gevallen al mogelijk op basis van drie verschillende privileged accounts.
Om de kans op lateral movement te verkleinen, is er een aantal mitigerende mogelijkheden. In het verlengde van de principle of least privileges is het wenselijk om lokale privileged account te gebruiken met unieke wachtwoorden boven domeingerelateerde privileged accounts. Als een lokaal privileged account gecompromitteerd is, kan deze niet gebruikt worden om op andere servers te komen. Ook is het mogelijk om op netwerkniveau logische scheidingen aan te brengen. Dit is mogelijk door het gebruik van interne firewalls, het aanbrengen van netwerk(micro)segmentatie of het implementeren van het Microsoft Tier-model. Het doel van het aanbrengen van logische scheidingen is voorkomen dat kritische systemen makkelijk benaderbaar zijn vanaf minder kritische systemen. Voor het implementeren van een dergelijke mitigatie zullen enterprise-architecten, securityspecialisten en infrabeheerders heel nauw moeten samenwerken.
Regelmatige rotatie met complexe wachtwoorden
Als startpunt van een PAM-implementatie voeren wij vaak een scan uit die inzichtelijk maakt welke privileged accounts er binnen een organisatie bestaan. Deze scan kan onder andere ook vaststellen wanneer het wachtwoord van een privileged account voor het laatst gewijzigd is. Vooral bij de gevonden serviceaccounts zien we vaak dat wachtwoorden al jaren niet gewijzigd zijn. De onderliggende reden hiervan is waarschijnlijk dat het onduidelijk is hoe en waar het serviceaccount gebruikt wordt. Als het wachtwoord gewijzigd wordt en er wordt een service vergeten mee te wijzigen, kan dit betekenen dat bedrijfskritische applicaties onbereikbaar worden. Een andere onderliggende reden kan zijn dat de eigenaar van een serviceaccount niet bekend is en er dus ook niet meer actief beheerd wordt. En dit geldt ook voor de applicatie en hard-coded accounts; deze zijn ooit aangemaakt en daarna nooit meer aangepast. En in zekere zin kan dit tenslotte ook voor robotic accounts het geval zijn. Het moet de bedoeling zijn dat de maximale wachtwoordleeftijd voor een robotic account gelijk is aan die van een mens, maar vanuit het gemak kan deze restrictie opgeheven zijn.
De wachtwoorden van serviceaccounts worden op de server in zogenaamde hashes opgeslagen. Met tools zoals Mimikatz is het mogelijk om de hashes terug te vertalen naar leesbare wachtwoorden. Wanneer het wachtwoord van een serviceaccount al jaren oud is, bestaat de kans dat de complexiteit van het wachtwoord zwak is. En hoe zwakker wachtwoorden zijn, des te makkelijker het is om deze leesbaar te krijgen. Doordat er ook geen regelmatige rotatie van de wachtwoorden (en dus van de hashes) plaatsvindt, zou een aanvaller voor lange tijd onopgemerkt misbruik van het serviceaccount kunnen maken. En voor de andere typen accounts is het misschien zelfs niet nodig om deze met tools leesbaar te maken, omdat ze zijn al leesbaar opgeslagen zijn in applicaties, scripts of RPA-oplossingen. Zodra de privileged accounts onder beheer van de PAM-oplossing geplaatst zijn, dan is het mogelijk om complexe wachtwoorden automatisch te genereren op regelmatige basis. Hierdoor wordt het moeilijker deze leesbaar te krijgen met tools zoals Mimikatz. Als een aanvaller er al in slaagt om het wachtwoord te achterhalen, kan deze maar voor een beperkte tijd misbruikt worden. En voor de detectie van misbruik hebben de meeste PAM-oplossing ook threatdetectie-modules beschikbaar.
Business-accounts of domain administrators niet voor services gebruiken
Helaas zien wij ook nog regelmatig dat de zogenaamde business-accounts gebruikt worden om services te draaien. Het betreft hier dan voornamelijk geplande taken op een Windows-service om dagelijks een handeling uit te voeren, zoals het veiligstellen van logbestanden. Een business-account dat voor dagelijks gebruik is om in te loggen op een werkplek, applicatie of mail te lezen, wordt hierdoor ineens een kroonjuweel. Het gevaar van een business-account is dat deze het makkelijkst door een aanvaller buit te maken is. Simpelweg door bijvoorbeeld te klikken op een link in een phishing e-mail kan een gebruiker al zijn wachtwoord compromitteren. De aanvaller kan dan vervolgens het wachtwoord misbruiken en inloggen op de server waarop een service draait onder dat business-account. Als er andere domeinservice-accounts gebruikt worden op die server, kan de aanvaller daar de hash van pakken en zo lateraal verder bewegen.
Aan de andere kant zien we dat één van de belangrijkste soort kroonjuwelen ook gebruikt worden voor het draaien van services, de domain administrator accounts. Deze hebben privileges over de gehele infrastructuur. Als een aanvaller hiervan een hash of wachtwoord weet te bemachtigen, kan de gehele infrastructuur benaderd en bijvoorbeeld een ransomware aanval uitgevoerd worden. Een service onder een domain administrator account vergroot de kansen op een Pass-the-Hash of Golden Ticket aanval.
De organisatie moet dus actief blijven monitoren onder welke accounts services draaien en of dit accounts zijn waarop de principle of least privileges is toegepast. Een organisatie moet zich er zeer bewust van zijn dat te veel rechten op een privileged account een groot risico met zich meebrengt met ondenkbare gevolgen.
PAM als initiator voor algehele IT-securityverbeteringen
Enkel het implementeren van de PAM-oplossing is niet voldoende. Er moeten andere werkwijzen toegepast worden. Er moet strikter vastgesteld worden waarvoor een privileged account gebruikt moet worden, welke rechten er nodig zijn. Hoe hoger de rechten, hoe meer beveiligingsrisico er ontstaat. De volledige infrastructuur zal onder de loep genomen moeten worden om logische scheidingen aan te brengen binnen de infrastructuur. Wachtwoorden zullen regelmatig gewijzigd moeten worden. Een organisatie moet actief monitoren dat services niet onder persoonlijke business accounts of domain administrator accounts draaien. Het hogere doel van een organisatie moet zijn om de algehele IT-security te verbeteren waardoor aanvallers moeilijker systemen kunnen compromitteren. PAM kan de initiator van dit hogere doel zijn en het management op uw kroonjuwelen van u overnemen.