Update 1-22-2020

Es gibt jetzt ein Tool von FireEye, das beim Scannen der folgenden Elemente hilft. Der Schlüssel dabei ist, dass Sie genügend Protokolle haben müssen, um bis zum 1.9.2020 zurückzugehen, um eine Chance zu haben, zu sehen, was über die Ausführung des Exploits hinaus getan wurde. Wenn es .XML-Payload-Dateien findet, müssen Sie die folgenden Informationen verwenden, um eine Entscheidung über die zu ergreifende Maßnahme zu treffen. https://www.fireeye.com/blog/products-and-services/2020/01/fireeye-and-citrix-tool-scans-for-iocs-related-to-vulnerability.html

Tool Download

https://github.com/citrix/ioc-scanner-CVE-2019-19781 https://github.com/fireeye/ioc-scanner-CVE-2019-19781/

Erkennung von Exploitation

Es gibt derzeit keine einfache Möglichkeit, zu beweisen, was jemand getan hat. Bei 4 öffentlichen Exploits hinterlässt jeder ein anderes Artefakt/Signatur, was für die Erkennung hilfreich ist, aber nicht 100%ig ist. Der Schlüssel ist, sich daran zu erinnern, dass dies die öffentlichen Exploits sind, die bis zum 10. privat waren, und das bedeutet auch nicht, dass es nicht noch andere da draußen gibt, die Leute nicht für ihren eigenen Gewinn teilen. Exploits sind in den meisten Fällen editierbar, wobei jemand den Namen der abgelegten Datei, den Namen des Benutzerkontos, den Namen des Prozesses, den Pfad der Abfrage und viele andere Optionen ändern kann, was bedeutet, dass die Möglichkeiten exponentiell steigen, dass jemand das System ausgenutzt haben könnte. Es gibt auch fortgeschrittene Angreifer und einfache Angreifer, einer wird nach sich selbst aufräumen und sehr clevere Wege finden, im System zu verschwinden, um der Erkennung zu entgehen.

Wenn Sie Nessus ausführen, können Sie diese .YAR-Datei unten verwenden, um einen privilegierten Scan durchzuführen, um nach den gängigen Erkennungsmethoden zu suchen. https://github.com/Neo23x0/signature-base/blob/master/yara/exploit_shitrix.yar

Exploit-Prüfung

Tolle Links zu diesem Prüfprozess. https://nerdscaler.com/2020/01/13/citrix-adc-cve-2019-19781-exploited-what-now/amp/ http://deyda.net/index.php/en/2020/01/15/checklist-for-citrix-adc-cve-2019-19781/

Haftungsausschluss: Wie bereits erwähnt, wird dies nicht jeden Exploit erkennen, aber es kann helfen, einige Anomalien zu erkennen, wenn der Angreifer die öffentlichen Exploits nicht modifiziert und/oder nicht aufgeräumt hat. Die meisten Angreifer werden den Standard-Exploit verwenden, und dies sind einige der dokumentierten Artefakte, die zurückbleiben könnten. Diese Liste von Befehlen wurde aus vielen Quellen zusammengetragen und wird sich dynamisch ändern, wenn andere Varianten, Workarounds und neue Entwicklungen auftauchen. Wir können damit rechnen, dass sich dies ständig ändert, wenn mehr Infektionen auftreten und weitere forensische Untersuchungen mit einer größeren Stichprobe abgeschlossen werden.

Schauen Sie sich zuerst Dinge an, die Sie nicht getan haben. Wenn Sie normalerweise nicht viel auf Ihrem ADC tun, sollten diese sehr ruhig sein, und es können Einträge von Wochen, Monaten oder Jahren von Ihrem letzten Besuch vorhanden sein. Es gibt genauere Abfragen weiter unten. Verstehen Sie auch, dass dies ein Katz-und-Maus-Spiel ist, selbst in diesem Blog. Während wir offenlegen, was wir gesehen haben und wie man Angreifer findet, nutzen diese diese Informationen gegen uns, indem sie ihre Taktiken ändern, um der Erkennung zu entgehen.

Exploitation Check Quick Punch List v1

