Monitoring von Pulse Connect Secure mit Splunk (CISA Emergency Directive 21-03)

Mit Beiträgen von Mick Baccio, James Brodsky, Tamara Chacon, Shannon Davis, Dave Herrald, Kelly Huang, Ryan Kovar, Marcus LaFerrerra, Michael Natkin, John Stonerund Bill Wright.

Update vom 4. Mai 2021: In den letzten beiden Wochen gab es ein paar wichtige Entwicklungen. Die erste und wichtigste ist, dass Pulse Secure am 3. Mai ein Update veröffentlicht hat, das mehrere Schwachstellen betrifft. Splunk empfiehlt allen Pulse-Secure-Benutzern, das Update so schnell wie möglich zu prüfen und zu installieren. Die CISA hat ihre Warnung (AA21-110A) bereits am 30. April aktualisiert, zu den neuen Erkennungen gehören „Impossible Travel“ und eine JA3-Analyse. Wir haben unsere Indikatorensammlung für Splunk um die aktuellen Informationen von CISA ergänzt.

Wenn ihr sofort wissen wollt, wie ihr potenzielle Schwachstellen oder Exploits in eurer Pulse Connect Secure Appliance findet, dann springt einfach nach unten zum Abschnitt „Identifikation, Monitoring und Suche mit Splunk“. Andernfalls lest weiter und verschafft euch einen schnellen Überblick darüber, was passiert ist, wie ihr Kompromittierungen erkennt und wie die Zuordnungen von MITRE ATT&CK aussehen.

Was ihr über die Angriffe auf Pulse Connect Secure wissen müsst

In den letzten Wochen gab es vermehrt Gerüchte über Angreifergruppen, die diverse Schwachstellen in der VPN-Appliance Pulse Connect Secure (PCS) ausnutzen. Am 20. April 2021 veröffentlichte das Mandiant-Team von FireEye einen Blog-Beitrag, in dem es seine Erkenntnisse aus mehreren aktuellen Vorfällen mit kompromittierten PCS-Appliances detailliert darlegt. Dieser Bericht hat aufgeregte Reaktionen bei etlichen Organisationen hervorgerufen, bei Behörden ebenso wie bei Sicherheitsanbietern. Am selben Tag veröffentlichte die Cybersecurity and Infrastructure Security Agency (CISA) beim Department of Homeland Security (DHS) den Alert AA21-110A und die Emergency Directive 21-03, welche alle US-Bundesbehörden verpflichtet, bestimmte Maßnahmen bezüglich der PCS-Appliances in ihren Umgebungen zu ergreifen. Splunk rät allen US-Bundesbehörden, dieser DHS-Richtlinie zu folgen, allein aus Gründen der Compliance.

Laut einem Blog-Beitrag von Pulse Secure betreffen die in dieser Woche bekannt gewordenen Vorfälle Schwachstellen, die 2019 und 2020 bereits gepatcht wurden, sowie ein neues Problem (CVE-2021-22893 bzw. Security Advisory SA44784), das in diesem Monat entdeckt wurde. Der Hersteller weist darauf hin, dass ein Software-Update für diese neue Schwachstelle Anfang Mai verfügbar sein wird. Der Beitrag enthält wertvolle Hinweise zu allen Schwachstellen und zu den empfohlenen Abhilfemaßnahmen sowie Informationen zum Kundensupport. Von besonderer Bedeutung ist das Pulse Connect Secure Integrity Tool, mit dem ihr überprüfen könnt, ob kritische Komponenten eurer PCS-Appliance-Software manipuliert wurden. Splunk empfiehlt allen PCS-Kunden, diese Herstelleranleitung in vollem Umfang zu befolgen.

Die PCS-Appliance ist eine beliebte Lösung für Virtual Private Networks (VPNs), die Mitarbeitern von jedem Ort der Welt aus einen sicheren Zugang zu den internen Netzwerken einer Organisation ermöglichen soll. Da VPN-Appliances eine wichtige Rolle bei der Absicherung des Netzwerkperimeters spielen und logischerweise direkt dem Internet ausgesetzt sind, werden sie häufig von Angreifern ins Visier genommen. Obwohl sich die jüngsten Nachrichten speziell auf Pulse-Secure-Produkte beziehen, sind Angriffe dieser Art nicht auf einen bestimmten Hersteller beschränkt. Gegner greifen häufig auf Schwachstellen in VPN-Produkten zurück, um sich unbefugten Zugang zu verschaffen. Erst am 16. April 2021 veröffentlichte die National Security Agency (NSA) in den USA ein Cybersecurity Advisory, das davor warnt, dass ältere Schwachstellen von mindestens fünf verschiedenen Remote-Access-Produkten aktiv ausgenutzt werden.

