Dark background with blue code overlay
Blog

Recommandations Akamai pour l'atténuation des risques de Log4j

Akamai blue wave

Written by

Aparna Rayasam, SVP & GM Application Security, Akamai

December 16, 2021

log4j.png

Synthèse

Une vulnérabilité critique d'exécution de code à distance (CVE-2021-44228) a été signalée publiquement dans Log4j, un outil de journalisation open source largement utilisé dans les applications, notamment par de nombreuses grandes entreprises. 

Cette vulnérabilité permet aux auteurs de menaces d'exécuter du code malveillant et d'exfiltrer les informations des systèmes des applications qui utilisent la bibliothèque en manipulant les messages de journal. Il existe déjà des rapports de serveurs effectuant des analyses Internet dans le cadre de tentatives de localisation de serveurs vulnérables, et nos équipes d'informations sur les menaces constatent un nombre alarmant de tentatives d'exploitation de cette vulnérabilité. Log4j est incorporée dans de nombreuses structures populaires et dans de nombreuses applications Java, ce qui rend son impact très large.

La suite de sécurité étendue d'Akamai, comprenant les solutions de sécurité des applications et des API, Enterprise Threat Protector et Guardicore Segmentation, est en bonne voie pour permettre de résoudre cette vulnérabilité de différentes manières. Il est fortement recommandé aux organisations de mettre à jour Log4j vers sa dernière version 2.16.0. En raison du développement rapide de cette vulnérabilité, les équipes d'Akamai continueront à développer et à déployer des mesures d'atténuation pour soutenir nos clients. 

Qu'est-ce que la vulnérabilité Log4j ?

Le 9 décembre 2021, une vulnérabilité critique impliquant l'exécution de code à distance non authentifié et l'exfiltration de données (CVE-2021-44228) a été signalée dans Log4j, générant l'inquiétude compte tenu de la façon dont la fonction de journalisation open source est utilisée. Cette utilisation généralisée, combinée à la facilité d'exploitation, rend son impact particulièrement important. Actuellement, la vulnérabilité est activement exploitée et les équipes de sécurité du monde entier recherchent des solutions pour en atténuer les risques.

Une machine compromise permet à un auteur de menace d'exfiltrer des données et donne accès à distance à des logiciels qu'exécute Log4j. Cela permet ensuite à un attaquant d'exécuter des commandes arbitraires sur un serveur, d'exposer des informations et des secrets, mais également de transformer ce serveur afin de pouvoir mener des attaques supplémentaires, potentiellement contre des machines sécurisées à l'intérieur d'un réseau sans accès direct à Internet.

Les développeurs Java utilisent largement Log4j afin de faciliter la journalisation des erreurs et des informations de débogage. Par conséquent, les fournisseurs de produits dont le logiciel est basé sur Java peuvent être vulnérables. Même si une application n'utilise pas directement Log4j, de nombreuses structures et de nombreux outils communs utilisent Log4j en interne et peuvent donc introduire cette vulnérabilité dans la pile d'applications.  

Quelle est la gravité de la vulnérabilité Log4j ?

Bien qu'Akamai ait observé des tentatives d'exploitation de la vulnérabilité Log4j pour la première fois le 9 décembre, nous constatons que de plus en plus de preuves indiquent que ces tentatives pourraient durer depuis des mois. Depuis la signalisation de la vulnérabilité, nous avons constaté plusieurs variantes d'exploitation à un taux soutenu de trafic d'attaque d'environ 2 millions de tentatives par heure. La vitesse d'évolution des variantes est sans précédent. 

Plus de la moitié (~57 %) des attaques observées jusqu'à présent proviennent d'attaquants précédemment classés comme des acteurs malveillants dans la base de données d'informations sur les menaces d'Akamai. En raison du volume considérable de systèmes non corrigés, nous prévoyons encore des tentatives d'exploitation pendant les mois à venir. Les équipes d'Akamai chargées de la recherche sur la sécurité et de la réponse aux incidents continuent de surveiller et de protéger notre infrastructure et nos clients en tirant parti de notre visibilité et de notre expérience uniques.

Bien qu'en cas de vulnérabilité, la mesure la plus importante à prendre soit de corriger les systèmes infectés, les chercheurs en sécurité ont conscience que cela prend du temps. Dans de nombreux cas, les entreprises peuvent même ne pas encore être capables de déterminer quels systèmes sont vulnérables. Par conséquent, des mesures d'atténuation supplémentaires doivent être déployées afin de réduire au maximum la surface de menace.

Pour y contribuer, Akamai propose un certain nombre de recommandations. À l'heure actuelle, la plus grande quantité de trafic d'attaque associée à Log4j est basée sur des applications Web. Par conséquent, la mesure la plus importante que les entreprises peuvent prendre après l'application de correctifs est d'exploiter les protections des applications Web et des API d'Akamai. Lisez la suite pour savoir comment procéder au sein de votre entreprise à mesure que les vecteurs d'attaque évoluent. 

Atténuer les abus Log4j grâce à la suite de protection des applications et des API d'Akamai

