Just Enough Administration

PowerShell ist eines der mächtigsten Tools auf Geräten mit Microsoft Betriebssystem. Aufgrund verschiedener administrativer Funktionen ist die PowerShell aber auch nicht mehr wegzudenken. Ein bei Premium Audits oft angetroffes Szenario ist, dass die PowerShell ohne Einschränkungen auch für normale Benutzer zur Verfügung steht. Aus Sicht der IT-Sicherheit ist dies zu vermeiden.

Mittels PowerShell kann beispielsweise auch eine Rückverbindung zu einem Command & Control Server bzw. zum Rechner eines Angreifers hergestellt werden.

Windows Sicht:

Angreifer Sicht:

Dieses Beispiel lässt bei den meisten Windows Administratoren die Alarmglocken läuten. Der einfachste Weg dies zu verhindern? PowerShell & cmd auf Clients sperren. Dies bringt aber den Nachteil, dass alle die administrativen Vorteile wie Logon Scripts, welche im User-Kontext ausgeführt werden oder andere Scripts, nicht mehr funktionieren. Wie also kann der Zugriff auf die PowerShell so eingeschränkt werden, dass normale User nur noch die nötigen Commands ausführen können und nicht mehr Zugriff auf alle verfügbaren Befehle haben?

Microsoft selber liefert da eins zurzeit noch eher unbekannten und kaum verbreiteten Tools namens JEA (Just Enough Administration). Mit Hilfe diese Tools kann bis auf User Ebene die PowerShell eingeschränkt werden.

Dass JEA optimal funktionieren kann muss aber folgendes Patchlevel bei Servern und Clients vorhanden sein.

Server
Mindestens Windows Server 2012 mit WMF (Windows Management Framework) 5.1
Client
Windows 10 ab Version 1607 mit WMF (Windows Management Framework) 5.1

Falls sie unsicher sind, welche PowerShell Version auf Ihren Servern bzw Clients installiert ist, können Sie dies mit folgendem Befehl überprüfen:

$PSVersionTable.PSVersion

Wenn Ihr Netzwerk diese Anforderungen erfüllt steht der Einführung von JEA nichts mehr im Wege. Nachfolgendes Tutorial zeigt auf, wie eine einfach Einschränkung auf eine gewisse Usergruppe in einem Active Directory Netzwerk realisiert werden kann.

Falls das PowerShell Remoting auf Ihren Systemen nicht aktiviert ist, kann dieses mittels folgendem Befehl aktiviert bzw. reaktiviert werden. Auf aktuellen Systemen dieses Feature aber standardmässig aktiviert.

Enable-PSRemoting

JEA verwendet zur Kontrolle der Berechtigungen zwei verschiedene Dateien. Im sogenannten RoleCapability File wird definiert was das dem zukünftigen JEA Nutzer erlaubt wird. Im Session Configuration File hingegen wird definiert, wer Die JEA Konfiguration bzw. Rollen verwenden darf. Beide dieser Files werden schlussendlich lokal auf den entsprechenden Computern bzw. Servern abgelegt. Die Verteilung in grossen Netzwerken mit entsprechend vielen Hosts kann mittels Gruppenrichtlinien realisiert werden.

Nun werde ich etwas genauer auf den Inhalt des RoleCapability File eingehen und welche Konfigurationsmöglichkeiten zur Verfügung stehen. Ich werde nicht alle Teile des Files erläutern, da die Beschreibungen für sich sprechen. Folgend sehen Sie ein „leeres“ RoleCapability File.

# ID zur eindeutigen Kennzeichnung dieses Dokuments
GUID = 'be7fe637-4fdf-4656-9826-07bf4b475a54'

# Autor dieses Dokuments
Author = 'Administrator'

# Beschreibung der von diesen Einstellungen bereitgestellten Funktionen
# Description = ''

# Company associated with this document
CompanyName = 'Unbekannt'

# Urheberrechtserklärung für dieses Dokument
Copyright = '(c) 2018 Administrator. Alle Rechte vorbehalten.'

