Log4shell-detector informations générales - Historique des versions

Acryline : /* En général */

2021-12-15T10:09:16Z

En général

← Version précédente		Version du 15 décembre 2021 à 12:09
Ligne 38 :		Ligne 38 :

	=== En général ===		=== En général ===
	* Mettra à jour son système régulièrement en utilisant pour un système Debian et ~~dérivié~~ par exemple [https://wiki.debian.org/fr/unattended-upgrades unattended-upgrades]		* Mettra à jour son système régulièrement en utilisant pour un système Debian et dérivé par exemple [https://wiki.debian.org/fr/unattended-upgrades unattended-upgrades]
	* Utiliser des outils comme [https://doc.ubuntu-fr.org/fail2ban Fail2ban]		* Utiliser des outils comme [https://doc.ubuntu-fr.org/fail2ban Fail2ban]

	== Sources ==		== Sources ==

Acryline : /* Contre cette attaque */

2021-12-15T10:08:54Z

Contre cette attaque

← Version précédente		Version du 15 décembre 2021 à 12:08
Ligne 35 :		Ligne 35 :
	* Tester son système par exemple avec [[Log4shell-detector]]		* 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,		* 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.		* 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)
	(Voir ci-dessous)
	=== En général ===		=== En général ===
	* Mettra à jour son système régulièrement en utilisant pour un système Debian et dérivié par exemple [https://wiki.debian.org/fr/unattended-upgrades unattended-upgrades]		* Mettra à jour son système régulièrement en utilisant pour un système Debian et dérivié par exemple [https://wiki.debian.org/fr/unattended-upgrades unattended-upgrades]

Acryline le 15 décembre 2021 à 10:08

2021-12-15T10:08:33Z

← Version précédente		Version du 15 décembre 2021 à 12:08
Ligne 1 :		Ligne 1 :
			= 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
			* [https://fr.wikipedia.org/wiki/Cam%C3%A9ra_IP 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 [https://fr.wikipedia.org/wiki/Botnet botnet] pour ajouter des portes dérobées
			* outils de minage de crypto-monnaies
			* [https://fr.wikipedia.org/wiki/Ran%C3%A7ongiciel 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.
			* [https://fr.wikipedia.org/wiki/Cheval_de_Troie_(informatique) des chevaux de Troie]
			* un accès à distance
			* [https://fr.wikipedia.org/wiki/Web_shell 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érivié par exemple [https://wiki.debian.org/fr/unattended-upgrades unattended-upgrades]
			* Utiliser des outils comme [https://doc.ubuntu-fr.org/fail2ban Fail2ban]

			== Sources ==
			* https://www.darkreading.com/attacks-breaches/attackers-target-log4j-to-drop-ransomware-web-shells-backdoors
			* [https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Accueil_principal Wikipédia]
			* [https://github.com/Neo23x0/log4shell-detector Log4shell-detector]
			* Ma petite expérience

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

Acryline : /* Historique */

2021-12-15T09:21:53Z

Historique

← Version précédente		Version du 15 décembre 2021 à 11:21
Ligne 97 :		Ligne 97 :

	===Historique===		===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.

Acryline : /* Détails de la version */

2021-12-15T09:16:37Z

Détails de la version

← Version précédente		Version du 15 décembre 2021 à 11:16
Ligne 54 :		Ligne 54 :
	'''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.'''		'''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===		====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.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.

Acryline : /* Description */

2021-12-15T09:15:29Z

Description

← Version précédente		Version du 15 décembre 2021 à 11:15
Ligne 86 :		Ligne 86 :
	=== Description===		=== 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 [https://fr.abcdef.wiki/wiki/LDAP_injection 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.		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 [https://fr.abcdef.wiki/wiki/LDAP_injection 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===

Acryline : /* 26 novembre 2021 */

2021-12-15T09:11:32Z

26 novembre 2021

← Version précédente		Version du 15 décembre 2021 à 11:11
Ligne 71 :		Ligne 71 :
	https://issues.apache.org/jira/browse/LOG4J2-3221		https://issues.apache.org/jira/browse/LOG4J2-3221

	= 26 novembre 2021=		== 26 novembre 2021 Corrigé dans Log4j 2.15.0==
			===CVE-2021-44228 ===
			[https://cve.mitre.org/cgi-bin/cvename.cgi?name=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 [https://fr.abcdef.wiki/wiki/LDAP_injection 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.

Acryline : /* Références */

2021-12-15T09:02:15Z

Références

← Version précédente		Version du 15 décembre 2021 à 11:02
Ligne 70 :		Ligne 70 :
	===Références===		===Références===
	https://issues.apache.org/jira/browse/LOG4J2-3221		https://issues.apache.org/jira/browse/LOG4J2-3221

			= 26 novembre 2021=

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

2021-12-15T08:59:04Z

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

← Version précédente		Version du 15 décembre 2021 à 10:59
Ligne 14 :		Ligne 14 :

	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.		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===

			[https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046 CVE-2021-45046] : Apache Log4j2 Thread Context Message Pattern et Context Lookup Pattern vulnérables à une [https://fr.wikipedia.org/wiki/Attaque_par_d%C3%A9ni_de_service 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

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

2021-12-15T08:39:42Z

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

← Version précédente		Version du 15 décembre 2021 à 10:39
Ligne 13 :		Ligne 13 :
	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 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é à [[private@logging.apache.org~~\|l'équipe de sécurité de Log4j]]~~. Merci.		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.

Log4shell-detector informations générales - Historique des versions

Acryline : /* En général */

Acryline : /* Contre cette attaque */

Acryline le 15 décembre 2021 à 10:08

Acryline : /* Historique */

Acryline : /* Détails de la version */

Acryline : /* Description */

Acryline : /* 26 novembre 2021 */

Acryline : /* Références */

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

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

Acryline : /* En général */

Acryline : /* Contre cette attaque */

Acryline : /* Historique */

Acryline : /* Détails de la version */

Acryline : /* Description */

Acryline : /* 26 novembre 2021 */

Acryline : /* Références */

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

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