Archive for month: January, 2020

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