# Module, die importiert werden sollen, wenn sie auf eine Sitzung angewendet werden.
# ModulesToImport = 'MyCustomModule', @{ ModuleName = 'MyCustomModule'; ModuleVersion = '1.0.0.0'; GUID = '4d30d5f0-cb16-4898-812d-f20a6c596bdf' }

# Aliase, die sichtbar gemacht werden sollen, wenn sie auf eine Sitzung angewendet werden.
# VisibleAliases = 'Item1', 'Item2'

# Cmdlets, die sichtbar gemacht werden sollen, wenn sie auf eine Sitzung angewendet werden.
# VisibleCmdlets = 'Invoke-Cmdlet1', @{ Name = 'Invoke-Cmdlet2'; Parameters = @{ Name = 'Parameter1'; ValidateSet = 'Item1', 'Item2' }, @{ Name = 'Parameter2'; ValidatePattern = 'L*' } }

# Funktionen, die sichtbar gemacht werden sollen, wenn sie auf eine Sitzung angewendet werden.
# VisibleFunctions = 'Invoke-Function1', @{ Name = 'Invoke-Function2'; Parameters = @{ Name = 'Parameter1'; ValidateSet = 'Item1', 'Item2' }, @{ Name = 'Parameter2'; ValidatePattern = 'L*' } }

# Externe Befehle (Skripts und Anwendungen), die sichtbar gemacht werden sollen, wenn Sie auf eine Sitzung angewendet werden.
# VisibleExternalCommands = 'Item1', 'Item2'

# Anbieter, die sichtbar gemacht werden sollen, wenn sie auf eine Sitzung angewendet werden.
# VisibleProviders = 'Item1', 'Item2'

# Skripts, die ausgeführt werden sollen, wenn sie auf eine Sitzung angewendet werden.
# ScriptsToProcess = 'C:\ConfigData\InitScript1.ps1', 'C:\ConfigData\InitScript2.ps1'

# Aliase, die definiert werden sollen, wenn sie auf eine Sitzung angewendet werden.
# AliasDefinitions = @{ Name = 'Alias1'; Value = 'Invoke-Alias1'}, @{ Name = 'Alias2'; Value = 'Invoke-Alias2'}

# Funktionen, die definiert werden sollen, wenn sie auf eine Sitzung angewendet werden.
# FunctionDefinitions = @{ Name = 'MyFunction'; ScriptBlock = { param($MyInput) $MyInput } }

# Variablen, die definiert werden sollen, wenn sie auf eine Sitzung angewendet werden.
# VariableDefinitions = @{ Name = 'Variable1'; Value = { 'Dynamic' + 'InitialValue' } }, @{ Name = 'Variable2'; Value = 'StaticInitialValue' }

# Umgebungsvariablen, die definiert werden sollen, wenn sie auf eine Sitzung angewendet werden.
# EnvironmentVariables = @{ Variable1 = 'Value1'; Variable2 = 'Value2' }

# Typdateien (PS1XML), die geladen werden sollen, wenn sie auf eine Sitzung angewendet werden.
# TypesToProcess = 'C:\ConfigData\MyTypes.ps1xml', 'C:\ConfigData\OtherTypes.ps1xml'

# Formatdateien (PS1XML), die geladen werden sollen, wenn sie auf eine Sitzung angewendet werden.
# FormatsToProcess = 'C:\ConfigData\MyFormats.ps1xml', 'C:\ConfigData\OtherFormats.ps1xml'

# Assemblys, die geladen werden sollen, wenn sie auf eine Sitzung angewendet werden.
# AssembliesToLoad = 'System.Web', 'System.OtherAssembly, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'

}

Für uns sind in diesem Blog bzw. zur ersten Einrichtung von JEA nur folgende Abschnitte wichtig:

VisibleCmdlets
VisibleFunctions
VisibleExternalCommands

Im Bereich VisibleCmdlets werden alle Cmdlets erfasst, welche der Nutzer der JEA Session später zur Verfügung haben soll. Standardmässig hat der Nutzer folgende Grund-Cmdlets zur Verfügung:

Clear-Host
Exit-PSSession
Get-Command
Get-FormatData
Get-Help
Measure-Object
Out-Default
Select-Object

Alle weiteren Cmdlets müssen im Bereich VisibleCmdlets definiert werden. Hier können zum einen Cmdlets generell erlaubt oder mittels Variablendefinition teils erlaubt werden.

