Log4shell-detector informations générales

Conséquences possibles d'une attaque Log4shell

La faille Log4j exécutable à distance - ou Log4Shell, comme on l'appelle maintenant - a suscité une inquiétude générale parce qu'elle se trouve dans un cadre de journalisation presque omniprésent dans les applications Java. Les experts en sécurité considèrent que cette faille est particulièrement inquiétante car elle est relativement facile à exploiter et permet aux attaquants de prendre le contrôle total de tout système exécutant une application vulnérable. Quelque 7 000 projets open source sont concernés par la vulnérabilité.(Ndlr : utilisés par des particuliers, des entreprises, pour des projets privateurs ou par l'administration.) De nombreuses organisations n'ont pas la visibilité nécessaire sur l'utilisation de l'ensemble de leur système d'information.

Pour les attaquants, la vulnérabilité a présenté une opportunité presque sans précédent d'essayer d'attaquer et de compromettre des milliards de dispositifs dans le monde. Jusqu'à présent, plus de 50 % des attaques provenaient d'acteurs connus de la menace, et la vitesse à laquelle les nouvelles variantes d'exploitation évoluent est sans précédent, a déclaré Akamai.

"C'est un morceau de code est si commun qu'il est même un élément constitutif de l'hélicoptère Ingenuity à bord du rover de Mars", a déclaré Sonatype.

Cibles

• serveurs,
• machines virtuelles,
• PC
• caméras IP

Le fournisseur de solutions de sécurité pour l'Internet des objets Armis a quant à lui constaté que 42 % des attaques visent les serveurs et que plus d'un quart d'entre elles (27 %) ciblent les machines virtuelles. Parmi les autres dispositifs relativement bien ciblés figurent les PC (7 %) et les caméras IP d'imagerie (12 %), ce qui est quelque peu inhabituel, selon Armis.

À peine 2 % des tentatives d'exploitation de la vulnérabilité concernaient des automates de fabrication, et 1 % des IHM.

Les risques

• compromettre des systèmes dans le but de les ajouter à un botnet pour ajouter des portes dérobées
• outils de minage de crypto-monnaies
• des ransomwares, avec une nouvelle famille de ransomware appelée Khonsari : Cette attaque implique l'utilisation d'un fichier .NET malveillant qui, une fois exécuté, répertorie tous les lecteurs d'un système vulnérable et les chiffre entièrement, à l'exception du lecteur C :, où il chiffre des dossiers spécifiques, notamment des documents, des vidéos et des téléchargements.
• des chevaux de Troie
• un accès à distance
• shells Web : Cette technique est utilisée par les attaquants pour prendre pied dans les systèmes en vue d'une exploitation ultérieure.

À ce stade, la plupart des attaques impliquant la faille Log4j restent de nature opportuniste, ce qui est typique de la première phase d'une vulnérabilité de type "jour zéro". Mais les entreprises peuvent s'attendre à voir cette faille exploitée dans des attaques plus ciblées à l'avenir, ajoute O'Neill. "Il est inévitable que des attaquants plus avancés cherchent à prendre pied maintenant, puis à exploiter cette vulnérabilité à un stade ultérieur."

"La vulnérabilité Log4j présente le même schéma d'exploitation que d'autres zero-days, soit environ cinq à sept jours avant une exploitation généralisée par les groupes criminels", explique Sergio Caltagirone, vice-président de la division "threat intelligence" de Dragos. "Bien sûr, Java n'a pas été un langage de programmation ou une plateforme populaire pour les cybercriminels depuis un bon moment et ils auront donc une légère courbe d'apprentissage." Toutefois, ne vous attendez pas à ce que ce fait dissuade les attaquants pendant trop longtemps, ajoute-t-il, étant donné le nombre de victimes vulnérables.

En outre, les adversaires peuvent exploiter la vulnérabilité Log4j dans les systèmes propriétaires de contrôle de surveillance et d'acquisition de données (SCADA) et les systèmes de gestion de l'énergie (EMS) qui utilisent Java, a averti M. Dragos.

Ce qu'il faut faire

Contre cette attaque

• Tester son système par exemple avec Log4shell-detector
• mettre à jour la nouvelle version du cadre de journalisation Log4j que la Fondation Apache a publié le 10 décembre,
• ou d'appliquer les mesures d'atténuation qu'elle a recommandées, ont déclaré les experts en sécurité cette semaine.(Voir ci-dessous)

En général

• Mettra à jour son système régulièrement en utilisant pour un système Debian et dérivé par exemple unattended-upgrades
• Utiliser des outils comme Fail2ban

Sources

• https://www.darkreading.com/attacks-breaches/attackers-target-log4j-to-drop-ransomware-web-shells-backdoors
• Wikipédia
• Log4shell-detector
• Ma petite expérience

Annonce Apache : Vulnérabilités de sécurité d'Apache Log4j

Source : https://logging.apache.org/log4j/2.x/security.html#CVE-2021-45046

Cette page répertorie toutes les vulnérabilités de sécurité corrigées dans les versions publiées d'Apache Log4j 2. Chaque vulnérabilité se voit attribuer une note d'impact sur la sécurité par l'équipe de sécurité d'Apache Logging. Veuillez noter que cette note peut varier d'une plate-forme à l'autre. Nous indiquons également les versions d'Apache Log4j que la faille est censée affecter, et lorsqu'une faille n'a pas été vérifiée, nous indiquons la version avec un point d'interrogation.

Remarque : Les vulnérabilités qui ne sont pas des vulnérabilités de Log4j mais qui ont été signalées de manière incorrecte contre Log4j ou pour lesquelles Log4j fournit une solution de contournement sont listées à la fin de cette page.

Veuillez noter que Log4j 1.x a atteint sa fin de vie et n'est plus pris en charge. Les vulnérabilités signalées après août 2015 contre Log4j 1.x n'ont pas été vérifiées et ne seront pas corrigées. Les utilisateurs doivent passer à Log4j 2 pour obtenir les correctifs de sécurité.

Veuillez noter que les correctifs binaires ne sont jamais fournis. Si vous devez appliquer un correctif de code source, utilisez les instructions de construction pour la version d'Apache Log4j que vous utilisez. Pour Log4j 2, il s'agit du fichier BUILDING.md. Ce fichier se trouve dans le sous-répertoire racine d'un distributeur de sources.

Si vous avez besoin d'aide pour construire ou configurer Log4j ou pour suivre les instructions visant à atténuer les vulnérabilités connues énumérées ici, veuillez envoyer vos questions à la liste de diffusion publique des utilisateurs de Log4j.

Si vous avez rencontré une vulnérabilité de sécurité non répertoriée ou un autre comportement inattendu ayant un impact sur la sécurité, ou si les descriptions données ici sont incomplètes, veuillez les signaler en privé à l'équipe de sécurité de Log4j via private@logging.apache.org. Merci.

14 décembre 2021 : Corrigé dans Log4j 2.12.2 et Log4j 2.16.0

CVE-2021-45046

CVE-2021-45046 : Apache Log4j2 Thread Context Message Pattern et Context Lookup Pattern vulnérables à une attaque par déni de service.

Gravité

Modérée

Score CVSS de base

3.7 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L)

