Table of Contents
Kritische Schwachstellen in NetScaler ADC und NetScaler Gateway erfordern ein strukturiertes Vorgehen: Betroffenheit bewerten, eine sichere Zielversion auswählen, Systeme aktualisieren und anschließend prüfen, ob Hinweise auf eine Kompromittierung vorliegen.
Diese Checkliste bündelt die wichtigsten Schritte für neue NetScaler-CVEs. Maßgeblich bleiben immer das aktuelle Security Bulletin des Herstellers, die unterstützten Firmwarestände und die Besonderheiten der eigenen Umgebung.
CVE bewerten und Update vorbereiten
- Security Bulletin prüfen und betroffene Produktversionen identifizieren.
- Aktuellen Build, HA-Status, Partitionen und eingesetzte Funktionen dokumentieren.
- Unterstützte Zielversion sowie bekannte Probleme und Upgrade-Pfade prüfen.
- Konfiguration und Systemdateien sichern und einen belastbaren Rollback-Plan festlegen.
- Von Citrix veröffentlichte Workarounds bis zum Update umsetzen und dokumentieren.
Firmware aktualisieren
Aktualisieren Sie alle betroffenen NetScaler-Systeme auf ein von Citrix freigegebenen Build. Bei HA-Paaren sollte das Update kontrolliert und unter Beachtung von Synchronisation, Failover und Erreichbarkeit der veröffentlichten Dienste erfolgen. Veraltete oder nicht mehr unterstützte Versionen müssen auf einen unterstützten Release-Zweig migriert werden.
Ein Firmware-Update allein beweist nicht, dass das System vor der Aktualisierung unberührt war. Bei kritischen Schwachstellen gehört deshalb eine anschließende Sicherheitsprüfung zum Ablauf.
Ü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.
Sichern Sie bei einem konkreten Verdacht vor Neustart, Update oder Bereinigung mindestens einen VPX-Snapshot beziehungsweise ein forensisches Abbild, Systemzeit, Zeitzone und NTP-Konfiguration, ein Technical Support Bundle sowie lokale und zentrale Protokolle. Je nach Vorfall kann zusätzlich ein NSPPE-Core-Dump sinnvoll sein. Citrix beschreibt den Ablauf in CTX694799.
Ein einzelner Treffer ist nicht automatisch ein Beweis für einen erfolgreichen Angriff. Umgekehrt schließt ein unauffälliger Befund eine Kompromittierung nicht aus, da Protokolle rotieren und Angreifer Spuren verändern können. Bewerten Sie Auffälligkeiten deshalb immer im zeitlichen und technischen Kontext des jeweiligen Security Bulletins.
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)
Prüfen Sie zusätzlich auf unbekannte PHP-, Perl-, Python-, JavaScript- oder ELF-Dateien in /var/vpn/, /var/netscaler/logon/, /var/python/, /netscaler/ns_gui/, /tmp/ und /var/tmp/.
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
Auffällig sind unerwartete erfolgreiche Aufrufe unbekannter Ressourcen, ungewöhnliche POST-Anfragen, für den Zeitraum untypische User-Agents sowie Abstürze oder Core Dumps nahe dem vermuteten Angriffszeitpunkt.
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
Achten Sie außerdem auf Protokolllücken, ungewöhnlich frühe Logrotation sowie Zeitstempel, die nicht zu Systemzeit, Zeitzone, NTP-Konfiguration oder dem übrigen Ereignisverlauf passen.
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
Kopierte Shells, neue setuid-Dateien sowie ungewöhnliche Eigentümer und Berechtigungen sind besonders kritisch und müssen nachvollziehbar gegen den bekannten Sollzustand geprüft werden.
|
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
Kontrollieren Sie neben den Crontabs auch /flash/nsconfig/rc.netscaler und /etc/monitrc. Verdächtig sind insbesondere Befehle, die Webshells nach einem Neustart erneut anlegen, das setuid-Bit setzen oder überwachte Prozesse ausblenden beziehungsweise beenden.
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
Unerklärliche HA-Synchronisationsfehler sowie gestoppte oder veränderte Monitor- und Synchronisationsprozesse können ebenfalls auf Manipulationen hinweisen.
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 Sie zusätzlich Gateway- und AAA-Sitzungen auf wechselnde Quell-IP-Adressen, Länder oder User-Agents innerhalb derselben Sitzung sowie auf Sitzungen, die trotz Kennwortänderung oder MFA-Maßnahmen weiterverwendet werden.
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
Suchen Sie in Core Dumps und angrenzenden Artefakten nach Hinweisen, dass ns.conf, .F1.key, .F2.key, Zertifikate oder private Schlüssel in Web-, Theme-, Template- oder temporäre Verzeichnisse kopiert wurden.
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
Untersuchen Sie ungewöhnlichen Verkehr von der NSIP: interne Scans auf 80, 443 oder 445, starke DNS- oder LDAP/LDAPS-Aktivität, RDP- und Netzwerk-Logons, viele Verbindungen von einer Quelladresse sowie größere ausgehende Datenübertragungen. Beziehen Sie AD-Ereignisse 4624 und 4625 sowie auffällige Kerberos- und LDAP-Abfragen ein.
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
- Ersetzt die SSL Zertifikate auf der Appliance zum frühestmöglichen Zeitpunkt
- Widerruft die kompromittierten SSL Zertifikate und SSL Keys
NetScaler-Sicherheit professionell prüfen lassen
Benötigen Sie Unterstützung bei Firmware-Updates, der Bewertung kritischer Schwachstellen oder der Prüfung auf Hinweise zu Sicherheitsvorfällen? Deyda Consulting begleitet Sie mit der NetScaler Security Readiness – strukturiert, nachvollziehbar und praxisnah.