1. Überprüfen Sie Ihre Lizenz; ich habe gehört, dass einige ihre Geräte neu gestartet haben und tatsächlich eine abgelaufene Lizenz hatten.
1. Holen Sie sich eine Support-Datei, auch Backup-System genannt: Diagnostics -> Get Support File und speichern Sie diese Datei ab.
1. Alle untenstehenden Befehle sind in NSCLI und wenn Sie per SSH auf das Gerät zugreifen und Shell verwenden, können Sie das Shell-Präfix weglassen.
1. Überprüfen Sie das Datum auf dem Gerät, um Protokollergebnisse zuzuordnen
- a. shell date
1. Überprüfen Sie Ihr Konfigurationsänderungsdatum
- a. Shell ls -l /netscaler/ | grep netscaler
- b. Shell ls -l /nsconfig | grep netscaler
  - i. Was ist das Datum Ihrer netscaler.conf?
  - ii. Sieht das richtig aus? Suchen Sie nach Dateiverweisen an andere Orte.
1. Überprüfen Sie die lokale Passwortdatei
- a. Shell ls -lh /etc/passwd
  - i. Überprüfen Sie, wann die Datei geändert wurde. Wenn nach dem Exploit und es nicht Sie waren, müssen Sie dieses Passwort so schnell wie möglich ändern.
  - ii. Ich empfehle, das Passwort von nsroot oder allen lokalen Konten zu ändern, wenn Exploits erkannt werden. In vielen Fällen
- b. Shell cat /etc/passwd
  - i. Schauen Sie, welche Konten dort vorhanden sind.
  - ii. Root, nsroot, daemon, operator, bin, nobody, sshd, nsmonitor sind Standard.
1. Überprüfen Sie Ihre Protokolle
- a. shell ls -lh /var/logfile
  - i. Sind die Dateien vorhanden? Sind sie sehr klein?
  - ii. https://support.citrix.com/article/CTX121898