Identifikation, Monitoring und Suche mit Splunk

Hier habt ihr ein paar nagelneue Suchen, mit denen ihr etliche der im FireEye- bzw. Mandiant-Blog und in anderen Quellen beschriebenen Bösartigkeiten ausfindig machen könnt. Wenn wir bereits Splunk Security Content zu diesen Suchläufen haben, so sind sie unten im Abschnitt „MITRE ATT&CK“ aufgeführt und verlinkt.

Beachtet bitte, dass es PoC-Exploits (Proof of Concept) nur für einige der Schwachstellen gibt, die zu diesem Angriff gehören. Die nachstehenden Erkennungen stammen alle aus einer Laborumgebung und beruhen auf Informationen aus dem im FireEye-/Mandiant-Bericht angegebenen Kontext. Sobald uns weitere Erkenntnisse vorliegen, werden wir Updates veröffentlichen.

PCS-Appliance-Daten in Splunk einlesen

Einige der folgenden Techniken setzen voraus, dass die Logs eurer PCS-Appliances zur Analyse in Splunk eingelesen werden. PCS-Appliances verwenden syslog zur Protokollierung in externen Systemen wie Splunk. Ivanti verzeichnet die Konfigurationsdetails im Administratorhandbuch für PCS-Appliances; hier ist der Link zum Administratorhandbuch in Version 9.1R11 (der Stand heute aktuellen Version). PCS-Appliances unterstützen mehrere Log-Exportformate (Standard, WELF, W3C). Jedes davon liefert leicht unterschiedliche Daten und Ergebnisse. 2015 verkaufte Juniper Networks die Reihe Junos Pulse an Pulse Secure, LLC, das jetzt zu Ivanti gehört. Die frühen Versionen des Splunk-Add-ons für Juniper enthielten Unterstützung für die IVE-/SA-Produktlinie (jetzt PCS), mit Sourcetype „juniper_sslvpn“ oder „juniper:ive“. Seitdem haben Drittanbieter ihre eigenen Technology Add-ons (TAs) auf Splunkbase (zum Beispiel hier) oder GitHub (zum Beispiel hier) veröffentlicht, um PCS-Appliance-Log-Daten weiterhin zu unterstützen. Das RWI-Szenario von BOTS V etwa nutzte WELF-formatierte Log-Daten von einer Juniper SA, die dieses TA verwendet. Bitte beachtet, dass manche Beispiele in diesem Beitrag den Sourcetype „juniper:ive“, andere „pulse:connectsecure“ und wieder andere „syslog“ verwenden. Damit soll die Vielfalt der Formate abgebildet werden, die wir in freier Wildbahn beobachten. Ihr ermittelt am besten den Sourcetype, der in eurer Umgebung verwendet wird, und ersetzt ihn bei Bedarf in diesen Beispielsuchen.

Darüber hinaus empfehlen wir, das Logging für „Unauthenticated Requests“ zu aktivieren (diese Einstellung ist in den PCS-Appliances standardmäßig deaktiviert). Dies kann zwar das Log-Volumen geringfügig erhöhen, aber die CISA-Warnung zeigt, dass es unerlässlich ist, wenn ihr Hinweise auf Manipulationen und potenziell noch andauernde Schadaktivitäten finden wollt.

Versionsüberprüfung

Den Bulletins dieser Woche zufolge haben bestimmte Versionen der Pulse-Secure-Appliance-Software kritische Sicherheitslücken. Daher ist es wichtig, dass ihr die Versionen aller PCS-Appliances, die ihr in eurem Netzwerk habt, katalogisiert, damit ihr einen Plan zur Schadensbegrenzung erstellen könnt. Ihr könnt dazu Splunk verwenden, wenn ihr keine anderen Mittel zur Verfügung habt. Wenn ihr bereits über eine Liste von IP-Adressen eurer PCS-Appliances verfügt, könnt ihr diese Liste als Lookup in ein einfaches Technology Add-on für Splunk übernehmen, das wir gebaut haben; es prüft jedes Gerät auf der Liste der Reihe nach und meldet die gefundene PCS-Version zum Reporting oder für Alerts an Splunk.

index=main source="checkpcsversions.sh"
| stats values(pcs_version) as "PCS Version" by dest_ip
| iplocation dest_ip

