Table of Contents
Citrix hat eine Woche vor Weihnachten eine Warnung über eine kritische Sicherheitslücke (CVE-2019-19781) in allen Citrix ADC & Gateway Systemen veröffentlicht. Seit dem 10.1.2020 wurden mehrere funktionierende Exploits veröffentlicht, die für jeden zugänglich sind.
Wichtig ! Der Fix von Citrix mit der Responder Policy funktioniert nicht bei Systemen mit der Version 12.1.51.16/51.19, 50.31 und älter. Wenn diese Version im Einsatz ist, bitte auf die aktuellste 12.1 Version updaten.
Die Exploits ermöglichen eine anonyme Ausführung von Remotecode und dadurch nicht authentifizierten Angreifern, die verschiedenen Maschinen mit Root Rechten zu übernehmen.
Seit geraumer Zeit wird von verschiedenen Einrichtungen ein massives Scannen nach Citrix ADC Maschinen wahrgenommen. Diese erstellte Liste wird nun angegriffen.
Für reine Microsoft Admins gibt es nun auch Powershell Scripts um zu prüfen, ob das System korrumpiert oder noch offen ist.
Firmware Updates
Citrix kann derzeit keinen Patch zur Verfügung stellen. Es stehen aber schon Termine fest, wann diese erscheinen werden:
| Citrix ADC and Citrix Gateway | ||
|---|---|---|
| Version | Refresh Build | Expected Release Date |
| 10.5 | 10.5.70.12 | Patch is here |
| 11.1 | 11.1.63.15 | Patch is here |
| 12.0 | 12.0.63.13 | Patch is here |
| 12.1 | 12.1.55.18 | Patch is here |
| 13.0 | 13.0.47.24 | Patch is here |
| Citrix SD-WAN WANOP | ||
| Release | Citrix ADC Release | Expected Release Date |
| 10.2.6 | 10.2.6b | Patch is here |
| 11.0.3 | 11.0.3b | Patch is here |
Anleitung zum Updaten der Appliances findet man <<hier>>
Workaround
Führt die folgenden Befehle über das Command line interface der GUI oder direkt auf der Appliance (über Putty) aus.
Command line interface
- Logt euch auf das betroffene System ein und geht dort auf die Navigationspunkte System > Diagnostics
- Im Menüpunkt Diagnostics geht ihr auf der rechten Seite auf Command line interface
- In der CLI lönnt ihr die folgenden Befehle eingeben und einzeln per Go ausführen
Direkt per Putty
- Startet Putty und gebt die Management IP des betroffenen Systems ein
- Verbindet euch mit dem System und gebt euren Benutzer und das Passwort ein
- Nun könnt ihr die unten aufgeführten Befehle einfügen und ausführen
Standalone System
Mit dem folgenden Befehlen werden die Responder Actions & Policy erstellt.
|
1 2 3 4 5 |
enable ns feature responder add responder action respondwith403 respondwith "\"HTTP/1.1 403 Forbidden\r\n\r\n\"" add responder policy ctx267027 "HTTP.REQ.URL.DECODE_USING_TEXT_MODE.CONTAINS(\"/vpns/\") && (!CLIENT.SSLVPN.IS_SSLVPN || HTTP.REQ.URL.DECODE_USING_TEXT_MODE.CONTAINS(\"/../\")) || HTTP.REQ.HEADER(\"NSC_USER\").CONTAINS(\"/../\") || HTTP.REQ.HEADER(\"NSC_NONCE\").CONTAINS(\".pl\")" respondwith403 bind responder global ctx267027 1 END -type REQ_OVERRIDE save config |
Nun stellen wir noch sicher, dass die Änderungen auch für die Management Schnittstelle gelten.
|
1 2 3 |
shell nsapimgr_wr.sh -ys skip_systemaccess_policyeval=0 shell "echo 'nsapimgr_wr.sh -ys skip_systemaccess_policyeval=0' >> /nsconfig/rc.netscaler" reboot |
HA Pair
Auf dem Primary
Gebt folgendes per Putty oder CLI ein.
|
1 2 3 4 5 |
enable ns feature responder add responder action respondwith403 respondwith "\"HTTP/1.1 403 Forbidden\r\n\r\n\"" add responder policy ctx267027 "HTTP.REQ.URL.DECODE_USING_TEXT_MODE.CONTAINS(\"/vpns/\") && (!CLIENT.SSLVPN.IS_SSLVPN || HTTP.REQ.URL.DECODE_USING_TEXT_MODE.CONTAINS(\"/../\")) || HTTP.REQ.HEADER(\"NSC_USER\").CONTAINS(\"/../\") || HTTP.REQ.HEADER(\"NSC_NONCE\").CONTAINS(\".pl\")" respondwith403 bind responder global ctx267027 1 END -type REQ_OVERRIDE save config |
Danach schwenkt den HA State der Maschine per GUI oder Shell Command auf Secondary.
- Navigiert nach System > High Availability
- Im Nodes Reiter, wählt einen Node aus und klickt in der Action list auf Force Failover.
Oder gebt per Putty oder CLI den folgenden Befehl ein:
|
1 |
force HA failover |
Nun stellen wir noch sicher, dass die Änderungen auch für die Management Schnittstelle gelten. Wieder über Putty oder CLI, folgendes eingeben.
|
1 2 3 |
shell nsapimgr_wr.sh -ys skip_systemaccess_policyeval=0 shell "echo 'nsapimgr_wr.sh -ys skip_systemaccess_policyeval=0' >> /nsconfig/rc.netscaler" reboot |
Auf dem Secondary, nachdem der Primary gestartet ist
Schwenkt den HA State der Maschine per GUI oder Shell Command wieder auf Secondary und gibt danach folgendes über Putty oder CLI ein.
|
1 2 3 |
shell nsapimgr_wr.sh -ys skip_systemaccess_policyeval=0 shell "echo 'nsapimgr_wr.sh -ys skip_systemaccess_policyeval=0' >> /nsconfig/rc.netscaler" reboot |
Cluster
CLIP
Gebt folgendes per Putty oder CLI ein.
|
1 2 3 4 5 |
enable ns feature responder add responder action respondwith403 respondwith "\"HTTP/1.1 403 Forbidden\r\n\r\n\"" add responder policy ctx267027 "HTTP.REQ.URL.DECODE_USING_TEXT_MODE.CONTAINS(\"/vpns/\") && (!CLIENT.SSLVPN.IS_SSLVPN || HTTP.REQ.URL.DECODE_USING_TEXT_MODE.CONTAINS(\"/../\")) || HTTP.REQ.HEADER(\"NSC_USER\").CONTAINS(\"/../\") || HTTP.REQ.HEADER(\"NSC_NONCE\").CONTAINS(\".pl\")" respondwith403 bind responder global ctx267027 1 END -type REQ_OVERRIDE save config |
Nun stellen wir noch sicher, dass die Änderungen auch für die Management Schnittstelle gelten und geben folgendes über Putty oder CLI ein.
|
1 2 3 |
shell nsapimgr_wr.sh -ys skip_systemaccess_policyeval=0 shell "echo 'nsapimgr_wr.sh -ys skip_systemaccess_policyeval=0' >> /nsconfig/rc.netscaler" reboot |
Auf jedem Cluster Knoten
Gebt folgendes per Putty oder CLI ein.
|
1 2 3 |
shell nsapimgr_wr.sh -ys skip_systemaccess_policyeval=0 shell "echo 'nsapimgr_wr.sh -ys skip_systemaccess_policyeval=0' >> /nsconfig/rc.netscaler" reboot |
In der Admin Partition
Gebt folgendes per Putty oder CLI ein.
|
1 2 3 4 5 6 7 8 9 |
switch ns partition default enable ns feature responder add responder action respondwith403 respondwith "\"HTTP/1.1 403 Forbidden\r\n\r\n\"" add responder policy ctx267027 "HTTP.REQ.URL.DECODE_USING_TEXT_MODE.CONTAINS(\"/vpns/\") && (!CLIENT.SSLVPN.IS_SSLVPN || HTTP.REQ.URL.DECODE_USING_TEXT_MODE.CONTAINS(\"/../\")) || HTTP.REQ.HEADER(\"NSC_USER\").CONTAINS(\"/../\") || HTTP.REQ.HEADER(\"NSC_NONCE\").CONTAINS(\".pl\")" respondwith403 bind responder global ctx267027 1 END -type REQ_OVERRIDE save config shell nsapimgr_wr.sh -ys skip_systemaccess_policyeval=0 shell "echo 'nsapimgr_wr.sh -ys skip_systemaccess_policyeval=0' >> /nsconfig/rc.netscaler" reboot |
Ü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.
Bash Skript zum überprüfen des Systems
Daniel Weppeler hat ein Bash Script erstellt um Citrix ADC / Netscaler auf Korrumpierung zu prüfen.
Download des Scripts in Git unter
Danach könnt ihr das Script wie folgt starten.
|
1 |
bash CVE-NetScalerFileSystemCheck.sh |
Citrix hat auch noch ein Script herausgebracht. Ladet es hier runter und kopiert es dann auf den Netscaler / Citrix ADC hoch. Startet es danach, mit dem folgenden Befehl (Bei mir liegt es in /tmp).
|
1 |
shell bash ./ioc-scanner-CVE-2019-19781-v1.2.sh > "/tmp/results-$(date).txt" |
Danach könnt ihr den Log File prüfen, mit den folgenden Befehlen.
|
1 2 3 |
shell cd /tmp vi results(Datum der Datei).txt |
XML Dateien
Die Exploits schreiben alle Dateien in mehrere verschiedene Verzeichnisse. Überprüft daher die folgenden Verzeichnisse, ob dort Unbekannte Benutzernamen auftauchen. Mittlerweile löschen Hacker diese Dateien, nachdem diese sich aufgeschaltet haben. Alle Befehle sollten per Putty oder CLI ausgeführt werden.
|
1 |
shell ls -latr /netscaler/portal/templates/*.xml |
Dieses Verzeichnis beinhaltet normalerweise keine XML-Dateien und daher sollte folgende Anzeige folgen.
Wenn Dateien gefunden worden sind, ist ein erster Zugriff auf das System schon geschehen.
|
1 |
shell ls -latr /var/tmp/netscaler/portal/templates |
Dieses Verzeichnis existiert normalerweise gar nicht.
Wenn aber kein Error kommt oder sogar Dateien in diesem Ordner sind, wurde das System erfolgreich angegriffen.
Hier ein Angriff mit einer .xml.ttc2 Datei.
Der Inhalt der .xml.ttc2 Datei.
|
1 |
shell ls -latr /var/vpn/bookmark/*.xml |
Dieses Verzeichnis sollte nicht existieren oder nur XML-Dateien beinhalten, von Benutzern die man kennt.
Wenn XML-Dateien in diesem Ordner vorhanden sind, die Unbekannt sind, wurde das System erfolgreich angegriffen.
Wenn Dateien vorhanden sind, diese umgehend löschen, um weitere Angriffe direkt zu bemerken.
Neue Ordner
Die folgenden Ordner sollten nicht vorhanden sein (NOTROBIN-Backdoor).
|
1 |
shell ls -latr /tmp/.init |
|
1 |
shell ls -latr /var/nstmp/.nscache |
UDP Listener
Bei einer Attacke, wo der Angreifer alle anderen Backdoors schliesst, baut er sich selber dann eine Backdoor über UDP Port 18634 auf. Scannt daher genau nach diesem Port.
|
1 |
shell netstat | grep 18634 |
Bash logs
Es können bei Attacken auch Einträge in der bash.logs erscheinen. Wir suchen hier nach dem Benutzer nobody, da dies seine Rechte sind, wenn er über Apache kommt und einem Pfad der bei Angriffen erstellt wird.
|
1 2 3 4 |
shell cat /var/log/bash.log | grep nobody shell gzcat /var/log/bash.*.gz | grep nobody shell cat /var/log/bash.log | grep /tmp/.init/httpd shell gzcat /var/log/bash.*.gz | grep /tmp/.init/httpd |
Abgebildet einige Angriffe.
Apache Log Dateien
Darüber hinaus hinterlassen Angriffe, Einträge in den Apache httpaccess Log Dateien.
|
1 |
shell cat /var/log/httpaccess.log | grep vpns | grep xml |
Attacken….
|
1 |
shell cat /var/log/httpaccess.log | grep "/\.\./" |
Abgebildet sind weitere Attacken.
|
1 |
shell gzcat /var/log/httpaccess.log.*.gz | grep vpns | grep xml |
Und noch mehr Attacken..
|
1 |
shell gzcat /var/log/httpaccess.log.*.gz | grep "/\.\./" |
Oben eine Attacke mit einem netten Verweis auf die offene Stelle unter CVE-2019-19781 (11 Januar 2020 07:39:59) und weitere Angriffe am Abend (19:18:11 usw.)
Cron Jobs
Angreifer könnten sich über die Cron-Jobs eine Backdoor eingebaut haben und damit einen persistenten Zugriff erhalten, auch wenn die Schwachstelle gepatcht wird. Überprüft eure crontab Datei auf Anomalien.
|
1 |
shell cat /etc/crontab |
Unten aufgeführt eine nicht korrumpierte crontab Datei.
Überprüft nun noch, ob neue Benutzer hinzugefügt worden sind. Unten aufgeführt die normalen Benutzer in der passwd Datei bei Citrix ADC / Netscaler vor der Version 13.0.
|
1 |
shell cat /etc/passwd |
Hier eine Liste der Benutzer auf einem Citrix ADC Version 13.0.
Überprüft nun noch, ob einer der vorhandenen Benutzer einen Cron Job zugeordnet hat (hier z.B. der Benutzer nobody).
|
1 |
crontab -u nobody -l |
Hier sieht man die crontab Datei bei einem korrumpierten Server.
Inhalt dieser Datei.
Löscht diese Datei aus dem Pfad:
|
1 |
/var/cron/tabs |
Die ERROR Antwort bedeutet nur das diese Benutzer keine Cron Jobs zugeordnet haben, was ein normales Verhalten ist.
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 auxd | grep nobody |
Und ein attackierter Server. Die oberste Zeile ist Schadsoftware.
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 angebildeten grep Abfragen zu sehen sind, sollten die weiteren Skripte, durch eine Google Suche überprüft werden.
Dies sind normale Skripte für eine ADC Instanz die in Azure gehostet ist.
Crypto Miners
Ich habe mehrere ADC 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 |
Vorgehensweise nach Update durch Citrix (Standalone,CLIP, HA Primary)
Führt die folgenden Befehle in Putty oder über die CLI aus, nachdem der Patch von Citrix (Ende Januar) installiert ist.
|
1 2 3 4 |
unbind responder global ctx267027 rm responder policy ctx267027 rm responder action respondwith403 save config |
Entfernen des nsapi Befehls aus der rc.netscaler Datei.
|
1 2 3 |
shell nsapimgr_wr.sh -ys skip_systemaccess_policyeval=1 shell "sed -i '' '/skip_systemaccess_policyeval=0/d' /nsconfig/rc.netscaler" reboot |
Ein Neustart der Instanzen ist nicht notwendig, um die Richtlinie anzuwenden. Es ist ein vorbeugender Schritt, um sicherzustellen, dass alle offenen Sitzungen, die über die Schwachstelle eingegangen sind, gelöscht werden.
Gegenmaßnahmen bei betroffenen Systemen
Wie DJ Eshelmann in seinem Blog schreibt, soll man folgendes tun, wenn das System korrumpiert wurde.
- Nehmt die ADC Instanz vom Netzwerk
- Ändert das Kennwort aller auf dem ADC 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 ADC gespeichert, die theoretisch vom Angreifer ausgelesen werden könnten)
- Wenn es eine VPX Appliance ist und Snapshots des Geräts (älter als der 9. Januar 2020) 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
- Führt den oben aufgeführten Fix aus
- 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 Zertifkate und SSL Keys