Um Cmdlets generell zu erlauben muss dieses wie folgt definiert werden:

VisibleCmdlets = 'Cmdlet', 'Cmdlet2'

Wie oben erwähnt, können die Variablen eingeschränkt werden. Dies ist nützlich, falls der betroffene User beispielsweise nur einen gewissen Dienst neustarten darf. Im Falle eines DHCP Servers würde dies wie folgt aussehen:

VisibleCmdlets = @{ Name = 'Restart-Service'; Parameters = @{ Name = 'Name'; ValidateSet = 'DHCP'}}

VisibleFunctions verhält sich gleich wie VisibleCmdlets, nur, dass hier die Funktionen definiert werden. Ob es sich beim gewünschten Befehl um eine Funktion oder ein Cmdlet handelt, kann mittels Get-Command herausgefunden werden:

Get-Command 'Befehl'

Unter CommandType ist nun ersichtlich, ob es sich um ein Cmdlet oder eine Funktion handelt.

Unter VisibleExternalCommands kann dem User das Ausführen von speziefischen externen Programmen oder Powershell Scripts erlaubt werden.

VisibleExternalCommands = 'C:\Windows\System32\whoami.exe', 'C:\Program Files\Scripts\Logon.ps1'

Um nun mit kleinem Aufwand ein solches Role Capatibility File erstellen muss folgendes gemacht werden.

Noch vor dem Erstellen des Role Capability Files muss die entsprechende Filestruktur inklusive Module Manifest angelegt werden:

New-Item -Path "C:\Program Files\WindowsPowerShell\Modules\DHCP_Module" -ItemType Directory

New-ModuleManifest -Path "C:\Program Files\WindowsPowerShell\Modules\DHCP_Module\DHCP_Module.psd1"
New-Item -Path "C:\Program Files\WindowsPowerShell\Modules\DHCP_Module\RoleCapabilities" -ItemType Directory

Nun wollen wir einem User erlauben den Befehl, welcher benötigt wird, um den DHCP Service neu zu starten, ausführen zu können. Als erstes werden aber die Parameter definiert, welche abgefüllt werden sollen:

$DHCPRoleCapabilityParams = @{
Author = 'goSecurity Tutorial'
Description = 'DHCP Service Administration'
CompanyName = 'goSecurity Tutorial'
VisibleCmdlets = @{Name = 'Restart-Service'; Parameters = @{ Name = 'Name'; ValidateSet = 'DHCPServer'}}}

New-PSRoleCapabilityFile -Path "$ENV:ProgramFiles\WindowsPowerShell\Modules\DHCP_Module\RoleCapabilities\DHCPRoleCapability.psrc" @DHCPRoleCapabilityParams

Mittels PSEdit kann das File nun begutachtet werden. Falls alles geklappt hat, sollte dieses wie folgt aussehen (ACHTUNG: psedit funktioniert nur im Powershell ISE)

psedit "$ENV:ProgramFiles\WindowsPowerShell\Modules\Demo_Module\RoleCapabilities\DHCPRoleCapability.psrc

# ID zur eindeutigen Kennzeichnung dieses Dokuments
GUID = '1f7c4406-cd4a-49c8-952a-a713ceb500a2'

# Autor dieses Dokuments
Author = 'goSecurity Tutorial'

# Beschreibung der von diesen Einstellungen bereitgestellten Funktionen
Description = 'DHCP Service Administration'

# Company associated with this document
CompanyName = 'goSecurity Tutorial'

# Urheberrechtserklärung für dieses Dokument
Copyright = '(c) 2018 goSecurity Tutorial. Alle Rechte vorbehalten.'

# Aliase, die sichtbar gemacht werden sollen, wenn sie auf eine Sitzung angewendet werden.
# VisibleAliases = 'Item1', 'Item2'

# Cmdlets, die sichtbar gemacht werden sollen, wenn sie auf eine Sitzung angewendet werden.
VisibleCmdlets = @{
'Name' = 'Restart-Service'
'Parameters' = @{
'Name' = 'Name'
'ValidateSet' = 'DHCPServer' } }