“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.

Delen via: Facebooktwitterpinterestlinkedinmail

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

Delen via: Facebooktwitterpinterestlinkedinmail

Windows Server 2016 HP Server OEM bios lock

Recently I build a Hewlett Packard Enterpise (HPE) server for a customer . With the HP Proliant G9 server we ordered the HPE branded Server 2016 installation media. We wanted to virtualize the OS but when we booted the installation media the error “Failed BIOS Lock: This installation media may be used only on hardware manufactured by: Hewlett Packard Enterprise.” came up and the sytem rebooted.

To work-around this popup we need to simulate the host BIOS to the virtual machine. This can be done by adding the following line to the virtual machine VDMX file.

smbios.addHostVendor = “TRUE”

This can also be done in the GUI, in the advanced options of the virtual machine. See the screenshots below for the required setting.

After setting the option the virtual Windows Server 2016 installed succesfully.Delen via: Facebooktwitterpinterestlinkedinmail

Microsoft App-V error ‘You do not have access to this information’ after installation

Recently after a fresh install of an App-V 5.1 environment I ran into an error managing the applications. When I browsed to the freshly installed App-V 5.1 management server I got the error ‘You do not have access to this information. Please Check your credentials‘. Even when the user / group was added to the App-V admin group.

AppVAdminError

After some research i discovered this was caused by the fact that the App-V management servers where not added to the App-V admin group. After adding the Active Directory computers accounts to the App-V management group the connection was working.

AppVgroupDelen via: Facebooktwitterpinterestlinkedinmail