par Bhabesh Raj, Associate Security Analyst Engineer et Kennet Harpsøe, Senior Cyber Analyst
L’exploit Log4Shell est sérieux : en effet, il est difficile à détecter, est utilisé dans de très nombreux logiciels et constitue le moyen idéal pour introduire des malwares dans votre réseau. Il n’existe pas un seul cyber-outil qui puisse protéger votre entreprise contre Log4Shell.
Une combinaison d’outils et une stratégie de défense en profondeur donneront aux entreprises la possibilité de détecter les activités post-compromission et de mettre un terme à l’attaque.
Vous avez été pris pour cible : quelle est la prochaine étape ?
Le 9 décembre 2021, Apache a révélé une vulnérabilité critique d’exécution de code à distance (CVE-2021-44228), également connue sous le nom de Log4Shell, qui affecte les versions 2.0-2.14.1 d’Apache Log4j. Log4j est une bibliothèque de logging populaire en Java et est utilisée dans plusieurs applications d’entreprise, notamment Apache Struts, Flume, Kafka, Flink, Tomcat, Solr et VMware vCenter. En raison de la prévalence de Log4j, les défenseurs se sont efforcés d’identifier quelles applications déployées avaient été affectées. Les tentatives d’exploitation de cette vulnérabilité sont particulièrement difficiles à détecter car toute chaîne pouvant être loggée par log4j pourrait déclencher cette vulnérabilité, qu’il s’agisse de chaînes de type « user-agent » ou de lignes d’objet d’emails. L’exploit pourrait même être déclenché dans un deuxième temps seulement, par exemple, par un système SIEM vulnérable susceptible de stocker ultérieurement les logs à l’aide de log4j.
La surface IT de la plupart des entreprises modernes est vaste et complexe. Il est impossible de stopper ou même de détecter toutes les activités malveillantes à la périphérie d’une organisation, et certaines s’infiltreront inévitablement en passant entre les mailles du filet. Les équipes de sécurité responsables de vastes systèmes informatiques doivent prendre en compte d’éventuelles violations lors de la gestion de la sécurité. Il est clair qu’il y aura des malwares dans votre système, quelque part, à un moment donné. L’ampleur et le caractère évasif de Log4Shell illustrent parfaitement ce dernier point. Ainsi, tous les managers doivent se demander s’ils seront en mesure de détecter de potentiels attaquants en train d’utiliser, ou non, le malware pour pénétrer dans leurs systèmes. Une stratégie de défense en profondeur est la meilleure façon de répondre à une telle menace.
La défense en profondeur est souvent analysée à travers le prisme de la Cyber Kill Chain de Lockheed-Martin ou du framework Mitre ATT&CK, qui partent tous deux du principe que toute cyberattaque réussie doit passer par une série d’étapes conceptuellement bien définies. Dans le cas de Log4Shell, les attaquants peuvent utiliser celui-ci pour mettre en place un accès initial et installer des malwares comme Cobalt Strike. Cet accès initial se fera très probablement via une machine connecté à Internet comme par exemple un serveur Web Apache HTTP. Les prochaines étapes après cet accès initial sont la persistance et le mouvement latéral. À l’aide d’une stratégie de défense en profondeur, les responsables de la sécurité sont à même de se demander dans quelle mesure il leur sera possible de détecter ce type d’activités. Par exemple, il peut être judicieux de détecter la persistance avec des agents hôtes qui feront des rapports au SIEM et de repérer un mouvement latéral avec un système de détection réseau qui enverra également des rapports au SIEM afin d’établir un référentiel pour savoir quelles machines communiquent avec quelles autres machines. De cette façon, les équipes de sécurité ont la possibilité de découvrir un serveur Web Apache qui agit en tant que client vis à vis d’un hôte joint au domaine (Domain-Joined Host) et qui lui serait adossé, ce qui compte tenu de la nature même de Log4Shell serait très suspect. En d’autres termes, il est important de consacrer du temps et de l’argent à la mise en place d’un logging concernant ce que vous voulez et non de ce que vous avez.
Avec une stratégie de défense en profondeur et une approche en matière de logging bien pensée, les responsables de la sécurité peuvent étendre les capacités de sécurité avec des logiciels supplémentaires, tels que l’UEBA (User and Entity Behavior Analytics), qui est un logiciel basé sur l’apprentissage automatique (ML) pouvant générer automatiquement des références comme mentionnées dans l’exemple ci-dessus. Les équipes peuvent également utiliser des solutions SOAR (Security Orchestration, Automation and Response) pour lancer automatiquement une action afin de réduire le temps de réponse et aider à réduire l’impact d’une attaque, par exemple en coupant automatiquement la connexion entre le serveur Web Apache et l’hôte de domaine. Le SOAR peut également notifier un analyste après l’action de réponse, en fournissant à ce dernier les informations pertinentes pour investiguer le serveur Web et évaluer si la connexion doit être rétablie ou non.
Toutes les alertes LogPoint sont mappées avec le framework MITRE ATT&CK, qui aide les analystes en sécurité à comprendre la posture de sécurité actuelle en priorisant les alertes.
Que savons-nous de Log4Shell ?
Chen Zhaojun de la Cloud Security Team d’Alibaba a signalé CVE-2021-44228 (CVSS 10 sur 10) aux développeurs Log4j le 24 novembre dernier, conduisant ainsi Apache à publier un correctif le 6 décembre. Un exploit PoC a été rendu public le 10 décembre. Le CEO de Cloudflare a déclaré que la première preuve d’exploitation qu’ils avaient trouvée à ce jour datait du 1er décembre, suggérant ainsi que la vulnérabilité était déjà présente sur le terrain au moins 9 jours avant d’avoir été divulguée publiquement.
Fait intéressant, Log4Shell utilise le vecteur d’attaque JNDI qui a été précédemment présenté au BlackHat USA 2016. L’exploitation de la vulnérabilité permet à un attaquant distant d’exécuter du code sur l’application si celui-ci parvient à logger la valeur de chaîne fournie par l’attaquant au niveau du lookup du serveur LDAP JNDI de ce dernier. Pour déclencher la vulnérabilité, un attaquant doit inclure une chaîne particulière dans ses requêtes, comme dans les user agents, que sera loggée par l’application utilisant la bibliothèque Log4j vulnérable. Le serveur envoie alors une requête à l’adresse de l’attaquant via JNDI. Le serveur de l’attaquant, tel que LDAP, répond en envoyant un chemin vers un fichier de classe Java distant qui est injecté dans le processus du serveur vulnérable et exécute le code de la charge virale. De plus, les administrateurs doivent être conscients que les acteurs malveillants peuvent récupérer et ont effectivement mis la main sur des données secrètes à partir de variables d’environnement, comme les clés secrètes AWS, pour compromettre le Cloud.
Deutsche Telekom CERT a signalé des tentatives d’exploitation provenant du réseau Tor. Le 10 décembre, Imperva a révélé avoir observé plus de 1,4 million d’attaques ciblant CVE-2021-44228 avec des pics atteignant environ 280 000 attaques par heure. Cloudflare a également signalé avoir bloqué un pic de 20 000 demandes d’exploitation par minute, avec environ 200 à 400 adresses IP semblant être activement analysées à un moment donné.
Les principaux éditeurs comme Cisco, VMware, SonicWall, Okta et RedHat investiguent les produits concernés. LogPoint conseille aux administrateurs de vérifier régulièrement les alertes au fur et à mesure qu’elles seront mises à jour par les éditeurs concernés. Pendant ce temps, les administrateurs peuvent utiliser des jetons Canary pour tester la présence de la vulnérabilité Log4Shell dans leurs applications.
Microsoft a observé des attaquants diffusant des balises Cobalt Strike en exploitant Log4Shell. L’expert en sécurité Markus Neis a tweeté qu’en dehors des cryptomineurs, il a pu observer Muhstik et Mirai être utilisés en tant que charges virales dans le cadre d’une potentielle exploitation de Log4Shell. Les administrateurs peuvent consulter les charges virales base64 publiées par GreyNoise à titre de référence pour savoir à quoi ressemblerait l’exploitation de Log4Shell sur le terrain.
Les évaluations initiales montrent que les produits LogPoint ne sont pas affectés par cette vulnérabilité. Nous mettrons à jour cet article sur notre blog, si nécessaire, en fonction de l’évolution de nos évaluations.
Détection de l’exploitation de Log4Shell
Les administrateurs peuvent utiliser la règle sigma de Florian Roth pour détecter les tentatives d’exploitation génériques à partir des logs du serveur Web.
(user_agent IN ['*${jndi:ldap:/*', '*${jndi:rmi:/*', '*${jndi:ldaps:/*', '*${jndi:dns:/*', '*/$%7bjndi:*', '*%
24%7bjndi:*', '*$%7Bjndi:*', '*%2524%257Bjndi*', '*%2F%252524%25257Bjndi%3A*', '*${jndi:${lower:*', '*${::-
j}${*', '*${jndi:nis*', '*${jndi:nds*', '*${jndi:corba*', '*${jndi:iiop*', '*${${env:BARFOO:-j}*', '*${::-l}${::
-d}${::-a}${::-p}*', '*${base64:JHtqbmRp*']
OR url IN ['*${jndi:ldap:/*', '*${jndi:rmi:/*', '*${jndi:ldaps:/*', '*${jndi:dns:/*', '*/$%7bjndi:*', '*%24%
7bjndi:*', '*$%7Bjndi:*', '*%2524%257Bjndi*', '*%2F%252524%25257Bjndi%3A*', '*${jndi:${lower:*', '*${::-j}${*',
'*${jndi:nis*', '*${jndi:nds*', '*${jndi:corba*', '*${jndi:iiop*', '*${${env:BARFOO:-j}*', '*${::-l}${::-d}${::-
a}${::-p}*', '*${base64:JHtqbmRp*']
OR referer IN ['*${jndi:ldap:/*', '*${jndi:rmi:/*', '*${jndi:ldaps:/*', '*${jndi:dns:/*', '*/$%7bjndi:*', '*%24%
7bjndi:*', '*$%7Bjndi:*', '*%2524%257Bjndi*', '*%2F%252524%25257Bjndi%3A*', '*${jndi:${lower:*', '*${::-j}${*',
'*${jndi:nis*', '*${jndi:nds*', '*${jndi:corba*', '*${jndi:iiop*', '*${${env:BARFOO:-j}*', '*${::-l}${::-d}${::-
a}${::-p}*', '*${base64:JHtqbmRp*'])"
Recherche de tentatives d’exploitation génériques dans les logs du serveur web
Les adversaires utilisent principalement le champ de l’agent utilisateur (user-agent) pour exploiter Log4Shell. Cependant, les administrateurs doivent noter que les schémas de vulnérabilité peuvent être déclenchés par la présence de ces derniers dans n’importe quelle chaîne loggée par log4j. La requête doit être ajustée en conséquence. De plus, il existe de nombreuses permutations pour contourner la signature que les administrateurs doivent garder à l’esprit lorsqu’ils utilisent la détection.
Les ET Labs ont publié des signatures pour Log4Shell que les administrateurs peuvent déployer sur leur IDS/IPS.
norm_id IN ["Snort", "SuricataIDS"] message="*CVE-2021-44228*"Plusieurs éditeurs ont publié des IoC concernant Log4Shell que les administrateurs peuvent utiliser pour faciliter leur détection.
(source_address IN LOG4SHELL_IPS OR destination_address IN LOG4SHELL_IPS)Soulignons que nous pouvons faire de même en utilisant les IoC de NetLab pour Mirai et Muhstik.
(domain IN ["nazi.uy", "log.exposedbotnets.ru"] OR query IN ["nazi.uy", "log.exposedbotnets.ru"]
OR url IN ["http://62.210.130.250/lh.sh", "http://62.210.130.250:80/web/admin/x86_64", "http://62.210.130.250:80
/web/admin/x86", "http://62.210.130.250:80/web/admin/x86_g", "http://45.130.229.168:9999/Exploit.class",
"http://18.228.7.109/.log/log", "http://18.228.7.109/.log/pty1;", "http://18.228.7.109/.log/pty2;", "http://18.
228.7.109/.log/pty3;", "http://18.228.7.109/.log/pty4;", "http://18.228.7.109/.log/pty5;", "http://210.
141.105.67:80/wp-content/themes/twentythirteen/m8", "http://159.89.182.117/wp-content/themes/twentyseventeen
/ldm"])Importance de la détection des activités post-compromis
Dans le paysage actuel des menaces, il ne suffit pas pour les défenseurs des entreprises d’être uniquement réactifs et de s’appuyer sur les données de Threat-Intelligence et les détections. Les défenseurs doivent être proactifs en recherchant toute activité suspecte dans leur environnement. Même si les défenseurs ne parviennent pas à détecter l’exploitation initiale, ils pourront quasiment toujours détecter les attaquants grâce à leurs activités post-compromis. Pour commencer, les administrateurs peuvent rechercher toute utilisation des outils courants des acteurs malveillants, tels que Cobalt Strike, Tor et PsExec, et procéder, s’ils sont détectés, à l’évaluation de l’intégralité de la kill chain.
LogPoint propose plusieurs articles de blog qui expliquent comment détecter les outils courants des acteurs malveillants :
- Microsoft a révélé que certains attaquants avaient déployé des charges virales Cobalt Strike après avoir exploité Log4Shell, les administrateurs doivent donc vérifier que leurs détections Cobalt Strike soient bien à jour.
- Les acteurs malveillants utilisent Tor pour préserver l’anonymat et masquer leur trafic réseau, il est donc important de vérifier l’utilisation de Tor dans votre entreprise.
- Les acteurs malveillants déploient des cryptomineurs afin de pouvoir générer des gains financiers, comme celui signalé par NetLab, les entreprises doivent donc partir à la chasse au cryptomining.
Les attaquants adorent configurer un accès SSH de type backdoor (porte dérobée) au niveau du système en ajoutant leur clé publique au fichier authorised_keys. Les administrateurs peuvent utiliser auditd pour surveiller et repérer d’éventuelles modifications au niveau du fichier enabled_keys de leurs serveurs.
norm_id=Unix "process"=audit event_type=SYSCALL command=bash key="ssh_key_monitor"Le botnet Muhstik peut mettre en place des backdoors et, comme mentionné précédemment, ce dernier reste l’un des rares botnets à avoir exploité Log4Shell.
Enfin, nous pouvons rechercher toute activité de serveur anormale, comme l’exécution de processus inhabituels, tels que curl et wget. Les administrateurs doivent noter qu’une liste d’autorisation peut être requise en fonction de l’environnement.
norm_id=Unix "process"=audit event_type=PROCTITLE command IN ["*curl*", "*wget*", "*chmod 777*", "*chmod +x*"]Nous nous devons d’insister sur l’importance d’une stratégie de défense en profondeur correctement mise en œuvre, qui pourra aider à détecter les menaces qui auront réussi à pénétrer au sein de l’entreprise et pour lesquelles la détection initiale n’est pas parvenue à se déclencher.
La défense en profondeur est la clé de la sécurité de l’entreprise
Il est important de noter que la vulnérabilité Log4Shell est simple à détecter mais beaucoup moins à exploiter, car la réussite de l’exploitation dépend de plusieurs facteurs tels que la version JVM et la configuration utilisée. Néanmoins, les entreprises utilisant des applications vulnérables doivent partir du principe qu’elles seront potentiellement ciblées et doivent donc être en mesure d’analyser facilement les logs d’applications à la recherche d’artefacts compromis. Les administrateurs doivent rechercher tout trafic réseau sortant suspect provenant de leurs applications vulnérables.
La défense en profondeur reste la meilleure stratégie possible pour détecter l’exploitation de Log4Shell. Une activité d’analyse à grande échelle a déjà commencé avec des cryptomineurs et des botnets qui se joignent déjà à la fête. Ce n’est qu’une question de temps pour que des affiliés de ransomwares ne prennent eux aussi le train en marche. Les défenseurs des entreprises doivent rester vigilants et ne doivent pas se fier à une seule et unique méthode de détection pour repérer l’exploitation de cette vulnérabilité critique. Enfin, nous insistons pour rappeler aux administrateurs de vérifier fréquemment les alertes des éditeurs en matière de mises à jour concernant la mitigation et l’état des correctifs des produits vulnérables qui auront été déployés au sein de leur entreprise.
