• Perspective
Publié le 28 janvier 2022

Présentation vulnérabilité Log4Shell

Un nouveau risque cyber a été découvert par les équipes d’Alibaba Cloud Security le 24/11. Ce qui a mené depuis le 10/12 à un grand nombre d’attaques recensé après que l’exploit ait été publié sur GitHub. Cette faille CVSS de criticité 10 a été annoncée sous le nom Log4Shell (CVE-2021-44228).

La vulnérabilité concerne la bibliothèque Apache Log4j, un package omniprésent sur Java pour des millions d’applications. Au travers de cet article, vous retrouverez une présentation de la librairie concernée, les impacts potentiels sur votre SI et les méthodes d’exploitation de la vulnérabilité, ainsi que les remédiations pour s’en prémunir.

1. Log4j?

Apache Log4j est une bibliothèque de journalisation performante, distribuée par l'Apache Foundation à travers un projet GitHub Open-source. C’est à dire maintenue à jour par quelques membres qui utilisent leur temps-libre pour développer des applications libres et pour lesquelles on n'est pas obligé de payer.

L’utilitaire Log4j est utilisé dans d’indénombrables programmes, comme l’a souligné Sean Gallagher, chercheur senior sur les menaces chez Sophos : “Log4j est une bibliothèque Java qui est utilisée par de nombreux produits. Elle est spécialisée dans la journalisation d’évènement pour des applications. Elle peut donc être présente dans les recoins les plus sombres de l’infrastructure d’une organisation, par exemple, tout logiciel développé en interne. Les systèmes vulnérables à cause de Log4Shell devraient être une priorité pour la sécurité informatique.”

2. Les vulnérabilités liées à Log4j

La vulnérabilité Zéro-Day, surnommée Log4Shell de par son exploitation possible, a rapidement été publiée sous la nomenclature CVE-2021-44228.

Comme indiqué dans le rapport de l’équipe de chercheurs en cyber sécurité LunaSec, cette vulnérabilité premièrement trouvée à travers un serveur (multijoueur) du jeu vidéo Minecraft, peut toucher n’importe qui utilisant la bibliothèque Log4j et ses packages (Log4j-core, Log4j-api, etc.) entre la version 2.0-beta9 et la version 2.14.1, ce qui donne une portée d’attaque d’autant plus importante.