1. Überprüfung auf schädliche Dateien
- a. Wenn eine dieser Dateien mehr oder weniger als 8-9 Zeichen und einen zufälligen Dateinamen hat, ist dies ein Zeichen für einen fortgeschritteneren Angreifer, der den Standard-Exploit geändert hat. Wenn Sie dies sehen, müssen Sie Ihre Behebung entsprechend anpassen. Pwnpzi1337.xml ist der Dateiname für den Project India Exploit.
- b. shell ls /netscaler/portal/templates/*.xml
  - i. Hier sollten keine XML-Dateien sein.
  - ii. Falls infiziert, sehen Sie sich die Dateidaten hier an.

Falls ausgenutzt

Was Sie tun müssen, hängt immer von Ihrer Bedrohungslandschaft ab. Hier sind einige meiner Gedanken, die ich Kunden mitgeteilt habe, die Anzeichen einer ausgeführten Ausnutzung gefunden haben.

Welche Compliance-Gremien decken Ihr Unternehmen ab? Finanzen/Banken, SOX, PCI, HIPPA, Bundesstaaten/Kommunen und Regierungsgesetze.

Wenn Sie unter eines dieser Rahmenwerke fallen, müssen Sie die Verfahren für diese Compliance-Gremien befolgen. Es gibt auch ethische Überlegungen basierend auf Zertifizierungen und Berufsgruppen, denen Sie angehören und die Bestimmungen für Incident Response und Offenlegung haben.

Hier sind Links zu diesen beiden bekannten Incident-Response-Prozessleitfäden https://security.berkeley.edu/incident-response-planning-guideline https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final

Eine Sache, die wir bisher wissen, ist, dass um den 10.1.2020 der erste öffentliche Exploit veröffentlicht wurde und es einige Berichte über Infektionen am 9. gibt, da genau zu diesem Zeitpunkt er veröffentlicht wurde. In den meisten Fällen ist das Risiko deutlich geringer, wenn Sie Ihr System vor 2020 gepatcht haben, im Vergleich zu später in diesem Monat.

CVE-2019-19781 Estimated Risk Threat Ramp

Dezember - 31. Dezember: Geringstes Exploit-Risiko
Januar - 8. Januar: Geringeres Exploit-Risiko
Januar - 13. Januar: Höheres Exploit-Risiko
Januar - Heute: Höchstes Exploit-Risiko

Dies sollte in Ihren Prozess für die nächsten Schritte einfließen.

Ich habe Spuren einer Ausnutzung gefunden, was nun? Das hängt immer noch davon ab: Eine Sache, die bei den meisten Citrix-ADC-Bereitstellungen nicht konfiguriert wird, ist ein gutes SNMP- und SYSLOG-Logging, und sie haben möglicherweise keine gute Möglichkeit, nach Artefakten zu suchen, zu filtern oder zu warnen. Wenn Sie absolut protokollieren und sicher sind, dass sie nichts getan haben, können Sie möglicherweise weitermachen. Wenn Sie dann etwas gefunden haben und ihren Fernzugriff sicher entfernen konnten, können Sie ebenfalls weitermachen.

Aber die meisten werden feststellen, dass sie einige Spuren finden und möglicherweise nicht in der Lage sind, die Punkte zu verbinden, was getan wurde und wohin sie gegangen sein könnten, und es könnte nach der Erkennung einfacher sein, die Geräte einfach zurückzusetzen.

Meine nächsten Ratschläge werden sich in den nächsten 2 Wochen ändern.

Beispielhafte Incident-Response-Pfade

Es gibt keine richtige und perfekte Antwort, die ich geben kann, die für jede Situation passt. Dies sind meine Gedanken vom 19.1.20 und sie können sich danach ändern, wenn ich mehr über nächste Schritte lerne und wenn neue Dinge auf der Verteidigungs- oder Angriffsseite im Zusammenhang mit dieser Schwachstelle veröffentlicht werden. Es gibt keine richtige Antwort, IT-Sicherheit ist wie die meisten Länder von 'es kommt darauf an' regiert. Ich empfehle dringend, wenn Sie etwas anderes als diese Dateien nur in diesen 3 Verzeichnissen finden, das Gerät als kompromittiert zu betrachten und den vorsichtigeren Weg zu gehen. In einigen Fällen empfehle ich, den vorsichtigeren Weg zu gehen, besonders wenn es keine Protokolle gibt, um zu bestätigen, was sie getan oder nicht getan haben. Sie müssen mit Ihrem Team zusammenarbeiten, um die beste Vorgehensweise basierend auf Ihrer Situation zu entscheiden, denn das ist ein Teamsport. Es gibt immer einen besseren Weg, solche Dinge zu beheben, aber basierend auf den Beweisen, die Sie auf dem Gerät und um das Gerät herum haben (Tier-1-Ziele), könnten Sie in Ordnung sein, indem Sie Ihr Risiko reduzieren und von dort aus weitermachen.

Schadensbegrenzung: Hier sollten Sie unabhängig vom Fall beginnen. Mit der neuen Firmware oder der Responder-Richtlinie.
Exploits während Ihrer Prüfung erkannt. - Starten Sie Ihren Incident-Response-Prozess.
Mit gutem Gerätelogging
- Anzeichen für fortgeschrittene Angriffe oder Persistenz
  - Neu aufbauen und migrieren
- Keine Anzeichen für fortgeschrittene Angriffe oder Persistenz
  - Beheben und weiterlaufen lassen
Ohne Gerätelogging
- Anzeichen für fortgeschrittene Angriffe oder Persistenz
  - Neu aufbauen und migrieren
  - Werksreset
- Keine Anzeichen für fortgeschrittene Angriffe oder Persistenz
  - Neu aufbauen und migrieren
  - Werksreset
Mit gutem Tier-1-Ziel-Logging
- Anzeichen für fortgeschrittene Angriffe oder Persistenz
  - Neu aufbauen und migrieren
  - Werksreset
- Keine Anzeichen für fortgeschrittene Angriffe oder Persistenz
  - Beheben und weiterlaufen lassen
Kein Tier-1-Ziel-Logging
- Anzeichen für fortgeschrittene Angriffe oder Persistenz
  - Neu aufbauen und migrieren
  - Werksreset
- Keine Anzeichen für fortgeschrittene Angriffe oder Persistenz
  - Neu aufbauen und migrieren
  - Werksreset

Reaktionsdefinition und Gedanken

Neu aufbauen und migrieren – Starten Sie Ihren Incident-Response-Prozess, dann können Sie diesen Prozess starten: https://docs.citrix.com/en-us/citrix-hardware-platforms/mpx/migrating-configuration-of-existing-appliance-to-another-appliance.html. Dies ist für VPX- und SDX-Kunden relativ einfach aufgrund der virtuellen Natur und der Flexibilität der Konfigurationsplattform. MPX-Migrationen sind eine andere Geschichte, da der Werksreset funktioniert und das Basisimage beibehalten wird; es könnte ein sehr geringes Risiko geben, dass ein fortgeschrittener Angreifer durch ein Firmware-Upgrade oder Werksreset persistiert. Die Wahrscheinlichkeit mag geringer sein, ist aber dennoch möglich (wie alles in der Cyberwelt).
Werksreset – Starten Sie Ihren Incident-Response-Prozess, entfernen Sie die .xml-Dateien und alles andere Erkannte, starten Sie neu und überprüfen Sie erneut auf Persistenz. Starten Sie dann den Prozess für den Werksreset. Es gibt Skripte von Citrix, die durch den Prozess führen. Dies löscht das System auf die niedrigste Ebene, bevor das Betriebssystem neu geladen wird, aber alle werden dieser Methode basierend auf ihrer Bedrohungslandschaft bisher vertrauen und möchten möglicherweise mehr.
- Die drastischste Methode wäre, die Geräte zu RMA, um die Laufwerke neu zu laden, und dies könnte basierend auf Ihrem Lebenszyklus, Ihrer Plattform und Ihrem Redundanzplan eine gute oder schlechte Idee sein. Ich würde dies nur vorschlagen, wenn Sie fortgeschrittene Techniken gesehen haben und eine laterale Bewegung basierend auf ihren Techniken bestätigt haben, um möglicherweise diesen Weg zu gehen. Ich weiß, dass Citrix an den 'Was-wäre-wenn'-Optionen arbeitet und
Beheben – Starten Sie den Incident-Response-Prozess, entfernen Sie die .xml-Dateien und alles andere Erkannte, starten Sie neu und überprüfen Sie erneut auf Persistenz. Wenn Sie gute Protokolle haben, wissen Sie, ob etwas getan wurde; wenn nicht, würde ich Ihre Bedrohungslandschaft betrachten und ob Sie Protokollierung auf Tier-1-Zielen oder etwas anderem haben, um zu wissen, ob Sie in Betracht ziehen müssen, dass ein Werksreset erforderlich ist und/oder ob Sie neu aufbauen und migrieren müssen.

Protokollierungsstufen

Gutes lokales Logging
- Sie sind in der besten Position, um lokal zu sehen, was passiert ist, um zu wissen, ob es Versuche lateraler Bewegung gab oder ob der Exploit einfach wie die meisten ausgeführt wurde.
Gutes Tier-1-Ziel-Logging
- Sie sind in der besten Position, um zu sehen, ob laterale Bewegung stattfand oder sogar versucht wurde. Dies sollten die ersten Dinge sein, die angegriffen werden könnten, und wenn Sie erfolgreiche laterale Bewegung gesehen haben, sollten Sie sich am meisten sorgen und mit größerer Vorsicht auf Ihrem Behebungspfad vorgehen. Wenn nicht, können Sie das Risiko der Bedrohung senken und einfach den Behebungspfad nehmen.
Kein lokales Logging
- Sie sind in der schlechtesten Position, um lokal zu sehen, was passiert ist, um zu wissen, ob es Versuche lateraler Bewegung gab oder ob der Exploit einfach wie die meisten ausgeführt wurde. Sie müssen auf Ihrem Behebungspfad mit größerer Vorsicht vorgehen.
Kein Tier-1-Ziel-Logging
- Sie sind in der schlechtesten Position, um zu sehen, ob laterale Bewegung stattfand oder sogar versucht wurde. Dies sollten die ersten Dinge sein, die angegriffen werden könnten, und wenn Sie erfolgreiche laterale Bewegung gesehen haben, sollten Sie sich am meisten sorgen und mit größerer Vorsicht auf Ihrem Behebungspfad vorgehen.

Ich hoffe, dass Leute die Infektion entfernen können und ausreichend gute Protokolle haben, um sicher zu sein, dass sie nicht mehr drin sind, und in der Lage sind, Ihre normalen Aktivitäten ohne einige dieser Schritte wieder aufzunehmen.

Weitere gute Folgeschritte

Es gibt zwei Hauptpunkte, über die Sie entscheiden müssen, wenn es Anzeichen einer Ausnutzung gibt.

1. NSROOT-Passwort ändern
- a. Ich empfehle dies unabhängig davon, was Sie finden oder welche Protokolle Sie haben. Dies ist eine Gelegenheit, nsroot in den Passwortwechsel-Rhythmus einzubeziehen. ADC-Management sollte an LDAP gebunden sein und NSROOT sollte nur für Notfälle verwendet werden.
1. LDAP-Dienstkonto (oder einen anderen Authentifizierungsdienst) ändern
- a. Ändern Sie dieses Passwort und ich empfehle, wenn möglich zu einem anderen Konto zu wechseln, damit Sie auch eine andere SID haben. Dies kann eine passive Änderung sein, die niemand bemerkt, wenn sie vor dem Rollout getestet wird.
1. SSL-Schlüssel ändern
- a. Gutes Logging
  - i. Vielleicht sind Sie in Ordnung, wenn Sie zu 100% sicher sind, dass es gut ist.
  - ii. Ein Teil von mir möchte trotzdem sagen, alle Schlüssel zu erneuern, aber ich weiß, wie viel Arbeit das in einem großen Unternehmen sein kann.
- b. Kein Logging
  - i. Ich denke, Sie müssen alles darauf erneuern. Es gibt PEM- und PFX-Schutz, aber ich habe viele Orte gesehen, die sehr einfache Passwörter dafür verwenden, die offline brute-forced werden könnten. Da wir es nicht wissen, müssen wir das Unternehmen schützen.

Gedanken zu Passwörtern

Ich empfehle, Ihre Passwörter für alle lokalen Konten auf dem Gerät zu ändern, wenn es irgendeinen Hinweis auf einen erfolgreichen Exploit gibt. Ändern Sie es, denn in vielen Bereitstellungen wurde es möglicherweise seit der ursprünglichen Bereitstellung vor 4-7 Jahren nie geändert. Wenn Sie Anzeichen von Befehlszeilenzugriff und/oder Manipulation sehen, können Sie höchstwahrscheinlich davon ausgehen, dass der Angreifer das Passwort knacken kann; bei Pre-11.0-Firmware war es AES256 und in späteren Builds wird AES512 verwendet, was ebenfalls anfällig für Knacken sein kann. Stellen Sie außerdem sicher, dass es sicher an LDAP gebunden ist und Sie Benachrichtigungen für NSROOT-Anmeldungen eingerichtet haben.

LDAP-Gedanken

Wenn Sie ein gewisses Maß an Ausnutzung gesehen haben, würde ich auch sicherstellen, dass jedes Dienstkonto geändert wird, das in der Citrix-ADC-Konfiguration definiert wurde. Das häufigste ist das LDAP/Kerberos-Bind-Konto. Dass jemand einen Exploit auf einem Citrix-ADC ausführt, bedeutet nicht, dass sie Domain-Admins sind, aber es könnte je nach Ihren Kontrollen und Protokollierung nicht zu lange dauern. Dies ist eine sehr einfache Änderung, die, wenn getestet, für Benutzer nahtlos sein kann.

Gedanken zu Zertifikaten

Abhängig davon, was Sie bei Ihrer Prüfung gefunden haben, hilft dies auch bei der Entscheidung. Wenn Sie gute Protokolle hatten und sehen können, dass auf diese Datei zugegriffen wurde, müssen Sie die Schlüssel erneuern. Wenn Sie keine guten Protokolle haben, sollten Sie ebenfalls die Schlüssel erneuern. Wenn Sie ein Wildcard-Zertifikat haben, ist das auch ein großes Problem, und je mehr Websites daran gebunden sind, desto größer sind Ihr Risiko und Ihre Gefährdung. Das Schlimmste, was passieren kann, ist, dass Sie annehmen, es sei in Ordnung, und jemand eine Phishing-Site mit Ihrem Zertifikat betreibt, bei der all Ihre Schulungen die Klicks nicht verhindern. Dies kann zu viel größeren Problemen führen, wenn jemand Zugriff auf Ihre Zertifikate hat, und ich würde empfehlen, vorsichtig vorzugehen und eine Schlüsselerneuerung durchzuführen. Dies könnte ein guter Zeitpunkt sein, basierend auf dem Ablaufdatum des aktuellen Zertifikats. Ich habe gesehen, dass einige in diesem Prozess zu einem anderen Zertifikatsregistrar wechseln, nur um etwas zu ändern, aber sie hatten Protokolle, dass auf die Datei zugegriffen und sie heruntergeladen wurde, zusammen mit anderen fortgeschrittenen Techniken, die erkannt wurden.

Danksagungen ###Zu guter Letzt einige Danksagungen an einige der Personen, die sich seit dem ersten Auftauchen dieses Problems damit beschäftigt haben. Es gibt noch viele weitere Personen, die nicht auf dieser Liste stehen, weil sie hinter den Kulissen arbeiten und ich sie nicht gesehen habe.

Citrix-Team – Arbeit daran, die Informationen zu verbreiten und gleichzeitig an diesen neuen Firmwares zu arbeiten. Sie müssen aufgrund der Unterschiede zwischen den Codefamilien gleichzeitig an 5 Patches arbeiten, was die Sache noch schwieriger macht.
Daniel Weppeler @_DanielWe – Protokollierung der Responder-Richtlinie zur Erkennung von Probes/Angriffen
Florian Roth @cyb3rops – Nessus YAR-Datei zur Erkennung von Exploits
CTP Anton van Pelt @AntonvanPelt & CTA Mads Petersen @mbp_netscaler & Jan Tytgat @jantytgat – Ständige Arbeit mit den CTP/CTA- und Citrix-Teams an vielen Fronten.
KevTheHermit @KevTheHermit – Offenlegung des AWS-Instanz-Passwort-Schwachstelle zusätzlich zur CVE
Bad Packets Report @bad_packets – Das gesamte Bad Packets-Team https://badpackets.net
Kevin Beaumont @GossiTheDog – Massive Promotion der beobachteten Probleme sowie einige Details zu seinem Honeypot und seinen Beobachtungen.
Mpgn @mpgn_x64 – Details zum Exploit und Varianten des Exploits
Nick Carr @ItsReallyNick – Details zum Exploit und Tipps zur Incident Response.
Digi Cat u/digicat – Reddit-Benutzer, erstaunlicher aktueller Nachrichten-Blog.
Ben Sadeghipour @NahamSec – DFIR-YouTube-Video und andere Beiträge
SANs-Team – Artikel und DFIR- und Deep-Dive-Videos
Craig Dods @0xCraig – Passwort-Implikationen und Forschung
Manuel Kolloff @manuelkolloff – Exploitation Post-Exploit-Walkthroughs.
FireEye und Mandiant-Team Vielen Dank an Rick Cole für die Erstellung unserer frühesten Erkennungsabdeckung und an das Team der Mandiant-Incident-Responder für Input zu diesem Blog – insbesondere Austin Baker, Brandan Schondorfer und John Prieto – sowie an alle Berater, die ihre Kundenumgebungen vor dieser Schwachstelle schützen oder darauf reagieren. Danke auch an Nicholas Luedtke von unserem Vulnerability-Intelligence-Team für seine Unterstützung bei der Verfeinerung des Zeitplans für Offenlegung und Tools in diesem Blog.

CVE-2019-19871-AuditGuide

Beliebteste