Versions concernées

Toutes les versions de 2.0-beta9 à 2.12.1 et de 2.13.0 à 2.15.0.

Description

Il a été découvert que la correction de la CVE-2021-44228 dans Apache Log4j 2.15.0 était incomplète dans certaines configurations qui ne sont pas par défaut. Cela pourrait permettre à des attaquants ayant le contrôle des données d'entrée de Thread Context Map (MDC) lorsque la configuration de journalisation utilise un Pattern Layout non par défaut avec soit un Context Lookup (par exemple, $${ctx:loginId}) ou un Thread Context Map pattern (%X, %mdc, ou %MDC) pour créer des données d'entrée malveillantes à l'aide d'un pattern JNDI Lookup résultant en une attaque par déni de service (DOS). Log4j 2.15.0 restreint par défaut les recherches LDAP JNDI à localhost. Notez que les mesures d'atténuation précédentes impliquant une configuration telle que la définition de la propriété système log4j2.noFormatMsgLookup à true n'atténuent PAS cette vulnérabilité spécifique.

Mesures d'atténuation

• Atténuation pour Log4j 1.x : Log4j 1.x n'est pas impacté par cette vulnérabilité.

• Atténuation pour Log4j 2.x : Mettre en œuvre l'une des techniques d'atténuation ci-dessous.
• Les utilisateurs de Java 8 (ou d'une version ultérieure) doivent passer à la version 2.16.0.
• Les utilisateurs nécessitant Java 7 doivent effectuer une mise à niveau vers la version 2.12.2 dès qu'elle sera disponible (travail en cours, devrait être disponible bientôt).
• Sinon, supprimez la classe JndiLookup du chemin de classe : zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Notez que seul le fichier JAR log4j-core est impacté par cette vulnérabilité. Les applications utilisant uniquement le fichier JAR log4j-api sans le fichier JAR log4j-core ne sont pas impactées par cette vulnérabilité.

Historique

Mesures d'atténuation plus anciennes (discréditées)

Cette page mentionnait précédemment d'autres mesures d'atténuation, mais nous avons découvert que ces mesures ne font que limiter l'exposition tout en laissant certains vecteurs d'attaque ouverts.

Les autres mesures d'atténuation insuffisantes sont les suivantes : définir la propriété système log4j2.formatMsgNoLookups ou la variable d'environnement LOG4J_FORMAT_MSG_NO_LOOKUPS à true pour les versions >= 2.10, ou modifier la configuration de la journalisation pour désactiver les recherches de messages avec %m{nolookups}, %msg{nolookups} ou %message{nolookups} pour les versions >= 2.7 et <= 2.14.1.

La raison pour laquelle ces mesures sont insuffisantes est que, en plus du vecteur d'attaque Thread Context mentionné ci-dessus, il existe encore des chemins de code dans Log4j où des recherches de messages pourraient se produire : des exemples connus sont les applications qui utilisent Logger.printf("%s", userInput), ou les applications qui utilisent une fabrique de messages personnalisée, où les messages résultants n'implémentent pas StringBuilderFormattable. Il peut y avoir d'autres vecteurs d'attaque.

La chose la plus sûre à faire est de mettre à niveau Log4j vers une version sûre, ou de supprimer la classe JndiLookup du jar log4j-core.

Détails de la version

Dans la version 2.12.2, la fonction de consultation des messages a été complètement supprimée. Les recherches dans la configuration fonctionnent toujours. En outre, Log4j désactive désormais l'accès à JNDI par défaut. Les recherches JNDI renvoient désormais une valeur constante. Enfin, Log4j limite désormais les protocoles par défaut à java.

Dans la version 2.16.0, la fonction de consultation des messages a été complètement supprimée. Les recherches dans la configuration fonctionnent toujours. En outre, Log4j désactive désormais l'accès à JNDI par défaut. Les recherches JNDI dans la configuration doivent maintenant être activées explicitement. De plus, Log4j limite désormais les protocoles par défaut à java, ldap et ldaps et limite les protocoles ldap à l'accès aux objets primitifs Java. Les hôtes autres que l'hôte local doivent être explicitement autorisés.

Travaux en cours

L'équipe Log4j continuera à mettre activement à jour cette page (Ndlr : page source) au fur et à mesure que des informations supplémentaires seront connues.

Crédit

Ce problème a été découvert par Kai Mindermann de iC Consult.

Références

https://issues.apache.org/jira/browse/LOG4J2-3221

26 novembre 2021 Corrigé dans Log4j 2.15.0

CVE-2021-44228

CVE-2021-44228 : Les fonctionnalités JNDI d'Apache Log4j2 ne protègent pas contre le contrôle par un attaquant de LDAP et d'autres points de terminaison liés à JNDI.

Gravité

Critique

Score CVSS de base

10.0 CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

Versions concernées

Toutes les versions de 2.0-beta9 à 2.12.1 et de 2.13.0 à 2.14.1.

Description

Dans les versions d'Apache Log4j2 jusqu'à la version 2.14.1 incluse (à l'exception de la version de sécurité 2.12.2), les fonctionnalités JNDI utilisées dans les configurations, les messages de journal et les paramètres ne sont pas protégées contre le contrôle par un attaquant de LDAP et d'autres points de terminaison liés à JNDI. Un attaquant qui peut contrôler les messages de journal ou les paramètres des messages de journal peut exécuter du code arbitraire chargé à partir de serveurs LDAP lorsque la substitution de recherche de message est activée.

Mesures d'atténuation

Atténuation pour Log4j 1.x : Log4j 1.x ne dispose pas de Lookups, le risque est donc plus faible. Les applications utilisant Log4j 1.x ne sont vulnérables à cette attaque que si elles utilisent JNDI dans leur configuration. Un CVE distinct (CVE-2021-4104) a été déposé pour cette vulnérabilité. Pour y remédier : vérifiez votre configuration de journalisation pour vous assurer qu'aucun JMSAppender n'est configuré. Les configurations Log4j 1.x sans JMSAppender ne sont pas affectées par cette vulnérabilité.

Atténuation pour Log4j 2.x : Mettre en oeuvre l'une des techniques d'atténuation ci-dessous.

• Les utilisateurs de Java 8 (ou d'une version ultérieure) doivent passer à la version 2.16.0.
• Les utilisateurs nécessitant Java 7 doivent effectuer une mise à niveau vers la version 2.12.2 dès qu'elle sera disponible (travail en cours, devrait être disponible bientôt).
• Sinon, supprimez la classe JndiLookup du chemin de classe : zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Notez que seul le fichier JAR log4j-core est impacté par cette vulnérabilité. Les applications utilisant uniquement le fichier JAR log4j-api sans le fichier JAR log4j-core ne sont pas impactées par cette vulnérabilité.

Historique

Mesures d'atténuation plus anciennes (discréditées)

Cette page mentionnait précédemment d'autres mesures d'atténuation, mais nous avons découvert que ces mesures ne font que limiter l'exposition tout en laissant certains vecteurs d'attaque ouverts.

Il a été constaté que la version 2.15.0 est toujours vulnérable lorsque la configuration a une disposition de motif contenant un Context Lookup (par exemple, $${ctx:loginId}), ou un motif Thread Context Map %X, %mdc ou %MDC. Lorsqu'un attaquant peut contrôler les valeurs de Thread Context, il peut injecter un motif JNDI Lookup, qui sera évalué et donnera lieu à une connexion JNDI. Log4j 2.15.0 restreint par défaut les connexions JNDI à localhost, mais cela peut encore entraîner des attaques DOS (déni de service), voire pire.

Un nouveau CVE (CVE-2021-45046, voir ci-dessus) a été créé pour ce problème.

Les autres mesures d'atténuation insuffisantes sont les suivantes : définir la propriété système log4j2.formatMsgNoLookups ou la variable d'environnement LOG4J_FORMAT_MSG_NO_LOOKUPS à true pour les versions >= 2.10, ou modifier la configuration de la journalisation pour désactiver les recherches de messages avec %m{nolookups}, %msg{nolookups} ou %message{nolookups} pour les versions >= 2.7 et <= 2.14.1.

La raison pour laquelle ces mesures sont insuffisantes est que, en plus du vecteur d'attaque Thread Context mentionné ci-dessus, il existe encore des chemins de code dans Log4j où des recherches de messages pourraient se produire : des exemples connus sont les applications qui utilisent Logger.printf("%s", userInput), ou les applications qui utilisent une fabrique de messages personnalisée, où les messages résultants n'implémentent pas StringBuilderFormattable. Il peut y avoir d'autres vecteurs d'attaque.

La chose la plus sûre à faire est de mettre à niveau Log4j vers une version sûre, ou de supprimer la classe JndiLookup du jar log4j-core.

Détails de la version

Depuis Log4j 2.15.0, la fonction de consultation des messages est désactivée par défaut. Les recherches dans la configuration fonctionnent toujours. Bien que Log4j 2.15.0 dispose d'une option permettant d'activer les recherches de cette manière, il est fortement déconseillé aux utilisateurs de l'activer. Un mécanisme de liste blanche a été introduit pour les connexions JNDI, autorisant uniquement localhost par défaut.

À partir de la version 2.16.0, la fonction de consultation des messages a été complètement supprimée. Les recherches dans la configuration fonctionnent toujours. De plus, Log4j désactive maintenant l'accès à JNDI par défaut. Les recherches JNDI dans la configuration doivent maintenant être activées explicitement. De plus, Log4j limite désormais les protocoles par défaut à java, ldap et ldaps et limite les protocoles ldap à l'accès aux objets primitifs Java. Les hôtes autres que l'hôte local doivent être explicitement autorisés.

Travaux en cours

L'équipe Log4j continuera à mettre activement à jour cette page au fur et à mesure que des informations supplémentaires seront connues.

Crédit

Ce problème a été découvert par Chen Zhaojun de l'équipe de sécurité d'Alibaba Cloud.

Références

https://issues.apache.org/jira/browse/LOG4J2-3201 et https://issues.apache.org/jira/browse/LOG4J2-3198.