“Log4shell” : retour sur les “Log injection attacks”

Les attaques par injection figurent toujours dans les 10 principales vulnérabilités des applications Web identifiées par l’OWASP. Bien que les attaques par injection SQL, injection de commandes et cross-site scripting (XSS) soient parmi les attaques par injection les plus courantes, l’injection de logs présente un risque bien souvent négligé. Possible lorsque des entrées contrôlées par l’utilisateur sont enregistrées sans assainissement, l’injection de logs peut avoir un certain nombre de conséquences, notamment l’exécution de code à distance (RCE). C’était notamment le cas avec l’attaque CVE-2021-44228, alias “log4shell”, récemment divulguée, contre les versions de log4j antérieures à la 2.15.0 ou les attaques qui ont remplacé la propriété formatMsgNoLookups par défaut dans les versions 2.15.x avant que la fonctionnalité ne soit complètement supprimée dans les versions 2.16.0 et supérieures. Menace mise en évidence En supposant qu’un hacker puisse réussir une attaque par injection de logs, une substitution de chaîne spécialement conçue qui effectue une recherche LDAP à l’aide de JNDI peut être utilisée pour exécuter du code chargé depuis un serveur LDAP distant contrôlé par l’assaillant. Compte tenu de la popularité de log4j pour les applications Java ainsi que de la possibilité d’exécuter du code arbitraire, Apache a attribué à cette vulnérabilité le degré de gravité le plus élevé possible lors …