Un second article publié par LunaSec décrit les marches à suivre pour vérifier si un système est vulnérable (https://www.lunasec.io/docs/blog/Log4j-zero-day-mitigation-guide/).

Le score CVSS a classé la vulnérabilité Log4Shell à 10, comme une vulnérabilité “critique”. La criticité réside dans les axes suivants :

· L’exploit de Log4j est facile à mettre en œuvre. Un développeur novice est en mesure de le réaliser.

· La surface d’attaque.

· Utilisation en mode non authentifié.

L’ampleur est si grande que des services Cloud très populaires tels que Steam ou Apple iCloud seraient potentiellement touchés. Il est important de savoir que même sans utiliser directement la librairie Log4j, on peut se retrouver face à la vulnérabilité, car plusieurs Framework tels qu'Apache Struts, Druid, ElasticSeach, Kafka peuvent dépendre de Java et ses bibliothèques, et sont probablement touchés par cette vulnérabilité. Par mesure de sécurité, certains préfèrent mettre le site hors ligne, c'est notamment le cas au Québec où près de 4 000 sites et services gouvernementaux ont été mis hors ligne par sécurité.

Le degré d’impact de l’attaquant est défini par les privilèges associés aux systèmes ou services corrompus. Avec des droits d’utilisateur complets un attaquant bénéficiera d’un RCE (Remote Control Execution), il aurait la liberté d’installer des programmes, afficher, ou même supprimer des données. À contrario, la corruption de systèmes ayant moins de droit réduit l’impact de l’attaquant.

De plus, un utilisateur a publié sur GitHub un PoC complet, et mis à jour depuis la publication de la vulnérabilité (https://github.com/tangxiaofeng7/CVE-2021-44228-Apache-Log4j-Rce), ce qui rend l’exploitation de cette Log4Shell totalement publique et accessible à tous.

Type de vulnérabilité : Injection (JNDI Lookup

1. Scan pour identifier les systèmes vulnérables

2. Injection des données malveillantes à travers le composant JNDI

3. Chargement du code malveillant dans le système vulnérable

4. Compromission du système vulnérable et réaliser des actions malveillantes : cryptojacking, installation Ransomware, construire un réseau Botnet

 

Voici les mesures à appliquer par rapport à chaque étape de ce chemin :

Etape 1 : Réduire la verbosité des applications exposées sur Internet

® Prendre contact avec les éditeurs de mes solutions applicatives pour vérifier s'ils sont exposés à cette vulnérabilité et si un correctif est disponible.

Etape 2 : La mise en place de filtres au niveau de vos firewalls applicatifs (WAF) pour bloquer les tentatives d'exploitation

® Privilégier le patch management avec la version 2.16.0

Etape 3 : Filtrer et de journaliser les flux sortants des serveurs pour les limiter aux seuls flux autorisés vers des services de confiance (Durcissement réseaux)

Etape 4 : Améliorer la détection en réalisant une analyse approfondie des journaux réseau (Journaux HTTP, DNS, …)

5. Remédiation Log4Shell

Les professionnels de la cyber sécurité ainsi qu’Apache invitent à mettre à jour rapidement leur bibliothèque vers la version 2.16.0 lorsque cela est possible.

Si les équipes techniques n’ont pas la possibilité de le faire, plusieurs autres solutions de remédiations sont disponibles pour mitiger la vulnérabilité :

1. Entre les versions 2.10.0 et 2.15 :

· Modifier le paramètre de configuration Log4j2.formatMsgNoLookups à la valeur TRUE.

ou

· Supprimer la classe JndiLookup dans le paramètre classpath pour éliminer le vecteur principal d'attaque (les chercheurs n'excluent pas l'existence d'un autre vecteur d'attaque).

2. Pour les versions antérieures à 2.10.0 : modifier le format des évènements à journaliser avec la syntaxe %m{nolookups} pour les données qui seraient fournies par l'utilisateur.

Ces options manuelles de remédiation ci-dessus, peuvent potentiellement impacter les SOC (Security Operations Center) des entreprises car les SIEM utilisent cette bibliothèque de plus le nouveau formatage des logs entraînent des dysfonctionnements de Parsing des évènements.

Il existe aussi des solutions qui permettront de peaufiner votre sécurité :

1. Mettre à jour les IP blacklist de vos systèmes de défense en se basant sur :

· La Threat Intelligence des constructeurs

· Les adresses IP des différentes sources malveillantes connues à date

2. Mettre à jour les équipements de sécurité (F5, Fortigate ...) avec les nouvelles règles prédéfinies par les constructeurs en se basant sur les IOC de la vulnérabilité.

Cette vulnérabilité met en lumière la dépendance des entreprises et éditeurs de logiciels vis-à-vis des projets Libres. Les contributeurs de cette librairie Log4j peuvent ne pas être rémunérées pour ces projets et leur support et réactivité ne dépendent que de leur propre implication.

(Source xkcd)

6. Accompagnement EVABSSI

Chez EvaBSSI, nous mettons le Risque Cyber comme une de nos priorités pour accompagner la Performance du SI de nos clients. Le Diagnostic Cyber est un ensemble de tests de sécurité techniques et fonctionnels ayant pour objectifs de :

· Évaluer la maturité en sécurité globale

· Analyser les risques des actifs audités

· Proposer un plan d’actions afin de mitiger les risques identifiés

L’audit consiste à mesurer et analyser les risques suivant 8 domaines de sécurité :

Avec cette démarche, nous vous accompagnons pour créer une vision 360 de votre SI et vous aider à renforcer sa sécurité.

Thomas BOUVET, Othmane ERRAJI, Kevin FLORO, Mehdi SADOUN

Sources

https://blog.cloudflare.com/how-cloudflare-security-responded-to-Log4j2-vulnerability/ https://www.cert.ssi.gouv.fr/alerte/CERTFR-2021-ALE-022/

https://nvd.nist.gov/vuln/detail/CVE-2021-44228

https://en.wikipedia.org/wiki/Java_logging_framework https://en.wikipedia.org/wiki/Log4j https://logging.apache.org/Log4j/2.x/index.html https://www.jmdoudoux.fr/java/dej/chap-jndi.htm https://cyberwatch.fr/cve/cve-2021-44228-log4shell-comment-detecter-et-corriger-cette-vulnerabilite-sur-Log4j/

https://logging.apache.org/Log4j/2.x/manual/lookups.html https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592 https://www.lunasec.io/docs/blog/Log4j-zero-day) https://www.cert.ssi.gouv.fr/alerte/CERTFR-2021-ALE-022/ https://nakedsecurity.sophos.com/2021/12/13/log4shell-explained-how-it-works-why-you-need-to-know-and-how-to-fix-it/

https://support.f5.com/csp/article/K19026212 https://www.truesec.com/hub/blog/apache-log4j-injection-vulnerability-cve-2021-44228-impact-and-response https://www.cadosecurity.com/analysis-of-initial-in-the-wild-attacks-exploiting-log4shell-log4j-cve-2021-44228

Article rédigé par
Tristan Loret