Table of Contents
Citrix hat gestern (18.07.2023) eine Warnung über eine kritische Sicherheitslücke (CVE-2023-3519) in allen NetScaler (Citrix ADC) & Gateway Systemen veröffentlicht. Bis heute sind keine funktionierenden Exploits veröffentlicht.
Wichtig ! Es gibt keine Patches für NetScaler (Citrix ADC) Version 12.1 oder älter. Diese Systeme haben ihr EOL erreicht und werden daher nicht mehr mit dem nötigen Fix bestückt. In diesem Fall bitte ein Update auf die neuste 13.0 oder 13.1 Version durchführen.
Die Sicherheitslücke ermöglichen eine anonyme Ausführung von Remotecode und dadurch nicht authentifizierten Angreifern verschiedene Maschinen mit Root Rechten zu übernehmen.
Wie man aus der Citrix Community hört, werden immer mehr attackierte Systeme aufgefunden. Die ersten Exploits sind auch schon seit einiger Zeit im Dark Web zu kaufen.
Danke an Sander Horsman von Conda Security für die weitere Einsichten und Informationen.
Assetnote hat nun durch Reverse Engineering ein Script erzeugt um offene Systeme zu erkennen. Im ersten Schritt betrifft dies erstmal nur Maschinen, wo SAML aktiviert ist.
Es ist anzunehmen das von verschiedenen Einrichtungen erstellte Listen, über NetScaler (Citrix ADC) Maschinen im Internet nun angegriffen wird.
Die ersten Exploits und Scanner sind nun auch öffentlich über GitHub erreichbar. Anbei der Output des Script von Bryan Smith (@securekomodo).
Der Output bei einem gepatchten sauberen System.
Und bei einem System das noch nicht gepatcht ist.
Firmware Updates
Citrix hat für alle unterstützen Versionen einen Patch zur Verfügung gestellt.
| NetScaler (Citrix ADC) únd NetScaler (Citrix) Gateway | ||
|---|---|---|
| Version | Refresh Build | Expected Release Date |
| 13.0 | 13.0-91.13 | Patch is here |
| 13.1 | 13.1.-49.13 | Patch is here |
Anleitung zum Updaten der Appliances findet man hier.
Überprüfung der Systeme
Selbst Systeme mit den vorhandenen Schutzmaßnahmen sollten einer eingehenden Überprüfung unterzogen werden, da man nie mit Sicherheit sagen kann, wann Angriffe begonnen haben könnten, bevor sie breit angelegt wurden.
Hier eine Zusammenfassung der Artikel, Twitter Einträge und eigener Erfahrungen bezüglich der Angriffswelle.
Zeitpunkt des letzten Update herausfinden
Einen Angriff kann man im Moment nur an überschriebenen Zeitstempeln in bestimmten Dateien erkennen. Diese Zeitstempel ändern sich normalerweise nur beim Update der NetScaler und daher ist es wichtig dieses Datum zu wissen. Ein guter Indikator hierfür ist es das Datum der entpackten Installationspakete sich anzuschauen.
Alle Befehle sollten per Putty oder CLI ausgeführt werden.
Als erstes sollte man sich natürlich mit nsroot oder einem anderen Administrativen Account anmelden. Danach kann man sich mit dem folgenden Befehl seine extrahierten Installationsdaten anschauen.
|
1 |
shell ls -ll /var/nsinstall |
Hier ersichtlich ist das Datum des letzten NetScaler Update Packets (19.07.2023). Dies sollten wir uns notieren, da wir dies für die nächsten Befehle benötigen. Wichtig ist hierbei aber, das wir nicht das ermittelte Datum eingeben in den folgenden Befehlen, sondern das ermittelte Datum in der Form YYYYMMDD +1. Also in meinem Fall 20230720.
Editierte Dateien
Nun können wir prüfen, ob seit dem letzten Update bestimmte Dateien angepasst worden sind. Dies wäre noch kein Beweis, aber ein erstes Indiz und sollte ernst genommen werden. Wenn wir angepasste Logon Seiten haben, ist hier natürlich das Datum von der letzten Editierung einzugeben.
|
1 2 3 4 |
shell find /var/vpn/ -type f -newermt {Timestamp der Installer Files +1} -exec ls -l {} \; find /var/netscaler/logon/ -type f -newermt {Timestamp der Installer Files +1} -exec ls -l {} \; find /var/python/ -type f -newermt {Timestamp der Installer Files +1} -exec ls -l {} \; |
Ein häufiger webshell den ich in der freien Wildbahn sehe, identifiziert sich durch die Datei a.php unter /var/netscaler/logon. Achtet bitte ebenfalls ob diese Datei vorhanden ist, dies ist ein Zeichen für eine erfolgte Attacke.
Die Dateien unter ns_gui ändern den Zeitstempel nicht nur beim Installieren der Dateien, sondern bei jedem Neustart. Daher sollte dies beim prüfen des Zeitstempels beachtet werden.
|
1 2 |
shell find /netscaler/ns_gui/ -type f -name *.php -newermt {Timestamp der Installer Files +1} -exec ls -l {} \; |
Oder mit dem folgenden Python Befehl.
|
1 2 |
shell python -c "import os, glob, time; newest_timestamp = max(os.stat(f).st_mtime for f in glob.glob('/var/nsinstall/*')); print('\n'.join(os.path.join(dirpath, f) for dir in ['/var/netscaler/logon/', '/var/python/', '/var/vpn/'] for dirpath, _, files in os.walk(dir) for f in files if os.stat(os.path.join(dirpath, f)).st_mtime > newest_timestamp))" |
Wenn nichts editiert wurde seit dem letzten Update ist dies ein gutes Zeichen.
Neue Dateien (webshell)
Wir überprüfen verschiedene Verzeichnisse ebenfalls auf neue Dateien, dies würde auf eine webshell hinweisen.
|
1 2 3 4 |
shell ls -ll /var/nsproflog/*.php ls -ll /var/netscaler/gui/*.php ls -ll /netscaler/portal/*.php |
HTTP error log Dateien
Es können bei Attacken auch Einträge in den http error logs erscheinen. Wir suchen hier nach Auffälligkeiten bezüglich .sh und .php.
|
1 2 3 |
zgrep '\.sh' /var/log/httperror.log* zgrep '\.php' /var/log/httperror.log* zgrep '\.pl' /var/log/httperror.log* |
Abgebildet sieht man das die Suche nach .sh erfolgreich war. Dies kann man direkt prüfen indem man einem Editor seiner Wahl (z.B. vi) in die Datei reinschaut.
In diesem Fall, habe ich in der betroffenen Datei nur .sh hinzugefügt um meinen Befehl zu prüfen.
Shell / Bash Log Dateien
Darüber hinaus hinterlassen Angriffe, Einträge in den Shell oder Bash Log Dateien.
|
1 2 |
shell zgrep -E 'database.php|/flash/nsconfig/keys/updated|/flash/nsconfig/keys|/ns_gui/vpn|LDAPTLS_REQCERT|ldapsearch|openssl|/nsconfig/ns.conf|del /etc/auth.conf|cp /usr/bin/bash|.F1.key|.F2.key|nobody' /var/log/sh.log* shell zgrep -E 'database.php|/flash/nsconfig/keys/updated|/flash/nsconfig/keys|/ns_gui/vpn|LDAPTLS_REQCERT|ldapsearch|openssl|/nsconfig/ns.conf|del /etc/auth.conf|cp /usr/bin/bash|.F1.key|.F2.key|nobody' /var/log/bash.log* |
Hier im Screenshot sind nur meine Tests zu sehen und kein Angriff.
Log Dateien
Prüfen der Log Dateien auf bekannte IOCs.
|
1 |
grep -v '127\.0\.0' /var/log/*.log | grep 'nc -l\|/etc/passwd\|/etc/shadow\|python -c\|curl\|\.php' |
Editierte Dateien mit dem setuid Bit
|
1 |
find /var -perm -4000 -user root -not -path "/var/nslog/*" -newermt {Timestamp der Installer Files +1} -exec ls -l {} \; |
Nobody Prozesse
Im Kontext des Nobody Benutzers wurden bei Angriffen auch neue Prozesse gestartet. Hier ein Beispiel für die erlaubten Prozesse.
|
1 |
shell ps aux | grep nobody | grep -v '/bin/httpd' |
Und ein attackierter Server. Die oberste Zeile ist Schadsoftware.
Crontab auf neue Einträge prüfen
Mit den folgenden Befehl können wir die aktuelle crontab Datei untersuchen. Sie sollte so aussehen wir im angezeigten Bild.
|
1 |
shell grep '' /etc/crontab |
Es sollte kein Crontab für nobody vorhanden sein. Dies kann mit dem folgenden Befehl geprüft werden.
|
1 |
shell crontab -l -u nobody |
Ich habe mehrere Community Kommentare erhalten, das die folgenden Einträge ebenfalls normal sind:
- /netscaler/adss-licexp.sh –> Bei Testlizenzen
- 0/5 * * * * root /netscaler/iprep –> Wenn IP Reputation im Einsatz ist
- */5 * * * * root /var/python/bin/python /netscaler/aslearn_health_monitor.py –> Wenn App Firewall genutzt wird
- */5 * * * * root /bin/pgrep -f /netscaler/appfw_dynamic_profiles/appfw_dynamic_profiles.py; [ $? != 0 ] && /var/python/bin/python /netscaler/appfw_dynamic_profiles/appfw_dynamic_profiles.py –> Wenn App Firewall genutzt wird
NetScaler HA Systeme
Bei verschiedenen Attacken wurde bei NetScaler HA Systemen der fürs HA zuständige Prozess (nsfsyncd) deaktiviert
|
1 |
shell ps aux | grep nsfsyncd |
Bei Standalone Maschinen sollte der Prozess auch nicht erscheinen. Abgebildet ist der Fall wie es auf einem funktionierenden System aussehen muss.
httpaccess-vpn Log Dateien
Prüfen der Log Dateien auf erfolgreiche Webzugriffe auf Unbekannte Ressourcen.
|
1 |
shell zgrep -E -v 'CitrixReceiver' /var/log/httpaccess-vpn.log* | grep ' 200 ' |
Sowie Webzugriffe von HeadlessChrome aus.
|
1 |
shell zgrep 'HeadlessChrome' /var/log/httpaccess-vpn.log* |
NPPE Core Dumps
Bei einigen Attacken wird nach einem kritischen Fehler im NetScaler über NPPE (NetScaler Packet Processing Engine) eine Core Dump erstellt. Normalerweise sollte das folgende Verzeichnis leer sein.
|
1 |
shell ls -ll /var/core/1 |
So sieht es bei einem attackierten System aus.
Perl & Python Scripte
Durch das hinzufügen von eigenen Perl oder Python Skripten kann ebenfalls ein Backdoor geöffnet werden.
|
1 2 |
shell ps -aux | grep python shell ps -aux | grep perl |
Wenn mehr als die abgebildeten grep Abfragen zu sehen sind, sollten die weiteren Skripte, durch eine Google Suche überprüft werden.
Falls etwas erscheint, führt den Befehl nach wenigen Sekunden nochmals aus. Manche Geplanten Tasks auf dem NetScaler nutzen auch python oder perl. Erst wenn es beim zweiten Aufruf immer noch läuft, sollte dies überprüft werden.
Dies sind normale Skripte für eine NetScaler Instanz die in Azure gehostet ist.
Wenn der StoreFront Monitor genutzt wird, sieht man dauerhaft das folgende Perl Script.
Crypto Miners
Ich habe mehrere NetScaler Instanzen gesehen, die nach dem Angriff als Crypto Miner genutzt worden sind.
Mit dem folgenden Befehl sieht man alle laufenden Prozesse.
Hier sollte kein weiterer Prozess, neben NSPPE-xx, dauerhaft auf 100% sein. Abgebildet ein normaler Zustand.
|
1 |
shell top -n 10 |
Netzwerk und Firewall Logs prüfen
Prüft die Netzwerk und Firewall Logs auf folgende Geschehnisse:
- Vom NetScaler gesendete Scans der Subnetze der Protokolle HTTP / HTTPS / SMB (Port 80 / 443 / 445)
- Spitzen in den Abfragen vom NetScaler bezüglich der Protokolle LDAP / LDAPS / DNS / AD (Port 389 / 636 / 53 / 88 / 135 / 137-138 / 464 / 3268-3269)
Gegenmaßnahmen bei betroffenen Systemen
Meine Empfehlung bezüglich der Maßnahmen, wenn das System korrumpiert wurde.
- Nehmt die NetScaler Instanz vom Netzwerk
- Ändert das Kennwort aller auf dem NetScaler gespeicherten LDAP oder anderen AD / Netzwerkkonten
- Stellt ein neues SSL-Zertifikat und eine neue Key Datei für alle Client SSL-Dateien auf dem Gerät aus (Die Schlüssel sind in Dateien auf dem NetScaler gespeichert, die theoretisch vom Angreifer ausgelesen werden könnten)
- Wenn es eine VPX Appliance ist und Snapshots des Geräts (älter als 3 Monate) vorhanden sind, kann es sich lohnen, diese zuerst wiederherzustellen, aber dies ist KEINE GARANTIE für die Sicherheit
- Um ganz sicher zu gehen, die Konfigurationsdatei des betroffenen Systems exportieren und in eine neue frische VPX Appliance kopieren / wiederherzustellen
- Beachtet hierbei das die gleiche Hardware-Adresse genutzt wird, sonst ist die Lizenz ungültig und muss neu angefordert / eingespielt werden
- Trennt das Netzwerk vor dem Start
- Startet die Appliance und überprüft über die Konsole, dass der VPX nicht kompromittiert ist
- Ändert das nsroot-Passwort
- Nur das interne Netzwerk anschließen
- Das externe Netzwerk anschließen
- Behaltet die Protokolle und die Responder Hits im Auge
- Ersetzt die SSL Zertifikate auf der Appliance zum frühestmöglichen Zeitpunkt
- Widerruft die kompromittierten SSL Zertifikate und SSL Keys
