Le directeur du CISA, Jen Easterly dit que la faille de sécurité de Log4j est la pire qu'elle ait vue dans sa carrer et les les professionnels de la sécurité feront face aux conséquences d'erreur pendant une longue période.
S'il n'est pas corrigé la principale faille de sécurité découverte il y a un mois dans la bibliothèque de journalisation Java Apache Log4j présente des risques pour de vastes secteurs de l'Internet, les pirates pourraient exploiter la vulnérabilité de logiciels largement utilisés pour détourner des serveurs informatiques, mettant tout, de l'électronique grand public aux systèmes gouvernementaux et d'entreprise, en danger d'une cyberattaque.
Le 9 décembre, il a été découvert une vulnérabilité dans la bibliothèque de journaux Apache log4j. Cette bibliothèque est largement utilisée dans les projets de développement d'applications Java / J2EE, ainsi que par les fournisseurs de solutions logicielles standard basées sur Java / J2EE.
Log4j inclut un mécanisme de recherche qui pourrait être utilisé pour interroger via une syntaxe spéciale dans une chaîne de format. Par défaut, toutes les requêtes sont faites avec le préfixe java : comp/env/*; cependant, les auteurs ont implémenté l'option d'utiliser un préfixe personnalisé en utilisant un symbole deux-points dans la clé. C'est là que réside la vulnérabilité : si jndi : ldap : // est utilisé comme clé, la requête va au serveur LDAP spécifié. D'autres protocoles de communication tels que LDAPS, DNS et RMI peuvent également être utilisés.
Par conséquent, un serveur distant contrôlé par un attaquant pourrait renvoyer un objet vers un serveur vulnérable, ce qui pourrait conduire à l'exécution de code arbitraire sur le système ou à une fuite de données confidentielles. Il suffit à un attaquant d'envoyer une chaîne spéciale via le mécanisme qui écrit cette chaîne dans un fichier journal et est donc gérée par la bibliothèque Log4j.
Cela peut être fait avec de simples requêtes HTTP, par exemple celles envoyées via des formulaires Web, des champs de données, etc., ou avec tout autre type d'interactions utilisant le registre côté serveur.
- La version 2.15.0 n'a pas résolu un autre problème, CVE-2021-45046, qui permettait à un attaquant distant de contrôler le Thread Context Map (MDC) pour préparer une entrée malveillante à l'aide d'un modèle de recherche JNDI. Le résultat pourrait être l'exécution de code à distance, heureusement pas dans tous les environnements.
- La version 2.16.0 a résolu ce problème. Mais cela n'a pas corrigé CVE-2021-45105, qu'Apache Software Foundation décrit comme suit :
« Apache Log2.0j1 versions 2.16.0-alpha4 à 2 n'a pas protégé contre la répétition incontrôlée des recherches autoréférentielles. Lorsque la configuration du registre utilise une disposition de modèle différente de celle par défaut avec une recherche de contexte (par exemple, $$ {ctx: loginId}), les attaquants contrôlant les données d'entrée de Thread Context Map (MDC) peuvent créer des données de connexion. . , qui génère une StackOverflowError qui mettra fin au processus. Ceci est également connu sous le nom d'attaque par déni de service (DOS).
Le programme de bug bounty indépendant du fournisseur, Zero Day Initiative, a décrit la faille comme suit :
« Lorsqu'une variable imbriquée est remplacée par la classe StrSubstitutor, elle appelle récursivement la classe de substitution (). Cependant, lorsque la variable imbriquée fait référence à la variable à remplacer, la récursivité est appelée avec la même chaîne. Cela conduit à une récursivité infinie et à une condition DoS sur le serveur ».
Un autre bogue critique d'exécution de code à distance désormais suivi comme CVE-2021-44832 a été découvert dans la même bibliothèque de journaux Apache Log4j. Il s'agit de la quatrième vulnérabilité de la bibliothèque Log4j.
Classée « modérée » en gravité avec un score de 6,6 sur l'échelle CVSS, la vulnérabilité provient de l'absence de contrôles supplémentaires sur l'accès JDNI dans log4j.
L'équipe de sécurité Apache a publié une autre version d'Apache Log4J (version 2.17.1) qui corrige le bogue d'exécution de code à distance récemment découvert CVE-2021-44832. C'est une autre mauvaise situation pour la plupart des utilisateurs, mais encore une fois, il est fortement recommandé de mettre à jour votre système pour résoudre ce problème critique.
Aucune agence fédérale américaine n'a été compromise en raison de la vulnérabilité, a déclaré Jen Easterly aux journalistes lors d'un appel. De plus, aucune cyberattaque majeure liée au bogue n'a été signalée aux États-Unis, bien que de nombreuses attaques ne soient pas signalées, a-t-il déclaré.
Easterly a déclaré que l'étendue de la vulnérabilité, affectant des dizaines de millions d'appareils connectés à Internet, en fait le pire qu'il ait jamais vu dans sa carrière. Les attaquants peuvent attendre leur heure, a-t-il déclaré, attendant que les entreprises et autres baissent leurs défenses avant d'attaquer.
"Nous espérons que Log4Shell sera utilisé pour des intrusions à l'avenir", a déclaré Easterly. Il a noté que la violation de données d'Equifax en 2017, qui a compromis les informations personnelles de près de 150 millions d'Américains, était due à une vulnérabilité dans un logiciel open source.
Jusqu'à présent, la plupart des tentatives d'exploitation du bogue se sont concentrées sur l'extraction de crypto-monnaie de bas niveau ou sur des tentatives d'attirer des appareils dans des botnets, a-t-il déclaré.
source: https://www.cnet.com
C'est à cause de la sur-ingénierie. Chaque composant ne doit faire qu'une seule chose et la faire bien. Mais les développeurs ont la mauvaise habitude de placer des calques et des calques et des fonctionnalités inutiles, ce qui ne le rend pas plus complexe et sujet à ce type de panne.. J'ai dit..