CVE-2021-22893 – Monitoring auf Abhilfe

Mit dieser Technik könnt ihr eure Gefährdung einschätzen und Appliances ausfindig machen, die möglicherweise noch nach der Pulse-Secure-Anleitung entschärft werden müssen. Wir schlagen vor, dass ihr diese Logs nach Hinweisen auf das Folgende durchsucht:

• Windows File Share Browser
• Pulse Secure Collaboration
  

Warum? Weil beide Services verwundbar sind und der Workaround, den ihr bereits nutzen solltet, diese beiden Funktionen deaktiviert. Wenn ihr also in den Protokollen seht, dass eine dieser beiden Funktionen noch aktiv ist, und wisst, dass auf eurer Appliance eine anfällige Pulse-Secure-Version läuft, müsst ihr die entsprechende Abhilfe in Form der Datei workaround-2104.xml anwenden. Ihr könnt einen Bericht oder Warnungen auf Basis aller Appliances erstellen, die noch Dateifreigabe- oder Collaboration-Aktivitäten verzeichnen, und den Report bzw. die Warnmeldungen eurem Netzwerkteam zur Verfügung stellen, damit der Workaround implementiert werden kann. Pulse Secure hat versprochen, Anfang Mai 2021 ein Update zu veröffentlichen. Dann kann dieser Workaround wieder rückgängig gemacht werden, sodass diese beiden Funktionen bei Bedarf wiederhergestellt werden können.

Aktivität von Pulse Secure Collaboration

Hier eine schnelle und einfache Suche, um festzustellen, ob Pulse Secure Collaboration derzeit aktiv ist. Vielleicht denkt ihr bei einem Blick auf die Suche, was dieser Verweis auf „meetings“ soll? Nun, „Secure Meetings“ ist die ursprüngliche Bezeichnung dieser Appliance-Funktion. Es werden hier nicht alle Meeting-Felder angezeigt, und es sind auch nicht alle erforderlich, um festzustellen, ob Collaboration ausgeführt wird, aber es soll euch zeigen, was bei den Events zu sehen ist.

sourcetype=pulse:connectsecure dest=<IP Address of Pulse devices> meeting_id=*

| table _time src meeting_name meeting_action meeting_bytes_read meeting_bytes_written meeting_client_version meeting_invitee meeting_server meeting_property meeting_property_initial_value meeting_property_new_value meeting_atendee meeting_duration

| sort + _time

Hinweis: Findet den in eurer Umgebung verwendeten Sourcetype und setzt ihn in diesen Beispielsuchen entsprechend ein.

Aktivität von Windows File Share

Wie gesagt solltet ihr auch auf Aktivität von Windows File Share prüfen. Wenn eure PCS-Appliance so konfiguriert ist, dass sie für Syslog-Events das WebTrends Enhanced Log Format (WELF) verwendet, wird diese Aktivität im Feld „proto“ erfasst. Sucht in euren Logs nach dem Folgenden:

proto=fbr (ob Windows File Share aktiv ist)

Als Alternative zur Collaboration-Suche oben könnt ihr auch diese Suche verwenden:

proto=meeting  (ob Pulse Secure Collaboration aktiv ist)

Eine einzige Suche nach beiderlei Aktivitäten sieht dann so aus:

search sourcetype=juniper:ive proto!=auth
| stats values(proto) AS Activity by user

Hinweis: Findet den in eurer Umgebung verwendeten Sourcetype und setzt ihn in diesen Beispielsuchen entsprechend ein.

Wenn eure Appliance jedoch für die Syslog-Formatierung „Standard“ konfiguriert ist, kann PCS die Aktivität anhand eines Message-Codes im Feld „msg“ erkennen. Das Format besteht aus drei Buchstaben, gefolgt von fünf Ziffern (etwa „MTG20035“ oder „FBR20503“). Die folgenden Beispiele extrahieren nur den Drei-Buchstaben-Code, der darauf hinweist, dass die Funktion verwendet wird. „FBR“ bezeichnet Aktivitäten von Windows File Share.

Das sieht dann beispielsweise so aus:

sourcetype="juniper:ive"
| rex field=msg "(?<product>^\w{3})"
| stats values(product) AS Activity by user

Im folgenden Beispiel ersetzen wir den Aktivitätscode inline (was wir ebenso gut durch einen Lookup erreichen könnten):

sourcetype="juniper:ive"
| rex field=msg "(?<product>^\w{3})"
| eval app=case(match(product,"FBR"),"Windows File Browser",match(product,"JAV"),"Java Embedded App",match(product,"MTG"),"Secure Meeting")
| stats values(app) AS Activity by user

