Les experts en sécurité informatique commentent la faille de sécurité log4j pour laquelle le BSI a déclaré le niveau d'alerte rouge. Des experts de Barracuda Networks, Radar Cyber Security et ForeNova dressent un bilan de la situation.
Jonathan Tanner, chercheur principal en sécurité chez Barracuda Networks
Jonathan Tanner, chercheur senior en sécurité chez Barracuda Networks : "Parce que cette vulnérabilité permet l'exécution de code à distance, les risques sont assez élevés." (Image : Barracuda Networks).
Comment les entreprises peuvent-elles identifier cette vulnérabilité dans leur technologie et quels sont les risques si elle n'est pas corrigée ?
"Vous devez d'abord vérifier si une version de log4j antérieure à 2.15.0 est utilisée, également dans les dépendances. Maven et Gradle - deux outils de gestion de build basés sur Java - offrent la possibilité d'imprimer l'intégralité de l'arborescence des dépendances d'un projet. De cette façon, il peut être déterminé si une version vulnérable de log4j est utilisée ou non. Même avec la version 2.15.0 ou ultérieure, assurez-vous que la propriété système formatMsgNoLookups n'est pas définie sur "true".
La seule raison pour laquelle cette version n'est pas vulnérable est qu'elle a défini la valeur par défaut de true à false. Dans certaines versions de log4j, cette propriété peut être facilement définie sur false manuellement pour atténuer la vulnérabilité. Si l'application n'a pas besoin de LDAP dans le cadre de son utilisation légitime, il est également possible de bloquer tout le trafic LDAP avec un pare-feu ou un filtre d'application Web pour empêcher l'accès au code distant en cas d'exploitation de la vulnérabilité.
Cependant, ceux-ci vérifient uniquement si log4j est capable d'exploiter cette vulnérabilité RCE ou non. Qu'un système soit vraiment vulnérable ou non à une attaque est une question beaucoup plus compliquée sans un seul test comme les vulnérabilités comme HeartBleed. Pour exploiter cette vulnérabilité, un attaquant devrait effectuer une attaque par injection de journal. Les trouver est un processus beaucoup plus complexe, mais fondamentalement, tout endroit où l'entrée d'un utilisateur (ou d'un attaquant potentiel) est enregistrée peut être vulnérable à cette attaque.
Donc, pour tester un RCE réel, il faudrait essayer de trouver un moyen de faire une requête LDAP JNDI dans les journaux à partir du contexte utilisateur lui-même (par exemple via le site Web ou l'API si l'application potentiellement affectée est une application Web). Comme cette vulnérabilité permet l'exécution de code à distance, les risques sont assez élevés. Un attaquant pourrait potentiellement pénétrer dans le réseau et essayer d'accéder à des ressources et des données importantes à partir de là.
Quel rôle l'open source a-t-il joué dans cette vulnérabilité et quelles sont les principales considérations de sécurité pour les organisations utilisant des outils comme log4j ?
« Étant donné que log4j est une bibliothèque open source très populaire, le nombre d'applications vulnérables était certainement plus élevé. En général, tout logiciel peut être vulnérable aux attaques, et avec les logiciels open source populaires, il existe souvent un vaste écosystème qui recherche et corrige les menaces de sécurité. Même si les logiciels open source font la une des journaux lorsque des vulnérabilités majeures sont découvertes, cela ne signifie pas qu'ils sont proportionnellement moins sécurisés (en fait, ils sont probablement beaucoup plus sécurisés que le code propriétaire ou les bibliothèques moins populaires). Une large distribution augmente seulement la probabilité que des vulnérabilités soient trouvées, pas nécessairement la probabilité qu'elles existent.
Lorsqu'elles recherchent des bibliothèques open source, les entreprises doivent choisir des projets importants, réputés et bien entretenus comme log4j pour les raisons ci-dessus. Bien sûr, il peut toujours y avoir des vulnérabilités, mais la communauté est plus susceptible de trouver et de corriger ces vulnérabilités, et également de vérifier que le code est exempt de bogues qui pourraient causer des vulnérabilités en premier lieu, que sur des projets plus petits.
Même pour ceux dont les applications ne sont pas vulnérables à CVE-2021-44228, ou qui n'utilisent pas du tout log4j pour la journalisation, cette vulnérabilité est définitivement un signal d'alarme que l'injection de journal est une méthode potentielle que les attaquants pourraient utiliser. Il vaut la peine de vérifier que toutes les entrées utilisateur enregistrées sont correctement filtrées dans chaque application, quel que soit le système de journalisation ou même le langage de programmation utilisé. Alors que d'autres formes d'injection sont beaucoup plus courantes et font l'objet d'un intérêt particulier, l'injection de journaux reste une forme d'attaque par injection et relève donc du Top 10 des vulnérabilités de l'OWASP.
Comment les entreprises peuvent-elles identifier cette vulnérabilité dans leur technologie et quels sont les risques si elle n'est pas corrigée ?
"Vous devez d'abord vérifier si une version de log4j antérieure à 2.15.0 est utilisée, également dans les dépendances. Maven et Gradle - deux outils de gestion de build basés sur Java - offrent la possibilité d'imprimer l'intégralité de l'arborescence des dépendances d'un projet. De cette façon, il peut être déterminé si une version vulnérable de log4j est utilisée ou non. Même avec la version 2.15.0 ou ultérieure, assurez-vous que la propriété système formatMsgNoLookups n'est pas définie sur "true". La seule raison pour laquelle cette version n'est pas vulnérable est qu'elle a défini la valeur par défaut de true à false.
Dans certaines versions de log4j, cette propriété peut être facilement définie sur false manuellement pour atténuer la vulnérabilité. Si l'application n'a pas besoin de LDAP dans le cadre de son utilisation légitime, il est également possible de bloquer tout le trafic LDAP avec un pare-feu ou un filtre d'application Web pour empêcher l'accès au code distant en cas d'exploitation de la vulnérabilité. Cependant, ceux-ci vérifient uniquement si log4j est capable d'exploiter cette vulnérabilité RCE ou non. Qu'un système soit vraiment vulnérable ou non à une attaque est une question beaucoup plus compliquée sans un seul test comme les vulnérabilités comme HeartBleed.
Pour exploiter cette vulnérabilité, un attaquant devrait effectuer une attaque par injection de journal. Les trouver est un processus beaucoup plus complexe, mais fondamentalement, tout endroit où l'entrée d'un utilisateur (ou d'un attaquant potentiel) est enregistrée peut être vulnérable à cette attaque. Donc, pour tester un RCE réel, il faudrait essayer de trouver un moyen de faire une requête LDAP JNDI dans les journaux à partir du contexte utilisateur lui-même (par exemple via le site Web ou l'API si l'application potentiellement affectée est une application Web).
Cette vulnérabilité permettant l'exécution de code à distance, les risques en cas de vulnérabilité sont assez élevés. Un attaquant pourrait potentiellement pénétrer dans le réseau et essayer d'accéder à des ressources et des données importantes à partir de là.
Plus sur Barracuda.com
Lothar Haensler, COO chez Radar Cyber Security
Lothar Hänsler, COO chez Radar Cyber Security : "La vulnérabilité est relativement facile à exploiter, les attaques peuvent être facilement dissimulées." (Image : Radar Cyber Security).
que s'est-il passé de toute façon
« Le week-end dernier, une vulnérabilité dans le module log4j2 d'Apache.org a été découverte et s'est rapidement vu attribuer un score CVSS de 10, le niveau de criticité le plus élevé. Des autorités telles que l'Office fédéral de la sécurité de l'information (BSI) ont rapidement relevé leur évaluation des risques, qui était initialement orange, à rouge.
Qu'est-ce qui rend cette vulnérabilité si spéciale ?
« Les vulnérabilités sont relativement faciles à exploiter, les attaques peuvent être facilement masquées (obfuscation). De plus, les mesures défensives ne sont pas faciles à mettre en place. L'une des raisons à cela est que toutes les stratégies d'atténuation peuvent avoir des risques et des effets secondaires sur les applications affectées par la vulnérabilité. Cependant, les évaluations des groupes d'experts sont très dynamiques, ce qui entraîne également des perspectives différentes sur les stratégies d'atténuation.
Qu'est-ce que Radar Cyber Security a fait exactement?
"Au cours du week-end, nous avons d'abord analysé la situation des données avec une réponse à l'incident, estimé l'impact, utilisé diverses sources d'informations provenant de plates-formes internationales telles que les équipes d'intervention d'urgence informatique (CERT) et conçu une stratégie pour faire face à cette menace. Enfin, lundi matin, nous avons envoyé un avis de sécurité à tous nos clients. Notre Centre de cyberdéfense (CDC) a été mis en mode d'alerte élevée.
Il porte désormais une attention particulière à l'occurrence de la vulnérabilité dans le module log4j2, sans négliger la posture de sécurité globale. Nous avons mis à jour les modules de détection pour vérifier et signaler les exploits de cette vulnérabilité à nos clients. Cela va de la gestion des vulnérabilités aux services SIEM classiques en passant par les outils d'analyse de réseau individuels. En même temps, nous avons commencé une analyse de nos propres systèmes. Après le premier scan chez un premier client, deux incidents critiques ont été identifiés en très peu de temps. D'autres services spécialisés analysent si les clients sont spécifiquement concernés par cette vulnérabilité. Dans les cas extrêmes, les systèmes peuvent devoir être arrêtés.
Plus sur RadarCS.com
Paul Smith, directeur des services professionnels chez ForeNova
Paul Smit, directeur des services professionnels chez ForeNova : "La vulnérabilité zero-day dans log4j est extrêmement dangereuse car elle peut être directement exploitée sans recharger explicitement de code malveillant." (Image : ForeNova).
« La vulnérabilité zero-day dans la bibliothèque Java log4j largement utilisée est extrêmement dangereuse car la vulnérabilité peut être directement exploitée sans recharger explicitement le code malveillant. Cependant, que cela se produise immédiatement ou non ne peut être vu que lorsqu'il est trop tard. Un terminal peut être compromis, mais pas encore à la vue des pirates. À l'heure actuelle, la nécessité pour les petites et moyennes entreprises de considérer la détection et la réponse du réseau et la détection et la réponse des terminaux comme une stratégie de défense complète devient évidente. EDR voit si le malware a été installé et organise la défense sur le terminal.
Voir le passé avec NDR
Avec NDR, vous pouvez également voir rétrospectivement dans les données de journalisation les systèmes auxquels les pirates ont tenté d'accéder depuis l'extérieur. NDR voit également le trafic typique résultant d'une telle tentative d'accès, comme la communication avec les serveurs C2C, l'analyse des ports et le trafic spécifique. NDR permet également le blocage et la segmentation des réseaux ou la mise en quarantaine des systèmes - une mesure qui doit être prise en cas de doute. Une solution NDR comme NovaComand analyse également les données de télémétrie des terminaux. NovaCommand a publié un correctif et mis à jour les règles de détection d'une telle attaque. NovaCommand déclenche également d'autres solutions tierces pour bloquer et segmenter les systèmes et les sections de réseau concernés. »
Plus sur ForeNova.com
Articles liés au sujet