Pleins feux sur les menaces : Attaques par injection de journaux
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 journaux présente un risque bien souvent négligé.
L'injection de journaux peut avoir des conséquences nombreuses, et parmi elles : l'exécution de code à distance. C'est le principe de la vulnérabilité CVE-2021-44228, également connue sous le nom d'attaque « log4shell » contre les versions log4j antérieures à 2.16.0.
Menaces particulièrement importantes
Injection journaux Log4j RCE : si une application utilisant une version vulnérable de log4j ajoute au journal une chaîne spécialement conçue, la bibliothèque vulnérable peut être incitée à exécuter un code fourni par un pirate. Compte tenu de la grande popularité de log4j pour les applications Java et de la possibilité d'exécuter du code arbitraire, Apache a attribué à cette vulnérabilité le degré de gravité le plus élevé possible lors de sa divulgation. De nombreuses grandes entreprises ont été touchées.
Les détails
La journalisation est un composant essentiel de la plupart des applications et des systèmes, car elle permet aux développeurs et aux administrateurs système de vérifier que les logiciels fonctionnent correctement et d'identifier des détails plus spécifiques en cas de dysfonctionnement. Cependant, le risque présenté par l'injection de journaux ne se limite pas à l'application et/ou au système concerné, car les journaux sont souvent traités par d'autres logiciels, qui peuvent également être vulnérables aux tentatives d'injection. Les attaques par injection des journaux peuvent viser tout système qui écrit dans ces journaux ou en consulte le contenu. Même un utilisateur lisant simplement ces journaux peut en être la cible. Parmi les attaques potentielles par injection de journaux figurent la falsification de journaux, le déni de service et l'injection de chaînes malveillantes, qui représente encore plusieurs attaques potentielles.
La falsification de journaux consiste à créer une charge utile qui ajoutera au journal une ligne d'apparence légitime, mais pourtant fausse. Cette technique peut être utilisée pour tromper les systèmes d'analyse des journaux, ainsi que les personnes qui les consultent manuellement (ou via des systèmes d'événements), en leur faisant croire qu'un événement s'est produit, ou pour fausser les analyses portant sur la fréquence d'un événement particulier. Dans les attaques par déni de service, le pirate inonde le fichier journal avec de grandes quantités de données qui peuvent entraîner une insuffisance de mémoire ou d'espace disque, ou la suppression prématurée des entrées par le système de journalisation, pour les journaux qui conservent uniquement un sous-ensemble de fichiers. Ces deux types d'attaques par injection de journaux n'impliquent pas d'exploiter un langage de programmation ou un moteur de modèle particulier.
L'injection de chaînes malveillantes peut se présenter sous de nombreuses formes et charges utiles, y compris l'exécution de code à distance dans le cas de la récente vulnérabilité log4j. Ces chaînes peuvent exploiter les fonctionnalités intégrées de l'enregistreur ou de tout logiciel lisant les journaux. log4shell exploite un aspect de la substitution de chaîne, en particulier une fonctionnalité qui autorise la recherche et la substitution de variables dans la sortie du journal à l'aide du langage d'expression de log4j. Si un logiciel permettant d'afficher ou traiter les journaux utilise un moteur de modèles, l'injection de modèles peut se faire en utilisant la syntaxe de ce moteur. Si les journaux sont affichés dans un navigateur Web, il est également possible d'injecter du code dans le langage de programmation utilisé par le service Web. Par exemple, le pirate peut injecter du code PHP à exécuter lorsque les journaux seront présentés à un utilisateur. Une attaque peut également écrire dans le journal un code JavaScript qui sera rendu et exécuté lorsque l'utilisateur consultera les entrées du journal dans une application web. On parle alors d'attaque de cross-site scripting stocké, ou script de site à site.
Bien que les attaques par injection présentent différents résultats et risques (dont les fuites de données), l'exécution de code à distance en est l'un des aspects les plus critiques. Un pirate peut exécuter dans une application du code qu'il fait passer pour authentique, obtenant ainsi l'accès et les autorisations associées. Il peut alors accéder aux fichiers accessibles à l'application, aux bases de données avec lesquelles l'application communique, ou même au système hôte par le biais d'un reverse shell. L'accès aux fichiers et aux bases de données peut entraîner des violations de données, tandis qu'un shell peut constituer un point d'entrée pour un pirate cherchant à pénétrer plus profondément dans un réseau et à compromettre des systèmes et des ressources auxquels l'application n'a même pas accès. On comprend aisément pourquoi l'attaque log4shell représente une telle menace pour la sécurité des données et du réseau.
Nous recommandons aussi aux chargés de maintenance de se pencher sur les risques associés à la mise à disposition d'un trop grand nombre de fonctionnalités qui peuvent potentiellement conduire à de graves vulnérabilités telles que log4shell. Heureusement, la fonctionnalité permettant d'activer cette exécution de code à distance a été supprimée dans la version 2.16.0.
Se protéger contre ces types d'attaques
La meilleure façon de se protéger contre Log4Shell spécifiquement est d'installer la dernière version de Log4j. Tenir ses logiciels et bibliothèques à jour permet de s'assurer que les vulnérabilités sont rapidement corrigées. Puisque log4j peut être inclus dans une application sans en être une dépendance directe, vous pouvez utiliser le système de génération pour obtenir une arborescence des dépendances et vérifier la présence des versions vulnérables de log4j en tant que dépendances indirectes. Maven et Gradle incluent des outils de ligne de commande permettant d'imprimer les arborescences des dépendances d'un projet.
Si la mise à niveau demande du temps, une solution provisoire peut consister à utiliser un firewall pour réseau ou pour application web, elle offrira un certain niveau de protection. Un firewall réseau peut être configuré pour bloquer le trafic LDAP sortant qui résulterait d'une exploitation de cette vulnérabilité. Un Web Application Firewall serait en mesure de prévenir l'attaque en question s'il offrait une protection contre l'injection de modèles. Les solutions Barracuda Web Application Firewall et WAF-as-a-Service vous protègent contre les injections de modèles et de journaux, dont celles liées à log4shell. Cependant, ces mesures ne vous protègent que contre cette menace spécifique et non pas les injections de journaux en général.
Étudier les systèmes qui peuvent traiter les journaux et les vulnérabilités qu'ils peuvent présenter vous aidera à évaluer les risques liés à la journalisation, ainsi que les mesures correctives potentielles en cas de menaces futures liées à la journalisation proposées par les équipes de développement et de sécurité. Comme ce type d'attaque peut affecter tout système qui consulte les journaux, connaître les systèmes qui lisent ou traitent ces derniers vous aidera à comprendre les risques spécifiques associés. Ainsi, les équipes de sécurité et de développement pourront identifier les aspects spécifiques de la journalisation qui nécessitent une attention particulière.
Rapport :La sécurité des applications : état des lieux en 2021
