cyberbibs/event-id-263-arbitrary-file-read-on-checkpoint-security-gateway-cve-2024-24919-Schritt-für-Schritt-SOC-Vorfallreaktionsleitfaden für das beliebige Dateilesen (Arbitrary File Read) CVE-2024-24919 auf Check Point-Gateways, der Erkennung, Analyse, Eindämmung und Behebung mit IOCs abdeckt.
CVE-2024-24919 ist eine kritische Zero-Day-Schwachstelle in Check Point Security Gateways, die es nicht authentifizierten entfernten Angreifern ermöglicht, beliebige Dateien von betroffenen Systemen zu lesen. Die im Mai 2024 entdeckte und aktiv ausgenutzte Sicherheitslücke betrifft Geräte mit aktiviertem Remote Access VPN oder Mobile Access Blade. Angreifer können diese Schwachstelle ausnutzen, um auf sensible Dateien wie Passwort-Hashes und SSH-Schlüssel zuzugreifen, was potenziell zu einer vollständigen Systemkompromittierung führen kann. Aufgrund ihres Schweregrads und des Ausnutzungsstatus wird dringend empfohlen, sofort Patches anzuwenden und Gegenmaßnahmen zu ergreifen.
Um den Alarm zu untersuchen und zu beheben, habe ich die folgenden Schritte unternommen:
Diese Schritte werden im Folgenden ausführlich mit Bildern erklärt.
Die Ticket-Warteschlange des Security Operations Centers (SOC) ist eine entscheidende Komponente für die Verwaltung und Reaktion auf Cybersicherheitsvorfälle. Die Gründe dafür sind Incident Tracking und Management, Priorisierung und Triage, Verantwortlichkeit, Berichterstattung, Trendanalyse sowie Compliance und Prüfbereitschaft.
Jedes Ticket in der Warteschlange wird in der Regel einem bestimmten Analysten oder Team zugewiesen, was eine klare Verantwortlichkeit für die Behebung von Vorfällen gewährleistet. Dies fördert einen strukturierten und organisierten Ansatz für das Incident Management. Ich habe den Besitz des Alarms mit der EventID: 263 übernommen.
Nach der Übernahme des Alarms wird dieser automatisch an den Untersuchungskanal gesendet, wo ich einen Fall eröffnen kann, um den Sicherheitsvorfall weiter zu analysieren und darauf zu reagieren. Ich habe einen Fall für den Alarm erstellt und konnte Details des Vorfalls einsehen.
Basierend auf den vom Alarm bereitgestellten Informationen scheint ein verdächtiger Webangriff auf einem Server namens „CP-Spark-Gateway-01“ mit der IP-Adresse 172.16.20.146 erkannt worden zu sein. Der Alarm wird durch die SOC287-Regel für beliebigen Dateilesevorgang auf Checkpoint Security Gateway [CVE-2024-24919] ausgelöst, und die Geräteaktion war zugelassen.
Um diesen Alarm besser zu verstehen, habe ich Open-Source-Intelligence (OSINT) zu dem gemeldeten CVE-2024-24919 und wichtige Informationen zu diesem CVE durchgeführt.
Als Nächstes habe ich eine Bedrohungsanalyse mithilfe der von LetsDefend bereitgestellten Threat-Intelligence-Plattform durchgeführt, die eine umfassende Datenbank zur Katalogisierung bösartig verwendeter Informationen wie IP-Adressen, Domains und anderer Indikatoren für Kompromittierungen (IOCs) unter Verwendung der Quell-IP-Adresse 203.160.68.12 bereitstellt.
Zusätzlich habe ich VirusTotal zur Bedrohungsanalyse derselben IP-Adresse verwendet und festgestellt, dass die Malware von 4 Sicherheitsanbietern als bösartig eingestuft wurde und die Geolokalisierung der IP Hong Kong ist.
Dies bestätigt, dass der Datenverkehr von der IP 203.160.68.12 bösartig ist. Daher ist eine weitere Untersuchung erforderlich, indem ich die Protokolle analysiere, um zu sehen, wie viele Hosts in meinem Netzwerk mit dieser bösartigen IP kommuniziert haben.
Ich begann meine Analyse mit der Untersuchung der Zugriffsprotokolle. Dabei konzentrierte ich mich auf IP-Adressen, User-Agents, Pfade, HTTP-Statuscodes und Zeitstempel, um verdächtige oder bösartige Aktivitäten zu identifizieren.
Bevor ich den HTTP-Verkehr untersuchte, analysierte ich die Payloads, die zur Ausnutzung der relevanten Schwachstelle verwendet wurden. Ich fand diesen öffentlich verfügbaren POC (Proof of Concept), der von [CVE-2024-24919] in diesem GitHub-Repository verwendet wird: https://github.com/seed1337/CVE-2024-24919-POC/blob/main/exploit.py
Als Nächstes ging ich zur Log-Management-Seite und filterte die Protokolle nach der bösartigen Quell-IP-Adresse 203.160.68.12, um zu sehen, wie viele Hosts mit ihr in Kontakt standen. Bei der Suche im Netzwerk stellte ich fest, dass nur der Host namens „CP-Spark-Gateway-01“ mit der IP-Adresse 172.16.20.146 mit der bösartigen IP in Kontakt war.
Die folgenden Protokollinformationen zeigen, dass die bösartige IP-Adresse 203.160.68.12 die POST-Methode verwendete, um die bösartige Payload „aCSHELL/../../../../../../../../../../etc/shadow“ zu senden – die versucht, die sensible Datei /etc/shadow durch Directory Traversal auf dem Host „CP-Spark-Gateway-01“ mit der IP-Adresse 172.16.20.146 am 06.06.2024 zu lesen.
Die Datei /etc/shadow ist eine kritische Datei in Unix/Linux-basierten Betriebssystemen, die gehashte Passwörter und Kontoverfallsdetails für Benutzerkonten speichert. Daher kann ich schlussfolgern, dass der Angreifer versucht, Benutzeranmeldeinformationen zu stehlen, und dass die Anfrage mit dem Statuscode 200 gewährt wurde, wie im obigen Protokoll zu sehen ist.
Dies beweist weiter, dass der Angriff bösartig ist.
Die Eindämmung spielt eine zentrale Rolle in der Cybersicherheit, indem sie die Auswirkungen von Sicherheitsvorfällen begrenzt, Daten und Betriebsabläufe schützt, eine effektive Incident Response ermöglicht, Beweise für forensische Analysen bewahrt und die Einhaltung gesetzlicher und regulatorischer Anforderungen sicherstellt.
Da ich erkannt habe, dass das Gerät kompromittiert ist, habe ich das Gerät „CP-Spark-Gateway-01“ mit der IP-Adresse 172.16.20.146 isoliert, um weitere Schäden zu verhindern.
Die Behebung ist ein grundlegender Bestandteil einer robusten Cybersicherheitsstrategie. Sie umfasst die Behebung von Schwachstellen und die Adressierung von Sicherheitsproblemen, um Ausnutzung zu verhindern, Daten zu schützen, den Betrieb aufrechtzuerhalten und Vorschriften einzuhalten, was letztendlich zu einer sichereren und widerstandsfähigeren Organisation beiträgt. Um die künftige Wiederholung zu beheben und zu verhindern, sollten die folgenden Schritte unternommen werden:
Nach Abschluss der Analyse habe ich meine Ergebnisse im Abschnitt „Analyst Note“ dokumentiert und Artefakte & IOCs gemeldet.
Nach Abschluss meiner Untersuchung kam ich zu dem Schluss, dass der Alarm ein echter Positivbefund ist. Ich habe eine Abschlussnotiz verfasst, in der ich die Ursache des Alarms, die von mir zur Analyse des Alarms unternommenen Schritte, das Ergebnis der Analysen, die zur Behebung des Alarms ergriffenen Maßnahmen erläuterte und den Alarm erfolgreich geschlossen habe.
