Comment atténuer correctement les vulnérabilités de Log4j

La communauté de la sécurité informatique a travaillé dur la semaine dernière pour enquêter sur une vulnérabilité importante et facile à exploiter dans un élément Java extrêmement populaire appelé Log4j qui est présent dans d’innombrables applications et éléments.

Étant donné que la faille a été initialement divulguée et que les agresseurs ont commencé à l’exploiter, les scientifiques de la sécurité ont découvert des problèmes de sécurité supplémentaires dans Log4j et différentes manières de contourner certaines des mesures d’atténuation proposées, laissant les groupes de sécurité se précipiter sur les moyens appropriés de protéger leurs applications, serveurs et réseaux.

Mise à niveau du composant concerné vers la dernière variation– actuellement 2.16.0 pour Java 8 et plus récent et 2.12.2 pour Java 7 et plus ancien (pas encore lancé)- – est la meilleure méthode pour pallier les deux failles identifiées jusqu’à présent : CVE-2021-44228, également appelée Log4Shell, qui provoque l’exécution de code à distance, et CVE-2021-45046, qui peut déclencher une condition de déni de service.

La correction immédiate n’est pas pratique dans tous les scénarios. Les produits emballés de fournisseurs tiers peuvent contenir des variations sensibles de la bibliothèque de journalisation populaire que les utilisateurs ne peuvent pas personnaliser sans mettre à jour l’ensemble de l’article, ils dépendent donc des fournisseurs pour publier les mises à jour.

Servez les serveurs et applications vitaux peuvent ne pas avoir la possibilité de redémarrer instantanément ou les applications peuvent s’exécuter dans des conteneurs pour lesquels de toutes nouvelles images de conteneurs doivent être créées. Comme pour beaucoup de vulnérabilités, les atténuations alternatives sont vraiment bénéfiques pour les groupes de sécurité, mais il est très important de comprendre leurs limites et le faux sentiment de sécurité que certaines d’entre elles peuvent induire.

Éliminer le Classe JndiLookup

Cette vulnérabilité est déclenchée par la façon dont Log4j utilise une fonction Java appelée JNDI (Java Naming and Directory User Interface) qui a été développée pour permettre le chargement d’éléments Java supplémentaires pendant l’exécution. JNDI peut être utilisé pour charger de tels éléments à partir de services d’appel à distance via de nombreuses procédures.

L’original utilise LDAP (Light-weight Directory Gain Access To Procedure), qui est le plus courant, mais d’autres sont également pris en charge : DNS (Domain Name System), RMI (Remote Technique Invocation ), NDS (Novell Directory Services), NIS (Network Info Service) et CORBA (Common Object Demand Broker Architecture).

Une méthode pour corriger la vulnérabilité consiste à désactiver à l’aide des recherches de messages JNDI, ce qui est ce que Log4j 2.16.0 le fait. Cela peut également être réalisé en extrayant essentiellement toute la classe JndiLookup, qui implémente cette performance, à partir d’un bundle Log4j affecté. Étant donné que les éléments Java sont essentiellement des archives ZIP, les administrateurs peuvent exécuter la commande suivante pour modifier et corriger une instance de package vulnérable :

zip -q -d log4j-core-*. jar org/apache/logging/ log4j/core/lookup/ JndiLookup.class

Hotpatching à l’aide d’un représentant Java

Hotpatching est la procédure de déployer un correctif sur un processus en cours d’exécution sans avoir besoin de le redémarrer. Java prend en charge la modification à la volée du byte-code qui s’exécute actuellement dans une machine virtuelle Java (JVM) via une API d’instrumentation et des agents Java. Un représentant Java est essentiellement un fichier CONTAINER (Java Archive) qui peut être connecté dynamiquement à une JVM pendant l’exécution.

En réaction aux vulnérabilités Log4j, le groupe Corretto d’Amazon Web Services (AWS) a développé un Java représentant qui essaie de repérer la méthode lookup() de toutes les instances org.apache.logging.log4j.core.lookup.JndiLookup empaquetées pour renvoyer la chaîne « Patched JndiLookup:: lookup() » au lieu de se connecter à un serveur distant.

L’agent est proposé sur GitHub et peut également être déployé en tant que conteneur éphémère sur un pod Kubernetes existant pour repérer les applications qui s’exécutent actuellement dans d’autres conteneurs. Les conteneurs éphémères sont pris en charge dans Kubernetes v1.16 et versions ultérieures.

Exploiter le défaut lui-même pour empêcher brièvement l’exploitation

Il est possible de tirer parti de la vulnérabilité elle-même sur les serveurs concernés pour garantir des modifications au système et à l’application en direct qui éviteraient une exploitation ultérieure. Les scientifiques de la société de sécurité Cybereason ont établi une telle immunisation et les scientifiques de LunaSec l’ont encore plus améliorée et l’ont hébergée sur un serveur en direct en tant que service public.

Un cas d’utilisation pour quelque chose comme ça sont tous ces troisièmes -des produits de fournisseurs tiers (applications packagées, appareils et appareils enracinés) qui n’ont pas encore d’emplacements disponibles ou des éléments vulnérables qui ont en fait atteint la fin de leur vie et ne recevront jamais de mise à jour officielle. L’utilisation de l’utilisation contre elle-même peut être un service possible à court terme.

Il est important de comprendre que l’utilisation de cette méthode comporte quelques mises en garde importantes. Premièrement, la réparation est à court terme car les modifications apportées par l’exploit s’appliquent au processus Java en cours d’exécution et seront annulées au redémarrage de la JVM. Cela indique que la vaccination doit être réappliquée si le serveur est redémarré.