Akamai continue de mettre à jour les règles de Web Application Firewall (WAF) afin de garantir une protection contre cette exploitation et ses nombreuses variantes. Cela inclut la mise à jour de la règle 3000014 dans l'ensemble de règles Kona et Adaptive Security Engine d'Akamai. Pour les clients qui utilisent les groupes d'attaque automatisés, nous avons mis à jour le groupe Injection de commande. Tous les clients qui ont actuellement ces règles ou groupes d'attaque activés en mode DENY recevront une protection automatique en ligne pour les moteurs et versions de protection suivants :

  • ensemble de règles Kona, toute version datée du 29 octobre 2019 ou ultérieure ;

  • groupes d'attaque automatisés, toutes les versions ;

  • Adaptive Security Engine, toutes les versions.

De nombreux serveurs, en particulier ceux qui se trouvent dans des environnements à haut risque comme ceux qui sont directement accessibles sur Internet, peuvent déjà avoir été compromis. Pour identifier les indicateurs d'infection, la commande suivante peut montrer les tentatives d'exploitation :

sudo egrep -i -r '\$\{jndi:(ldap[s]?|rmi|dns)://' /var/log

Pour en savoir plus sur les protections des applications Web et des API d'Akamai, lisez la suite ou contactez-nous.

Bien que les protections WAF puissent être très efficaces pour les serveurs Web à ce stade, les entreprises doivent également envisager d'autres sources d'attaque qui pourraient être à l'origine de l'infection. À cette fin, nous recommandons d'utiliser la microsegmentation afin de mieux visualiser l'exposition potentielle et ainsi réduire le risque et la propagation. 

Détecter les abus Log4j grâce à Enterprise Threat Protector

Les chercheurs d'Akamai chargés des menaces ont examiné les données DNS, proxy et de gouffre des clients à la recherche d'un comportement anormal lié aux acteurs qui tentent d'exploiter la vulnérabilité Log4j. Dans les données DNS, nous avons été surpris de constater des requêtes DNS pour les domaines contenant la chaîne « jndi:ldap ». Il s'agit de requêtes DNS non valides qui contiennent des caractères non valides dans le nom de domaine et qui ne seront donc pas résolues. De plus, nous avons constaté un trafic vers des domaines malveillants connus redirigés vers des serveurs gouffre ; ces domaines hébergent du code Java malveillant utilisé pour attaquer des serveurs vulnérables. Tous ces éléments sont des signes d'abus potentiel au sein des réseaux de clients. 

Atténuer les abus Log4j grâce à Akamai Guardicore Segmentation

Les clients qui utilisent Akamai Guardicore Segmentation peuvent tirer parti de sa visibilité au niveau des processus afin d'identifier les applications vulnérables et les risques de sécurité dans l'environnement. Ces éléments peuvent ensuite être utilisés pour mettre en place un contrôle précis du trafic réseau afin d'intercepter les attaques sur les systèmes vulnérables, sans perturber les opérations normales des entreprises.

Les éléments menacés : identifiez les processus Java vulnérables et les abus Log4j

Pour se protéger contre les abus éventuels de Log4j, il est essentiel d'identifier dans un premier temps les processus potentiellement exploitables. Pour ce faire, cela nécessite une visibilité approfondie du trafic réseau au niveau du processus, garantie par Akamai Guardicore Segmentation. Une visibilité précise des connexions et du trafic Internet nous permet de voir clairement quelles mesures d'atténuation doivent être prises afin de ne pas perturber les opérations de l'entreprise. 

Intercepter l'attaque : bloquez les indicateurs d'infection (IoC) malveillants et les vecteurs d'attaque

Une fois les applications vulnérables identifiées, il est impératif de pouvoir agir. Tout en appliquant les correctifs nécessaires, Akamai Guardicore Segmentation offre une multitude d'options visant à alerter, intercepter et prévenir les attaques. Une solution avec un contrôle détaillé et précis des communications et du trafic réseau est essentielle pour bloquer ou isoler précisément les vecteurs d'attaque tout en évitant de perturber au maximum les fonctions normales de l'entreprise. En voici quelques exemples :

  • blocage automatique des indicateurs d'infection grâce à Threat Intelligence Firewall (TIFW) et à la sécurité DNS ;

  • mise en quarantaine des serveurs compromis ;

  • blocage du trafic entrant et sortant vers les ressources vulnérables ;

  • blocage du trafic sortant des applications Java vers Internet.

Enfin, les clients Guardicore Hunt peuvent compter sur une équipe de chercheurs en sécurité dédiée à la surveillance et à l'analyse continues de leur environnement qui leur communiquera immédiatement les alertes relatives aux risques de sécurité et aux mesures d'atténuation suggérées.  

Pour en savoir plus sur Akamai Guardicore Segmentation, lisez la suite ou contactez-nous.

Conclusion

À mesure que nous surveillerons et analyserons de près les exploitations de Log4j, Akamai continuera de partager ses idées et de fournir des mises à jour en temps voulu de nos protections et de nos capacités.



Akamai blue wave

Written by

Aparna Rayasam, SVP & GM Application Security, Akamai

December 16, 2021