CyberArk PasswordVault “Error: (winRc=5) Access Denied”

Indien je via de CyberArk PasswordVault een lokaal administrator wachtwoord probeert te wijzigen op een Windows Server 2016 of 2019 server kan het voorkomen dat je onderstaande foutmelding krijgt.

"Error: (winRc=5) Access Denied"

Indien je tegen deze foutmelding aanloopt dienen er vier instellingen gecontroleerd te worden.

Controleer of gebruiker eigen wachtwoord kan wijzigen

De gebruiker waarvan het wachtwoord moet worden gewijzigd moet zelf de rechten hebben om dit te kunnen doen. De instelling “User cannot change password” moet uit staan.

Controleer de firewall configuratie

Tussen de Central Policy Manager (CPM) en het systeem moeten poort 135 en poort 445 open staan. Zorg dat deze zowel op tussenliggende firewalls als op de Windows Firewall op het lokale systeem open staan.

Controleer de Group Policy Settings

De actie die de CyberArk Passwordvault uitvoert vereist het dat de instelling “Disable the User Access Control (UAC) Run all administrators in Admin Mode” op disabled staat. Indien de machine in het domein zit kan dit centraal in een Group policy geplaatst worden. Indien dit niet mogelijk is dient dient in de lokale Group Policy Manger aangepast te worden.

"Local Security Policy > Local Policies > Security Options > Disable the User Access Control (UAC) Run all administrators in Admin Mode"

Controleer of de IPC$ share benaderbaar is

Controleer of je vanaf de CPM server de IPC$ share van de server kunt benaderen met de huidige werkende gegevens van het account wat je gemanaged wilt hebben. Indien dit niet het geval is, en je een foutmelding over rechten krijgt, dien je de instelling “LocalAccountTokenFilterPolicy” toe te voegen in het register van de server waarop je het wachtwoord wilt wijzen. De server heeft na deze aanpassing een herstart nodig.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System

Waarde: LocalAccountTokenFilterPolicy

Data: 1 (om uit te schakelen, 0 schakelt filtering in)

Activeren 2FA in Azure AD via Powershell

 Indien je met de basis variant van Azure AD werkt heb je niet de mogelijkheid om een aparte beleidsregel aan te maken waarin je kunt aangeven dat gebruikers 2FA vereisen. Hiervoor moeten alle gebruikers handmatig aangepast worden via een (onhandige) interface. Gelukkig kunnen de aanpassingen ook via PowerShell op groepen gebruikers uitgevoerd worden.

Connect naar de Azure tenant

Connect-MsolService

Bekijk hoe de authenticatie methoden nu ingesteld staan

Get-MsolUser -all | Where-Object {$_.StrongAuthenticationMethods -like "*"}  | select UserPrincipalName,StrongAuthenticationMethods,StrongAuthenticationRequirements

Inschakelen van 2FA

Om 2FA in te schakelen moet eerst de “StrongAuthenticationRequirement” ingeschakeld worden.

$mf= New-Object -TypeName Microsoft.Online.Administration.StrongAuthenticationRequirement
$mf.RelyingParty = "*"
$mfa = @($mf)

Schakel 2FA voor een enkele gebruiker in

Set-MsolUser -UserPrincipalName "username" -StrongAuthenticationRequirements $mfa

Schakel 2FA voor alle gebruikers in

Get-MsolUser -All | Set-MsolUser -StrongAuthenticationRequirements $mfa

Schakel 2FA voor een enkele gebruiker uit

$mfa = @()
Set-MsolUser -UserPrincipalName eshlomo@elishlomo.us -StrongAuthenticationRequirements $mfa 

“An internal error has occurred” RDP connectie server 2016 (Error 10013)

Indien er bij het verbinden van een RDP sessie naar een Windows Server 2016 server de melding komt “An internal error has occurred” is er zeer waarschijnlijk een probleem ontstaan met het RDP certificaat.

Bij het verbinden van een sessie verschijnen onderstaande meldingen in de eventviewer van de betreffende server.

Event 1057 – RD Session Host Server has failed to create a new self signed certificate to be used for RD Session Host Server authentication on SSL connections. The relevant status code was Object already exists.

Event 36871 – A fatal error occurred while creating a TLS client credential. The internal error state is 10013.

De oplossing/workaround hiervoor is het verwijderen van onderstaande key. Bij de eerstvolgende RDP connectie wordt er een nieuw certificaat gegenereerd.