Hinweis: Findet den in eurer Umgebung verwendeten Sourcetype und setzt ihn in diesen Beispielsuchen entsprechend ein.

Falls euer Logging URIs umfasst, könnt ihr auch nach Folgendem suchen:

/dana/fb/smb/wfb.cgi for Windows File Share browsing activity

/dana/fb/smb/swsh.cgi   for Windows File Share activity

/dana-na/{meeting_base_URL}/meetingrun.cgi for Pulse Secure Collaboration activity (where {meeting_base_URL} is the administrator-configured base URL for secure meetings)

Je nach Logging-Konfiguration in der PCS-Appliance werden Ereignisse wie die folgenden protokolliert, wenn versucht wird, über Verbindungen auf Dateien auf den Windows-Servern zuzugreifen.

Wenn wir uns einer vertrauten Datenquelle zuwenden, die ihr vielleicht auch verwendet, dem Sicherheitsereignisprotokoll von Windows (Security Event Log), dann bietet die unten abgebildete Suche eine Möglichkeit, Einblick in Dateien zu erhalten, auf die über eine Freigabe direkt von Windows aus zugegriffen wird. Dies kann nützlich sein, wenn die PCS-Appliance selbst dieses Maß an Auflösung nicht bietet.

source="WinEventLog:Security" EventCode=5145 Source_Address=<IP Address of Pulse devices> Share_Name="\\\\*\\C$"

| table _time ComputerName Security_ID Relative_Target_Name Accesses

In ähnlicher Weise wird ein Windows-Event-Code 4625 ausgelöst, wenn versucht wird, ohne die richtigen Berechtigungen auf eine Freigabe zuzugreifen. Aber zurück zu den Pulse-Secure-Logs: Im Beispiel unten tritt der Benutzer „badguy“ erfolgreich bei, wie diesen Events zu entnehmen ist:

Allerdings versucht „badguy“, eine Verbindung zu einer Dateifreigabe herzustellen, und wird abgewiesen. Die folgende Suche gibt Aufschluss darüber, warum er nicht auf die gewünschte Ressource zugreifen konnte. In diesem Beispiel, bei dem LDAP auf dem Windows-Gerät konfiguriert ist, liegt es daran: „User name does not exist“. Mit dieser Suche lässt sich feststellen, warum Anmeldeereignisse, die vom Pulse-Server bzw. den Pulse-Servern stammen, nicht erfolgreich authentifiziert werden.

source="WinEventLog:Security" EventCode=4625  Source_Network_Address=<IP Address of Pulse devices>  

| table  _time EventCode hostname user Source_Network_Address Logon_Process

Warum ist das alles wichtig? Weil es eine weitere potenzielle Erkennung ermöglicht. FireEye schreibt im Blog-Beitrag: „Die böswilligen Operationen von SLOWPULSE können über die Log-Korrelation zwischen den Authentifizierungsservern, die für LDAP- und RADIUS-Authentifizierung zuständig sind, und dem VPN-Server erkannt werden. Authentifizierungsfehler in LDAP- oder RADIUS-Protokollen, während die zugehörigen VPN-Anmeldungen erfolgreich sind, wären ein anormales Ereignis, das es wert ist, gekennzeichnet zu werden.“ Die folgende Suche liefert eine Auflistung von Pulse-Anmeldeereignissen, die mit LDAP verknüpft sind; in unserem Fall verwenden wir Active Directory für LDAP, daher heißt unser Realm AD.

sourcetype=pulse:connectsecure dest= action=success realm=AD
| table _time user
| sort + _time

Ab da könnten wir diese Pulse-Anmeldungen nehmen und nach den fehlgeschlagenen Anmeldeereignissen suchen, Event-Code 4625. Diese Suche steht oben. Die Zeitstempel sollten sehr nahe beieinander liegen, innerhalb von Sekunden.

Hinweis: Findet den in eurer Umgebung verwendeten Sourcetype und setzt ihn in diesen Beispielsuchen entsprechend ein.

Indikatoren einer Kompromittierung

FireEye bzw. Mandiant hat in diversen Blog-Beiträgen Indicators of Compromise (IOC) veröffentlicht, darunter Dateien, Hashes, Webshells und sed-Muster. Ivanti und die CISA haben zusätzliche Indikatoren (darunter weitere Hashes und betroffene URIs) in ihren jeweiligen Beiträgen genannt. Wir haben diese Indikatoren konsolidiert und einfach als CSV abgespeichert, damit ihr sie als Lookup-Tabellen verwenden könnt – und sie hier auf GitHub zur Überprüfung und Verwendung bereitgestellt. Aber was ist eigentlich eine Lookup-Tabelle, und wie hilft sie bei Security-Erkennungen in Splunk? Auch da haben wir für euch vorgesorgt.

