Checkliste für NetScaler (Citrix ADC) CVE-2023-4966

Citrix hat vor einiger Zeit (10.10.2023) eine Warnung über eine kritische Sicherheitslücke (CVE-2023-4966) in allen NetScaler (Citrix ADC) & Gateway Systemen veröffentlicht. Es sind mehrere funktionierende Exploits veröffentlicht.

Hier ist zu beachten, das ein reines updaten der Systeme nicht ausreicht. Es müssen auch noch die Connection Tokens zurückgesetzt werden.

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, 13.1 oder 14.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.

Es ist anzunehmen das von verschiedenen Einrichtungen erstellte Listen, über NetScaler (Citrix ADC) Maschinen im Internet, nun angegriffen wird.

Der Output eines Scripts bei einem System das noch nicht gepatcht ist und/oder für den Citrix Bleed anfällig wäre.

Firmware Updates

Citrix hat für alle unterstützen Versionen einen Patch zur Verfügung gestellt.

NetScaler (Citrix ADC) und NetScaler (Citrix) Gateway
VersionRefresh BuildExpected Release Date
13.013.0-92.19Patch is here
13.113.1.-50.23Patch is here
14.114.1.-12.30Patch is here

Anleitung zum Updaten der Appliances findet man hier.

Arbeiten nach dem Update

Im Anschluss an das Update auf eine nicht mehr betroffene Version, müssen alle aktiven und dauerhaften Sitzungen mit den folgenden Befehlen beendet werden.

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

Timestamp installer files

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.

Suspicios files webshells

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.

Oder mit dem folgenden Python Befehl.

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.

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.

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.

Hier im Screenshot sind nur meine Tests zu sehen und kein Angriff.

Log Dateien

Prüfen der Log Dateien auf bekannte IOCs.

Editierte Dateien mit dem setuid Bit

Nobody Prozesse

Im Kontext des Nobody Benutzers wurden bei Angriffen auch neue Prozesse gestartet. Hier ein Beispiel für die erlaubten Prozesse.

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.

Es sollte kein Crontab für nobody vorhanden sein. Dies kann mit dem folgenden Befehl geprüft werden.

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

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.

Sowie Webzugriffe von HeadlessChrome aus.

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.

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.

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.

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

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

* Ich bin damit einverstanden, dass diese Website die von mir übermittelten Daten speichert, damit sie auf meine Anfrage antworten kann.