Deuxièmement, bien que l’approche ait été vérifiée sur diverses configurations et systèmes, il est possible qu’elle ne s’occupe pas de tous et entraîne des plantages sur certains. La récupération d’un plantage peut impliquer un redémarrage du serveur, ce n’est donc pas un excellent concept de l’exécuter sur des systèmes cruciaux où les temps d’arrêt ne sont pas une option.

Enfin, en utilisant ceci par rapport à des serveurs dont vous n’êtes pas propriétaire et vous ne contrôlez pas est le plus susceptible d’être illégal car il exploite la vulnérabilité, malgré le fait que ce soit à des fins non malveillantes.

Reconnaître les systèmes vulnérables

Avant qu’une méthode de réaction ne soit établie et que l’un des chemins d’atténuation mentionnés ci-dessus puisse être utilisé, les organisations doivent tout d’abord identifier toutes les applications et tous les systèmes dont elles disposent qui pourraient être vulnérables aux exploits de Log4j. Ce n’est pas facile à faire, étant donné que chaque application peut regrouper sa propre instance de Log4j et peut également la remplir dynamiquement dans le cadre d’une autre dépendance tierce.

De nombreuses listes d’avis des fournisseurs Log4Shell sont maintenues par le quartier de sécurité et les CERT, mais ils sont très probablement insuffisants.

Jusqu’à ce que les dépenses en matériaux des applications logicielles (SBOM) finissent par être largement adoptées par les concepteurs d’applications logicielles, les groupes de sécurité seront confrontés à la tâche longue et sujette aux erreurs de reconnaître les systèmes impactés dans leurs organisations en réaction à chaque nouvelle vulnérabilité. Il est probable que davantage de chercheurs et d’opposants commenceront à rechercher des failles dans d’autres parties couramment utilisées à la suite de cette vulnérabilité.

La communauté de la sécurité a réagi rapidement en développant des outils open source pour automatiser la recherche de serveurs et d’instances sensibles. le plan Log4j. L’outil log4shell de LunaSec peut vérifier les fichiers .jar et .war dans un site de répertoire de tâches et signaler si certains sont vulnérables. L’assistance pour les vulnérabilités Log4j a en fait été ajoutée à d’autres scanners et outils de vulnérabilité open source et industriels.

Atténuations Log4j inefficaces

Depuis le tout premier Log4j vulnérabilité a été annoncée, un certain nombre d’atténuations proposées se sont en fait avérées inadéquates et ne devraient plus être fiables.

La mise à jour de la variante Java est inadéquate :L’exploit préliminaire n’a pas fonctionnent sur les versions Java plus récentes que 6u212, 7u202, 8u192 ou 11.0.2 car la configuration par défaut dans ces variantes empêche le chargement de classe via JNDI (Java Identification and Directory Site Interface) à partir de serveurs distants.

Cependant, les scientifiques de la sécurité ont en fait révélé que les assaillants peuvent développer des charges utiles qui bénéficient de classes dans le chemin de classe de l’application plutôt que de celles à distance, donc cela n’empêche pas toutes les attaques.

L’indicateur formatMsgNoLookups n’évite pas tous les exploits : Les premiers conseils d’atténuation, y compris de la part des développeurs de Log4j, consistaient à définir une maison appelée formatMsgNoLookups dans les versions de Log4j supérieures à 2.10 sur true ou une variable d’environnement appelée LOG4J_FORMAT_MSG_NO_LOOKUPS. Cela a été montré inefficace par la deuxième vulnérabilité de déni de service, qui fonctionne même avec cet indicateur autorisé.

 » Il existe encore des cours de code dans Log4j où des recherches de messages peuvent se produire : des exemples connus sont des applications qui utilisent Logger.printf( » %s « , userInput), ou des applications qui utilisent une fabrique de messages personnalisée, où le les messages résultants n’exécutent pas StringBuilderFormattable », ont déclaré les développeurs.

Désactivation des recherches de messages en modifiant les formats de déclaration de journal :Une atténuation proposée consistait à personnaliser tous les formats de déclaration de journal dans l’application à partir de % m, %msg ou %message à %m , %msg nolookups ou %message pour désactiver la fonction de recherche de message.

Cela ne fonctionne pas pour les mêmes facteurs que l’indicateur formatMsgNoLookups, mais est également dangereux car il développe une complaisance incorrecte. Il est très facile de rater la mise à jour d’une déclaration de journalisation dans une dépendance ou de réintroduire ultérieurement une déclaration %m vulnérable sans comprendre. Si vous avez actuellement utilisé cette atténuation, vous ne devez pas en dépendre.

Utiliser des programmes de pare-feu d’application Web (WAF) pour filtrer les demandes malveillantes :tout en bloquant les exploits connus avec un programme de pare-feu d’application Web est possible, il est extrêmement difficile d’attraper toutes les utilisations possibles des chaînes. Depuis que le défaut a été annoncé, les chercheurs ont en fait montré de nombreuses façons de construire des charges utiles intégrées et obscurcies qui contourneraient les directives de filtrage WAF proposées.

Cela dit, les fournisseurs WAF et IPS mettent constamment à jour leurs signatures Log4Shell, cela peut donc être utilisé comme une réaction instantanée et à court terme pour bloquer les exploits connus ou comme couche de défense supplémentaire en plus d’autres atténuations. Il convient de noter que les WAF sont généralement utilisés pour les propriétés exposées publiquement, mais il existe des cours et des situations internes d’utilisation de cette vulnérabilité qui ne passeraient pas par un WAF pour être bloqué.

Alors que la communauté de la sécurité continue de le faire. enquêter sur cette vulnérabilité et son impact, il est possible que les méthodes d’atténuation existantes soient modifiées ou supprimées. Il est donc préférable de vérifier en permanence la page de sécurité du projet Log4j et les avis d’organisations telles que CISA pour toute mise à jour.