cyberbibs/event-id-263-arbitrary-file-read-on-checkpoint-security-gateway-cve-2024-24919-Procédure pas à pas de réponse aux incidents SOC pour la lecture arbitraire de fichiers CVE-2024-24919 sur les passerelles Check Point, couvrant la détection, l'analyse, le confinement et la remédiation avec des IOC.
CVE-2024-24919 est une vulnérabilité zero-day critique dans les Check Point Security Gateways qui permet à des attaquants distants non authentifiés de lire des fichiers arbitraires sur les systèmes concernés. Découverte en mai 2024 et activement exploitée dans la nature, cette faille cible les appareils avec Remote Access VPN ou Mobile Access Blade activés. Les attaquants peuvent exploiter cette vulnérabilité pour accéder à des fichiers sensibles tels que les hashs de mots de passe et les clés SSH, ce qui peut potentiellement conduire à un compromis complet du système. En raison de sa gravité et de son statut d'exploitation, un correctif et une atténuation immédiats sont fortement recommandés.
Pour enquêter sur l'alerte et y remédier, j'ai suivi les étapes suivantes ;
Ces étapes sont expliquées en détail ci-dessous avec des images.
La file d'attente des tickets du Security Operations Center (SOC) est un composant essentiel pour gérer et répondre aux incidents de cybersécurité. Les raisons sont le suivi et la gestion des incidents, la priorisation et le triage, la responsabilisation, le reporting, l'analyse des tendances, ainsi que la conformité et la préparation aux audits.
Chaque ticket de la file est généralement attribué à un analyste ou à une équipe spécifique, garantissant une responsabilité claire pour la résolution de l'incident. Cela favorise une approche structurée et organisée de la gestion des incidents. J'ai pris en charge l'alerte avec l'EventID : 263
Après avoir pris en charge l'alerte, celle-ci est automatiquement envoyée dans le canal d'investigation, où je peux créer un dossier (case) pour analyser et répondre plus en détail à l'incident de sécurité. J'ai créé un dossier pour l'alerte et j'ai pu consulter les détails de l'incident.
Sur la base des informations fournies par l'alerte, il semble qu'une attaque Web suspecte ait été détectée sur un serveur nommé « CP-Spark-Gateway-01 » avec l'adresse IP 172.16.20.146. L'alerte est déclenchée par la règle SOC287 pour Lecture arbitraire de fichiers sur Checkpoint Security Gateway [CVE-2024–24919] et l'action sur l'appareil a été autorisée.
Pour mieux comprendre cette alerte, j'ai effectué des recherches OSINT (Open-Source Intelligence) concernant le CVE-2024–24919 signalé et les informations importantes relatives à ce CVE.
Ensuite, j'ai effectué une veille sur les menaces à l'aide de la plateforme de threat intelligence fournie par LetsDefend, qui propose une base de données complète dédiée au catalogage des informations à usage malveillant, telles que les adresses IP, les domaines et d'autres indicateurs de compromission, en utilisant l'adresse IP source 203.160.68.12.
De plus, j'ai utilisé VirusTotal pour la threat intelligence sur la même adresse IP et j'ai observé que l'adresse IP a été signalée pour activités malveillantes par 4 éditeurs de sécurité et que la géolocalisation de l'IP est Hong Kong.
Cela confirme que le trafic provenant de l'IP 203.160.68.12 est malveillant. Par conséquent, je dois poursuivre l'investigation en analysant les journaux pour voir combien d'hôtes de mon réseau ont eu une communication avec cette IP malveillante.
J'ai commencé mon analyse en examinant les journaux d'accès. Je me suis concentré sur les adresses IP, les user-agents, les chemins, les codes de statut HTTP et les horodatages afin d'identifier toute activité suspecte ou malveillante.
Avant d'examiner le trafic HTTP, j'ai étudié les payloads utilisés pour exploiter la vulnérabilité concernée. J'ai trouvé ce POC (Proof of Concept) disponible publiquement, utilisé par [CVE-2024–24919], dans ce dépôt GitHub https://github.com/seed1337/CVE-2024-24919-POC/blob/main/exploit.py
Ensuite, je me suis rendu sur la page de gestion des journaux et j'ai filtré les journaux par l'adresse IP source malveillante 203.160.68.12 pour voir combien d'hôtes ont été en contact avec elle. Après avoir effectué une recherche dans le réseau, j'ai découvert que seul l'hôte nommé « CP-Spark-Gateway-01 » avec l'adresse IP 172.16.20.146 a été en contact avec l'IP malveillante.
Les informations de journal ci-dessous montrent que l'adresse IP malveillante 172.16.20.146 a utilisé la méthode POST pour envoyer le payload malveillant aCSHELL/../../../../../../../../../../etc/shadow — qui tente de lire le fichier sensible /etc/shadow via un directory traversal sur l'hôte « CP-Spark-Gateway-01 » avec l'adresse IP 172.16.20.146 le 06/juin/2024.
Le fichier /etc/shadow est un fichier critique des systèmes d'exploitation basés sur Unix/Linux qui stocke les mots de passe hachés et les détails d'expiration des comptes utilisateur. Par conséquent, je peux conclure que l'attaquant tente de voler les identifiants utilisateur et que la requête a été accordée avec un code de statut 200, comme constaté dans le journal ci-dessus.
Cela prouve en outre que l'attaque est malveillante.
Le confinement joue un rôle central en cybersécurité en limitant l'impact des incidents de sécurité, en protégeant les données et les opérations, en facilitant une réponse efficace aux incidents, en préservant les preuves pour l'analyse forensique et en garantissant la conformité aux exigences légales et réglementaires.
Ayant détecté que l'appareil est compromis, j'ai procédé à l'isolation de l'appareil « CP-Spark-Gateway-01 » avec l'adresse IP 172.16.20.146 afin de prévenir d'autres dommages.
La remédiation est un élément fondamental d'une stratégie de cybersécurité robuste. Elle consiste à corriger les vulnérabilités et à traiter les problèmes de sécurité afin de prévenir l'exploitation, de protéger les données, de maintenir les opérations et de se conformer aux réglementations, contribuant en fin de compte à une organisation plus sécurisée et plus résiliente. Pour remédier à la vulnérabilité et prévenir toute récidive future, les mesures suivantes doivent être prises ;
Après avoir terminé l'analyse, j'ai documenté mes conclusions dans la section « Analyst Note », et j'ai rapporté les artefacts et IOCs
Après avoir conclu mon investigation, j'ai déterminé que l'alerte est un vrai positif. J'ai rédigé une note de clôture expliquant la cause de l'alerte, les étapes que j'ai suivies pour analyser l'alerte, le résultat des analyses, les mesures prises pour remédier à l'alerte et clôturer l'alerte avec succès.
