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 de sa divulgation. De nombreuses entreprises de renom ont ainsi été affectées par cette vulnérabilité.

Les détails

La journalisation est un élément 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 le logiciel fonctionne correctement et d’identifier des détails plus spécifiques lorsqu’il ne fonctionne pas. L’injection de logs n’est cependant pas seulement un risque pour l’application et/ou le système lui-même, car il est assez courant que les journaux soient traités par d’autres logiciels, qui peuvent également être vulnérables aux tentatives d’injection de logs. En fait, tout ce qui écrit ou lit dans les fichiers journaux peut être la cible d’attaques par injection de logs. Même une personne lisant les logs pourrait être la cible de certaines de ces attaques. Les attaques possibles par injection de logs comprennent la falsification de logs, le déni de service et l’injection de chaînes de caractères malveillantes - qui comporte elle-même plusieurs attaques possibles.

La falsification de logs consiste à créer une charge utile qui ajoutera au log une ligne d’apparence légitime, mais pourtant fausse : cette technique peut être utilisée pour tromper les systèmes d’analyse des logs, 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 log 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 logs ne conservant uniquement qu’un sous-ensemble de fichiers. Ces deux types d’attaques par injection de logs 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 log à l’aide du langage d’expression de log4j. Si un logiciel permettant d’afficher ou traiter les logs utilise un moteur de modèles, l’injection de modèles peut se faire en utilisant la syntaxe de ce moteur. Si les logs 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 logs seront présentés à un utilisateur. Une attaque peut également écrire dans le log un code JavaScript qui sera rendu et exécuté lorsque l’utilisateur consultera les entrées du log 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és. 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. Offrir trop de fonctionnalités qui pourraient potentiellement conduire à de graves vulnérabilités telles que log4shell pourrait également être un sujet sur lequel les mainteneurs devraient se pencher. Étant donné que la fonctionnalité permettant ce RCE a été supprimée dans la version 2.16.0, il semble que les mainteneurs de log4j aient déjà réalisé ce point.

Comment se protéger contre log4shell

La meilleure façon de se protéger contre log4shell est d’effectuer une mise à niveau vers au moins la version 2.15.0 de log4j, et idéalement vers la version 2.16.0 ou supérieure, afin d’éviter ce RCE spécifique. Puisque log4j peut être inclus dans une application sans être une dépendance directe, le système de construction peut probablement être utilisé pour obtenir un arbre de dépendance afin de vérifier la ou les versions vulnérables de log4j comme dépendances indirectes. Maven et Gradle comprennent tous deux des outils en ligne de commande permettant d’imprimer les arbres de dépendance d’un projet. Dans les versions de log4j au moins égales à 2.10.0 et inférieures à 2.15.0, la fonctionnalité désactivée par défaut dans 2.15.0 peut être désactivée manuellement en ajoutant l’indicateur "-Dlog4j2.formatMsgNoLookups=true" lors de l’exécution de l’application à l’aide de la commande java. Si la version 2.15.x est utilisée, il faut vérifier que cet indicateur n’a pas été remplacé par false dans l’application ou la commande, car cela réactiverait la fonctionnalité vulnérable.
Un pare-feu - qu’il s’agisse d’un réseau ou d’une application Web - peut éventuellement être en mesure de bloquer tout trafic LDAP sortant comme solution provisoire si la mise à niveau nécessite du temps pour être planifiée et exécutée. Ces mesures ne protègent toutefois que contre cette menace spécifique, et non contre l’injection de logs en général. Le Web Application Firewall et le WAF-as-a-Service de Barracuda protègent contre les tentatives d’injection de logs, y compris celles liées à log4shell.

Toute application utilisant la journalisation - même si elle n’utilise pas log4j ou même Java - devrait être vérifiée, pour d’éventuelles attaques par injection de log et pour des pratiques appropriées d’assainissement des données en rapport avec les utilisations spécifiques des logs, chaque fois qu’une entrée externe fournie par l’utilisateur est enregistrée. Cela permettra d’atténuer toute autre vulnérabilité future liée à l’injection de logs qui pourrait exister. La désinfection peut être moins simple que la simple prise en compte des capacités de l’application et du système de journalisation, car tout ce qui est lu dans les logs peut introduire d’autres vulnérabilités, potentiellement différentes. De même, il faut tenir compte de ce qui est consigné en premier lieu. Par exemple, un nom d’utilisateur ou une adresse électronique est un cas beaucoup moins valable pour autoriser toute sorte de caractères spéciaux qui pourraient rendre possibles des attaques par injection que les en-têtes de requête, qui pourraient nécessiter certains de ces caractères.

Si l’on considère les systèmes qui traitent les logs et les vulnérabilités qu’ils peuvent présenter, on peut faire une bonne évaluation des risques que la journalisation peut présenter. Cela pourrait aider une organisation à comprendre l’impact potentiel des attaques par injection de logs sans avoir à connaître tous les endroits où elles pourraient se produire. Comme l’injection de logs peut affecter tout système qui lit les logs, le suivi des systèmes qui lisent ou traitent les logs peut aider à comprendre les risques spécifiques qui pourraient être associés à la journalisation. Pour les équipes de sécurité et de développement, cela peut aider à déterminer quels langages de programmation, de modèles ou d’expression spécifiques doivent être pris en compte pour déterminer ce qui est consigné et qu’un attaquant peut contrôler.