Na connecten zal er weer een certificaat staan. De verbinding werkt weer naar behoren.

Controles op aanvallen voor Citrix NetScaler CVE-2019-19781

Op 17 december 2019 is er door Citrix een aangekondigd dat in de Citrix NetScaler een ernstig beveiligingslek is. Door middel van dit lek kan er op de NetScaler code (Remote Code Execution) uitgevoerd worden.

Simpel uitgelegd gaat het om het volgende: om een aanval uit te voeren wordt er gebruik gemaakt van een zogenaamd “path traversal”. Hiermee zijn er bestanden toegankelijk die niet toegankelijk zouden moeten zijn. In deze bestanden kan code toegevoegd worden waarna de NetScaler deze uitvoert. In het ergste geval kan hiermee de NetScaler overgenomen worden.

Citrix heeft op 17 december een mitigerende maatregel aangedragen. Deze is in de vorm van een “responder policy” op de NetScaler. Mocht er een poging gedaan worden tot de “path traversal” dan geeft de NetScaler een HTTP error 403 terug en kan de aanval niet succesvol uitgevoerd worden. Deze responder policy kan toegevoegd worden via de volgende URL: https://support.citrix.com/article/CTX267679

Mochten er nieuwe mogelijkheden komen om het lek te misbruiken dan kan het zo zijn dat de “responder policy” dit niet blokkeert. Om extra te checken of er aanvallers binnen zijn is het verstandig om regelmatig extra controles uit te voeren op de NetScaler. Deze controles kunnen uitgevoerd worden door met SSH te connecten naar de NetScaler en in de “shell” mode onderstaande commando’s uit te voeren.

Deze controles bieden uiteraard geen 100% zekerheid maar bieden wel een stukje extra inzage.

Controle 1 – Wijzigingen in Templates

Zoek op de NetScaler naar bestanden in de template map. Alle files die vanaf 01-01-2020 zijn gewijzigd (tenzij je zelf een template hebt gewijzigd) zijn verdacht.

find /netscaler/portal/templates -newermt “2020-01-01”

Controle 2 – Wijzigingen in /netscaler

Zoek voor de zekerheid ook in de volledige /netscaler (config) map of hier in de afgelopen weken wijzingen hebben plaatsgevonden.

find /netscaler -newermt “2020-01-01” -type f -print0 | xargs -0 /bin/ls –ltr

Controle 3 – Scripts MD5 hash

Controleer of de .pl (Perl) scripts die gebruikt/aangepast kunnen worden bij het lek nog hetzelfde zijn als bij het initiële bouwen van de NetScaler.

md5 /netscaler/portal/scripts/*

Controleer vervolgens je hashes met onderstaande hashes. Deze zijn origineel van een schone NetScaler.

Controle 4 – Bash.log

Controleer of er geen commando’s met de gebruiker “nobody” zijn uitgevoerd (hier kan een aanvaller onder werken). Dit geldt alleen als er nog geen “privilege escalation” heeft plaatsgevonden.

cat /var/log/bash.log | grep ‘nobody’

gzcat /var/log/bash.*.gz | grep nobody

Controle 5 – HTTPaccess.log

Controleer de http logs of er aanvallen zijn geweest met HTTP status code 200. Deze zijn doorgelaten door de responder policy en hebben mogelijk aanpassingen aan de NetScaler gedaan.

shell cat /var/log/httpaccess.log | grep vpns | grep xml

shell cat /var/log/httpaccess.log | grep “/\.\./”

shell gzcat /var/log/httpaccess.log.*.gz | grep vpns | grep xml

shell gzcat /var/log/httpaccess.log.*.gz | grep “/\.\./”

Controle 6 – Crontab

Controleer of er geen crontab (repeterende taken) zijn aangemaakt onder de gebruiker “nobody” of een andere gebruiker. Onderstaande een screenshot van een standaard schone NetScaler.

cat /etc/crontab

crontab -l -u nobody

Controle 7 – Perl / Python

Controleer of er geen “Perl” of “Python” processen draaien die niet standaard zijn. De NetScaler voert intern regelmatig ook diverse scripts uit dus een extra script is niet direct verdacht. Mocht hij aanwezig blijven is onderzoek gewenst.

ps -aux | grep perl

Controle 8 – Cryptominers

Controleer of er geen cryptominers zijn geïnstalleerd. Dit kan eenvoudig gedaan worden door te controleren of er geen script/proces is wat constant 100% CPU vraagt.

top -n 10