Webshells

Viele der in dieser Woche bekannt gewordenen Angriffe resultieren in der Installation von Webshells auf der PCS-Appliance. Wir finden es darum sinnvoll, noch einmal auf dieses klassische YouTube-Video von James Bower über die Suche nach Webshells mit Splunk zu verweisen.

Splunk Enterprise Security

Erkenne dich selbst

Wir haben uns bis hierher dem Angriff und den Maßnahmen zu seiner Aufdeckung gewidmet. Es ist aber darauf hinzuweisen, dass die Grundlagen ebenso wichtig sind. Das elementare Asset Management, hoffentlich mithilfe eures Asset-and-Identity-Frameworks, sagt euch, wo sich die anfälligen Systeme befinden. Regelmäßige Schwachstellenscans, die in Splunk integriert sind, zeigen an, welche Systeme verwundbar sind, und können euch helfen, die Patch-Pläne zu priorisieren und eure Erkennung besser zu fokussieren.

Framework für Bedrohungsdaten

Ihr könnt die oben genannten IOC (für alle, die nicht nach oben scrollen wollen: hier sind sie) auch mit Splunk Enterprise Security nutzen. Das Threat Intelligence Framework kann diese IOC ganz einfach aufnehmen, und Splunk Enterprise Security gibt euch Bescheid, wenn einer der Indikatoren auftritt. Wenn ihr euch nicht sicher seid, wie das geht, lest unseren aktuellen Blog-Beitrag, der euch durch den gesamten Prozess beim Onboarding von IOC in Splunk Enterprise Security führt.

MITRE ATT&CK

Nach Durchsicht der Blog-Posts von FireEye/Mandiant haben wir die Aktivitäten des Angreifers auf MITRE ATT&CK abgebildet. Jede Taktik ist außerdem mit Splunk-Content verknüpft, damit ihr nach diesen Informationen nicht lange suchen müsst. Seid euch bitte dessen bewusst, dass diese Suchen dazu gedacht sind, eure Nachforschungen zu beschleunigen. Wir empfehlen euch, sie über die Splunk Security Essentials App zu konfigurieren. Möglicherweise müsst ihr sie modifizieren, damit sie in eurer Umgebung funktionieren! Viele dieser Suchen sind für die Verwendung mit dem tstats-Befehl optimiert.

Sobald neue Informationen verfügbar sind, werden wir diese Suchläufe aktualisieren, wenn weitere ATT&CK-TTPs bekannt werden.

Here is the full list of all the MITRE ATT&CK TTP’s that FireEye/Mandiant reported as being associated with malware/groups identified in this attack: 

T1003,T1016, T1021.001, T1027, T1036.005, T1048, T1049, T1053, T1057, T1059, T1059.003, T1070, T1070.001, T1070.004, T1071.001, T1082, T1098, T1105,T1111,T1133,T1134.001, T1136,T1140,T1190,T1505.003,T1518,T1554,T1556.004,T1592.004, T1562,T1569.002,T1574, T1600

Fazit

Uns ist bewusst, dass es sich um kritische Schwachstellen handelt, die man als Kunde so schnell wie möglich patchen will. Und dass man feststellen will, ob man selbst von diesem Angriff betroffen ist. Wenn ihr noch nicht gepatcht habt (das haben wir alle schon einmal erlebt), könnt ihr mit diesen Suchen hoffentlich genaueren Einblick in eure Umgebungen und in etwaige Schadaktivitäten gewinnen, die ihr vielleicht gerade erlebt. Falls die Suchen nicht auf Anhieb perfekt funktionieren, betrachtet sie als „SplunkSpiration“ :-). Sobald wir weitere Informationen haben, werden wir diesen Blog aktualisieren. Und falls ihr Hilfe braucht: Die Splunk-Fachleute sind für euch da! Kunden wenden sich am besten an ihren Customer Success Manager, ihren Vertriebskontrakt oder die regionale Vertriebsleitung.

^{*Dieser Artikel wurde aus dem Englischen übersetzt und editiert. Den Originalblogpost findet ihr hier: Monitoring Pulse Connect Secure With Splunk (CISA Emergency Directive 21-03).}