Table of Contents
Am 17. Juni 2025 veröffentlichte Citrix eine Sicherheitsmeldung zu CVE-2025-5777, gefolgt von CVE-2025-6543 am 25. Juni 2025. Beide Schwachstellen gelten als kritisch und werden aktiv ausgenutzt..
Die Bedrohungslage
- CVE-2025-5777: Kritische Schwachstelle durch unzureichende Eingabevalidierung → führt zu Memory Overread
- CVE-2025-6543: Ermöglicht Memory Overflow, was zu DoS oder Codeausführung führen kann → Exploits vorhanden !
⚠️ Wichtig: Ein Update allein reicht nicht aus. Alle aktiven ICA- und PCoIP-Sitzungen müssen manuell beendet werden, um die Sicherheitslücke vollständig zu schließen.
Unterstützte Builds & Upgrades
Für ältere NetScaler-Versionen 12.1, 13.0 und alle älteren Builds existieren keine Patches mehr – diese Versionen sind End-of-Life (EOL).
Ein Upgrade auf 13.1 oder 14.1 ist zwingend erforderlich.
| NetScaler (Citrix ADC) und NetScaler (Citrix) Gateway | ||
|---|---|---|
| Version | Refresh Build | Expected Release Date |
| 13.1 | 13.1.-59.19 | Patch is here |
| 14.1 | 14.1.-43.56 | Patch is here |
Anleitung zur Aktualisierung der Appliances:
Nach dem Update: Aktive Sitzungen beenden (CVE-2025-5777)
|
1 2 |
kill icaconnection -all kill pcoipConnection -all |
Diese Befehle beenden alle Sessions, die vor dem Update aktiv waren – und somit potenziell weiterhin angreifbar sind.
Forensische Analyse: Wurde Ihr System kompromittiert?
Auch wenn (noch) keine Angriffszeichen sichtbar sind, empfehlen wir eine umfassende Analyse. Nachfolgend finden Sie 19 Prüfbereiche mit Erläuterungen und Befehlen.
1. Letztes Update-Datum bestimmen
|
1 |
ls -ll /var/nsinstall |
Zeitstempel der zuletzt extrahierten Firmware-Dateien. Merkt euch dieses Datum +1 Tag für alle folgenden Prüfungen (z. B. 20230720).
2. Geänderte Dateien seit Update
|
1 2 3 |
find /var/vpn/ -type f -newermt YYYYMMDD -exec ls -l {} \; find /var/netscaler/logon/ -type f -newermt YYYYMMDD -exec ls -l {} \; find /var/python/ -type f -newermt YYYYMMDD -exec ls -l {} \; |
Auffällige Änderungen (z. B. neue PHP-Dateien) deuten auf Manipulationen hin.
3. Bekannte Webshells prüfen
|
1 |
ls -ll /var/netscaler/logon/a.php |
Diese Datei ist eine bekannte Webshell und definitiv ein Indikator für Kompromittierung.
4. GUI-Dateien (vorsichtig) prüfen
|
1 |
find /netscaler/ns_gui/ -type f -name "*.php" -newermt YYYYMMDD -exec ls -l {} \; |
Timestamps ändern sich auch bei Reboots – keine alleinige Aussagekraft.
5. Automatisierte Analyse per Python
|
1 |
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))" |
Dieses Skript listet alle Dateien auf, die nach dem letzten Update verändert wurden – ideal für eine schnelle Übersicht.
6. Neue verdächtige PHP-Dateien
|
1 2 3 |
ls -ll /var/nsproflog/*.php ls -ll /var/netscaler/gui/*.php ls -ll /netscaler/portal/*.php |
Neue PHP-Dateien an diesen Speicherorten sind fast immer ungewollt und könnten z. B. Backdoors sein.
7. HTTP-Fehlerlogs prüfen
|
1 2 3 |
zgrep '.sh' /var/log/httperror.log* zgrep '.php' /var/log/httperror.log* zgrep '.pl' /var/log/httperror.log* |
Sucht nach Einträgen, die auf Skriptaufrufe hindeuten, insbesondere .php, .sh oder .pl. Diese können Angriffe dokumentieren.
Abgebildet sieht man das die Suche nach .sh erfolgreich war. Dies kann man direkt prüfen indem man mit einem Editor seiner Wahl (z.B. vi) in die Datei reinschaut.
8. Shell- und Bash-Logs
|
1 2 |
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* 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* |
Diese Logs speichern direkte Shell-Kommandos, die von Angreifern ausgeführt wurden. Besonders gefährlich sind Zugriffe auf Schlüsseldateien oder der Einsatz von openssl.
9. „nobody“-Prozesse prüfen
|
1 |
ps aux | grep nobody | grep -v '/bin/httpd' |
Der Benutzer „nobody“ sollte nur vom internen Webserver verwendet werden. Weitere Prozesse sind verdächtig.
Hier ein Beispiel für die erlaubten Prozesse.
Und ein angegriffener Server. Die oberste Zeile ist Schadsoftware.
10. Crontab auf ungewollte Aufgaben prüfen
|
1 2 |
grep '' /etc/crontab crontab -l -u nobody |
Crontabs, die auf ungewöhnliche Skripte oder den User „nobody“ verweisen, sind verdächtig.
Ausnahmen (AppFW, IPReputation, Trial Licensing) sind dokumentiert.
Es sollte kein Crontab für nobody vorhanden sein.
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
11. HTTP-Zugriffe analysieren
|
1 2 |
zgrep -E -v 'CitrixReceiver' /var/log/httpaccess-vpn.log* | grep ' 200 ' zgrep 'HeadlessChrome' /var/log/httpaccess-vpn.log* |
Zugriffe mit 200er-Statuscodes auf unbekannte Ressourcen oder von Bots wie „HeadlessChrome“ sollten überprüft werden.
12. Core Dumps prüfen
|
1 |
ls -ll /var/core/1 |
Ein voller Dump-Ordner ist ein Hinweis auf einen Absturz durch Speicherüberlauf – ein mögliches Zeichen für CVE-Ausnutzung.
So sieht es bei einem angegriffenen System aus.
13. Perl/Python-Prozesse
|
1 2 |
ps -aux | grep python ps -aux | grep perl |
Laufende, unbekannte Skripte können Backdoors oder Miner sein. Zweimal prüfen!
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.
14. CPU-Auslastung prüfen – Crypto Mining?
|
1 |
top -n 10 |
NetScaler-Prozesse wie NSPPE-xx dürfen CPU nutzen – alles andere (z. B. xmrig) deutet auf Mining-Malware hin.
15. Netzwerk- und Firewall-Logs
- Ungewöhnlich viele Verbindungen auf Ports 80, 443, 445
- Spikes bei LDAP/DNS/AD (389/53/88/135/464/3268)
Deutet auf laterale Bewegungen hin (Post-Exploitation).
16. Logdateien auf Indicators of Compromise (IOCs) prüfen
|
1 |
grep -v '127.0.0' /var/log/*.log | grep 'nc -l|/etc/passwd|/etc/shadow|python -c|curl|.php' |
Ein schneller IOC-Check über sämtliche Logdateien gibt oft Hinweise auf versuchte oder erfolgreiche Kompromittierung.
Diese Abfrage filtert lokale IPs heraus und konzentriert sich auf verdächtige Kommandos in Logdateien.
17. Geänderte Dateien mit gesetztem setuid-Bit
|
1 |
find /var -perm -4000 -user root -not -path "/var/nslog/*" -newermt {Timestamp der Installer Files +1} -exec ls -l {} ; |
Jede Datei mit setuid außerhalb der Standardverzeichnisse wie /bin, /usr/bin oder /sbin ist hochgradig verdächtig – insbesondere in /var.
18. NetScaler HA-Systeme – Prüfung des HA-Prozesses nsfsyncd
|
1 |
ps aux | grep nsfsyncd |
Wenn nsfsyncd auf einem HA-System fehlt, wird auch kein Failover mehr durchgeführt – Angreifer können gezielt verhindern, dass ein sauberes Failover auf das nicht-kompromittierte System stattfindet.
Bei Standalone Maschinen sollte der Prozess auch nicht erscheinen. Abgebildet ist der Fall wie es auf einem funktionierenden System aussehen muss.
19. HA-Status prüfen
|
1 |
show ha node |
Eine Differenz zwischen Konfiguration, Sync-Status oder ein ungesunder Node ist ein weiterer Hinweis auf Probleme – ggf. verursacht durch Angreifer.
Sofortmaßnahmen bei kompromittierten Systemen
- Netzwerkverbindung trennen
- Alle gespeicherten Passwörter ändern (LDAP, Admin, etc.)
- Neue SSL-Zertifikate & Schlüssel generieren, alte widerrufen
- Wenn VPX: Snapshot (älter als 3 Monate) ggf. prüfen
- Besser: Neuinstallation mit Import der Konfiguration
- Gleiche MAC verwenden, sonst Lizenz ungültig
- Appliance offline starten & Konsole prüfen
- nsroot Passwort ändern
- Logs und Events weiter überwachen
- SSL-Zertifikate auf dem neuen System erneuern
Fazit
Die Sicherheitslage rund um Citrix NetScaler bleibt angespannt.
Die Kombination aus aktivem Exploit, nicht unterstützten Legacy-Versionen und post-patching Risiken macht eine tiefgehende Prüfung jedes Systems unabdingbar.
Patchen reicht nicht – prüfen, dokumentieren und handeln.