Discussion :

[walfrat]

Ce que ça m'inspire, c'est que Apache et Java, c'est de la M.

Mais surtout, ce qui est de loin le pire, c'est le fait de faire des projets qui incluent je ne sais combien de dépendances externes, et donc la moindre faille dans un composant, même mineur comme ici, met en danger tout le Web parce que je ne sais combien de projets l'incluent par paresse.

De la même manière, la moindre dépendance qui disparaît du jour au lendemain peut empêcher le fonctionnement de milliers de projets, c'était arrivé à Node.Js.

Je sais bien que réinventer la roue n'est pas une bonne chose, mais j'ai toujours milité pour limiter le nombre de dépendances externes dans mes projets. Ma règle d'or : si les doigts d'une main ne suffisent pas à compter les projets externes dont dépendent mon propre projet, c'est qu'il y en a trop et un jour ou l'autre, ça va me péter à la gueule.

On en a ici la preuve.

C'est débile comme raisonnement, la faille de log4j, faut utiliser log4j pour qu'elle soit exploitable.
Avoir log4j dans ton classpath ne rend pas ton application vulnérable.

Et comment compte tu le nombre de projet dont tu dépend ? Spring c'est un projet ? Ou tu compte un projet par Spring-context,Spring-orm,Spring-tx ?

Tu compte Apache tomcat comme une dépendance dans ton projet ? Et l'OS de déploiement c'est aussi une dépendance ?

Enfin, entre ton codage, et celui de librairie éprouvé (open source ou non), le tiens aura sans doute largement plus de failles de sécurité.

[mood8moody]

La faille de sécurité c'est Java, depuis le temps qu'on le dit. On a réussi à s'en débarrasser dans la plupart des navigateurs mais combien d'entreprises doivent garder une version périmée de java pour faire tourner une application qui ne supporte pas la maj du jre, et il n'y a pas que des développements maison, des fournisseurs de solutions matériels et logiciels utilisent encore java et ont besoin d'installer une version précise qui ne doit pas être mise à jour.

[Christophe]

Est-ce vraiment Java le problème ? ou plutôt l'utilisation de composants externes mal programmée, ou des failles de la JVM ?
Pour ce dernier aspect, les postes faillibles :
- sont-ils à jour au niveau Java ?
- L'utilisation d’une JVM autre que celle d'Oracle est il plus sûr ?

[A3gisS3c]

Est-ce vraiment Java le problème ? ou plutôt l'utilisation de composants externes mal programmée, ou des failles de la JVM ?
Pour ce dernier aspect, les postes faillibles :
- sont-ils à jour au niveau Java ?
- L'utilisation d’une JVM autre que celle d'Oracle est il plus sûr ?

D’expérience 90% des boites sont réticentes à faire des mises à jour pour ne pas casser leur code il est la le problème.
On est obligé de combler leur lacune via l'IPS.

[marsupial]

Est-ce vraiment Java le problème ? ou plutôt l'utilisation de composants externes mal programmée, ou des failles de la JVM ?
Pour ce dernier aspect, les postes faillibles :
- sont-ils à jour au niveau Java ?
- L'utilisation d’une JVM autre que celle d'Oracle est il plus sûr ?

jndi est maintenu par Oracle car composant développé par Sun : c'est lui la source de la vulnérabilité, pas le langage ou Apache.
Marc Collin a posté un lien qui date de 2016 lors d'une conférence Black Hat. Il s'agirait de sécuriser jndi.

[Stéphane le calme]

Plus de 35 000 packages Java impactés par les vulnérabilités Log4j
selon un rapport de l'équipe open source de Google

L'équipe open source de Google a déclaré avoir analysé Maven Central, le plus grand référentiel de packages Java, et a découvert que 35 863 packages Java utilisent des versions vulnérables de la bibliothèque Apache Log4j. Cela inclut les packages Java qui utilisent des versions Log4j vulnérables à l'exploit Log4Shell d'origine (CVE-2021-44228) et un deuxième bogue d'exécution de code à distance découvert dans le correctif Log4Shell (CVE-2021-45046).

Log4j est une bibliothèque de journalisation open source basée sur Java utilisée dans des millions d'applications. Il y a quelques jours, une vulnérabilité dans Log4J a été découverte. Elle permet à un attaquant de provoquer une exécution de code arbitraire à distance s'il a la capacité de soumettre une donnée à une application qui utilise la bibliothèque log4j pour journaliser l'évènement. Cette attaque peut être réalisée sans être authentifié, par exemple en tirant parti d'une page d'authentification qui journalise les erreurs d'authentification. Les entreprises spécialisées en cybersécurité ont indiqué que le nombre d'attaques profitant de cette faille se multiplient.

James Wetter et Nicky Ringland, membres de l'équipe Google Open Source Insights, ont déclaré dans un rapport que, bien souvent, lorsqu'une faille de sécurité Java majeure est détectée, elle n'affecte généralement que 2% de l'index Maven Central. Cependant, les 35 000 packages Java vulnérables à Log4Shell représentent environ 8 % du total de Maven Central d'environ 440 000, un pourcentage que les deux ont décrit en utilisant un seul mot : « énorme ».

« Plus de 35 000 packages Java, représentant plus de 8 % du référentiel Maven Central (le référentiel de packages Java le plus important), ont été touchés par les vulnérabilités log4j récemment divulguées, avec des retombées généralisées dans l'industrie du logiciel. Les vulnérabilités permettent à un attaquant d'exécuter du code à distance en exploitant la fonctionnalité de recherche JNDI non sécurisée exposée par la bibliothèque de journalisation log4j. Cette fonctionnalité exploitable était activée par défaut dans de nombreuses versions de la bibliothèque.

« Cette vulnérabilité a captivé l'écosystème de la sécurité de l'information depuis sa divulgation le 9 décembre en raison à la fois de sa gravité et de son impact généralisé. En tant qu'outil de journalisation populaire, log4j est utilisé par des dizaines de milliers de progiciels (appelés artefacts dans l'écosystème Java) et de projets dans l'ensemble de l'industrie du logiciel. Le manque de visibilité de l'utilisateur sur ses dépendances et ses dépendances transitives a rendu l'application des correctifs difficile ; cela a également rendu difficile la détermination du rayon d'explosion complet de cette vulnérabilité. En utilisant Open Source Insights, un projet pour aider à comprendre les dépendances open source, nous avons examiné toutes les versions de tous les artefacts dans le référentiel central Maven pour déterminer l'étendue du problème dans l'écosystème open source des langages basés sur JVM, et pour suivre les efforts en cours pour atténuer les paquets affectés ».

Depuis que la vulnérabilité a été divulguée, Wetter et Ringland ont déclaré que la communauté avait répondu positivement et avait déjà corrigé 4 620 des 35 863 packages qu'ils avaient initialement trouvés vulnérables. Ce nombre représente 13% de tous les packages vulnérables. « Ceci, plus que toute autre statistique, témoigne des efforts massifs déployés par les mainteneurs open source, les équipes de sécurité de l'information et les consommateurs du monde entier », ont déclaré Wetter et Ringland.

À titre de comparaison, les deux citent des statistiques similaires pour les failles de sécurité Java passées, où environ 48% des bibliothèques en amont et en aval sont mises à jour pour corriger les vulnérabilités. Cependant, les deux ne s'attendent pas à ce que le problème Log4Shell soit entièrement corrigé, du moins pour les années à venir.

La principale raison en est que Log4j n'est pas toujours inclus en tant que dépendance directe dans les packages Java, mais est également une dépendance d'une autre dépendance, également appelée dépendance indirecte.

Dans ces situations, les responsables de packages Java vulnérables doivent attendre d'autres développeurs avant de pouvoir mettre à jour leurs propres applications, prolongeant ce processus pendant des semaines et des mois, dans certains cas.

Selon Google, Log4j est une dépendance directe dans seulement 7 000 packages sur les 35 000 bibliothèques totales, et de nombreux développeurs Java devront très probablement remplacer les dépendances indirectes qui n'ont pas été mises à jour avec des alternatives sûres.

Quelle est l'étendue de la vulnérabilité log4j ?

« Au 16 décembre 2021, nous avons constaté que 35 863 des artefacts Java disponibles de Maven Central dépendent du code log4j affecté. Cela signifie que plus de 8 % de tous les packages sur Maven Central ont au moins une version impactée par cette vulnérabilité. (Ces chiffres n'incluent pas tous les packages Java, tels que les binaires directement distribués, mais Maven Central est un puissant indicateur de l'état de l'écosystème.) En ce qui concerne l'impact sur l'écosystème, 8 %, c'est énorme. L'impact moyen sur l'écosystème des avis affectant Maven Central est de 2 %, avec une médiane inférieure à 0,1 %.

« Les dépendances directes représentent environ 7 000 des artefacts affectés, ce qui signifie que l'une de ses versions dépend d'une version affectée de log4j-core ou log4j-api, comme décrit dans les CVE. La majorité des artefacts affectés proviennent de dépendances indirectes (c'est-à-dire les dépendances de ses propres dépendances), ce qui signifie que log4j n'est pas explicitement défini comme une dépendance de l'artefact, mais est intégré comme une dépendance transitive ».

Quels sont les progrès actuels dans la réparation de l'écosystème JVM open source ?

« Nous avons compté un artefact comme corrigé si l'artefact avait au moins une version affectée et a publié une version plus stable (selon la gestion sémantique des versions) qui n'est pas affectée. Un artefact affecté par log4j est considéré comme corrigé s'il a été mis à jour vers 2.16.0 ou s'il a complètement supprimé sa dépendance à log4j.

« Au moment de la rédaction de cet article, près de cinq mille des artefacts concernés ont été corrigés. Cela représente une réponse rapide et un effort colossal à la fois de la part des mainteneurs de log4j et de la communauté plus large des consommateurs open source.

« Cela laisse plus de 30 000 artefacts affectés, dont beaucoup dépendent d'un autre artefact à corriger (la dépendance transitive) et sont probablement bloqués ».

Pourquoi est-il difficile de réparer l'écosystème JVM ?

« La plupart des artefacts qui dépendent de log4j le font indirectement. Plus la vulnérabilité est profonde dans une chaîne de dépendances, plus il faut d'étapes pour qu'elle soit corrigée. Le diagramme suivant montre un histogramme de la profondeur avec laquelle un package log4j affecté (core ou api) apparaît pour la première fois dans les graphiques de dépendance des consommateurs. Pour plus de 80 % des packages, la vulnérabilité est profonde de plus d'un niveau, avec une majorité affectée à cinq niveaux (et certains jusqu'à neuf niveaux). Ces packages nécessiteront des correctifs dans toutes les parties de l'arborescence, en commençant par les dépendances les plus profondes.

« Une autre difficulté est causée par les choix au niveau de l'écosystème dans l'algorithme de résolution des dépendances et les conventions de spécification des exigences.

« Dans l'écosystème Java, il est courant de spécifier les exigences de version "soft" - les versions exactes qui sont utilisées par l'algorithme de résolution si aucune autre version du même package n'apparaît plus tôt dans le graphique de dépendance. La propagation d'un correctif nécessite souvent une action explicite de la part des responsables pour mettre à jour les exigences de dépendance vers une version corrigée.

« Cette pratique contraste avec d'autres écosystèmes, tels que npm, où il est courant pour les développeurs de spécifier des plages ouvertes pour les exigences de dépendance. Les plages ouvertes permettent à l'algorithme de résolution de sélectionner la version la plus récemment publiée qui répond aux exigences de dépendance, introduisant ainsi de nouveaux correctifs. Les consommateurs peuvent obtenir une version corrigée lors de la prochaine version une fois le correctif disponible, ce qui propage rapidement les dépendances. (Cette approche n'est pas sans inconvénients*; l'ajout de nouveaux correctifs peut également entraîner de nouveaux problèmes.) »

Combien de temps faudra-t-il pour que cette vulnérabilité soit corrigée dans l'ensemble de l'écosystème ?

« C'est difficile à dire. Nous avons examiné tous les avis critiques publiés concernant les packages Maven pour avoir une idée de la rapidité avec laquelle les autres vulnérabilités ont été entièrement corrigées. Moins de la moitié (48 %) des artefacts affectés par une vulnérabilité ont été corrigés, nous pourrions donc devoir attendre longtemps, probablement des années.

« Mais les choses semblent prometteuses sur le front de log4j. Après moins d'une semaine, 4 620 artefacts affectés (~ 13 %) ont été corrigés. Ceci, plus que toute autre statistique, témoigne de l'effort massif des mainteneurs open source, des équipes de sécurité de l'information et des consommateurs à travers le monde ».

Le rapport a été publié avant la découverte d'une vulnérabilité sur le deuxième correctif, conduisant à la publication de la version 2.17.0 de Log4j

Les membres de l’Apache Software Fondation ont développé un patch en catastrophe pour corriger la vulnérabilité, la version 2.15.0. Des contournements sont également possibles pour réduire les risques.

Mais les chercheurs ont signalé qu'il existe au moins deux vulnérabilités dans le correctif, publié sous le nom de Log4J 2.15.0, et que les attaquants exploitent activement l'une d'entre elles ou les deux contre des cibles du monde réel qui ont déjà appliqué la mise à jour. Les chercheurs ont exhorté les organisations à installer un nouveau correctif, publié en tant que version 2.16.0, dès que possible pour corriger la vulnérabilité, qui est suivie comme CVE-2021-45046.

Le correctif précédent, ont déclaré les chercheurs mardi soir, « était incomplet dans certaines configurations autres que celles par défaut » et permettait aux attaquants d'effectuer des attaques par déni de service, ce qui facilite généralement la mise hors ligne des services vulnérables jusqu'à ce que les victimes redémarrent leur serveurs ou prennent d'autres mesures. La version 2.16.0 « résout ce problème en supprimant la prise en charge des modèles de recherche de messages et en désactivant la fonctionnalité JNDI par défaut », selon l'avis de vulnérabilité lié ci-dessus.

La version 2.15.0 ne résolvait pas un autre problème - CVE-2021-45046 - qui permettait à un attaquant distant contrôlant le Thread Context Map (MDC) de préparer une entrée malveillante à l'aide d'un modèle de recherche JNDI. Le résultat pourrait être l'exécution de code à distance, heureusement pas dans tous les environnements.

La version 2.16.0 a résolu ce problème. Mais elle n'a pas corrigé CVE-2021-45105, que l'Apache Software Foundation décrit comme suit :

« Les versions 2.0-alpha1 à 2.16.0 d'Apache Log4j2 ne protégeaient pas contre la récursivité incontrôlée des recherches auto-référentielles. Lorsque la configuration de la journalisation utilise une disposition de modèle autre que celle par défaut avec une recherche de contexte (par exemple, $${ctx:loginId}), les attaquants contrôlant les données d'entrée de Thread Context Map (MDC) peuvent créer des données d'entrée malveillantes contenant une recherche récursive, ce qui entraîne une StackOverflowError qui mettra fin au processus. Ceci est également connu sous le nom d'attaque DOS (Denial of Service) ».

Source : Google

[marsupial]

La dernière météorite tombée sur Terre a provoqué l'extinction du règne animal laissant la place à l'humanité....

[gallima]

N'importe qu'elle projet java moderne utilise un gestionnaire de dépendance (maven, gradle, ivy ou autre) dans lequel il est possible et facile de forcer la version de log4j utilisé même si aucun paquet n'a de dépendance directe dessus. (moderne <=> mise à jour après 2004)

Les développeurs ne sont donc pas bloqués pendant que les mises à jour remontent toutes les chaînes de dépendances comme l'article veut nous le faire croire.

Informer en première page juste assez pour faire peur pour faire du clic sans donner le contexte ? Google n'a pas honte... mais quid de celui qui diffuse ?

[gabriel21]

Je vois dans les crises sécuritaires actuelles un problème plus profond :
L'architecture système repose sur une notion de couche et les développeurs ne comprennent plus rien aux bases, voir en ont rien à "bip".
Combien de fois j'ai pu entendre, j'en ai rien à faire de comment ça marche tant que ça marche de la part de nombreux développeurs (et pas uniquement Java ).
Il nous font "bip" tous ces administrateurs système avec leur "bip" de mise à jour qui casse mon super code de la mort qui tue tout. Parce que le problème, ce n'est pas nous, mais forcément les autres...
Combien de fois je suis épouvanté par le fait que juste pour afficher "Hello World", il faut un serveur avec 2 processeurs et 64Go de mémoire? Moi qui es commencé sur des systèmes avec des Pentium III et 64 Mo de ram.
Car pourquoi se faire "bip" par les dépendances quand il suffit d'intégrer un framework de 4 Go pour 3 fonctions qui pèsent 3Ko, et plusieurs fois dans le projet...

Mais moi qui fait un peu de programmation, mais qui suis administrateur système de vocation, je pleure.
Pour moi, le minimum est le mieux. Je pleure quand je dois faire 5 mises à jour de noyau Linux parce qu’il y a une faille sur une fonctionnalité que nous n'utilisons pas, mais vous comprenez avoir une personne qui compile un noyau qui correspond à notre besoin, ça coûte trop chère alors on utilise un noyau générique qui pèse 150Mo alors que l'on pourrait utiliser un noyau de 50 Mo qui ne demande pas de mise à jour régulière. Je regrettes ces serveur qui ont un Uptime de 3000 jours, car ayant un noyau optimisé pour leur matériel et n'utilisant pas le chargement dynamique de module du noyau Linux, n'ont pas de failles du moins connue...

[Christophe]

Les projets devant être sorti pour la vielle, un développeur a tout intérêt à réutiliser des briques existantes, l'optimisation , on verra pour la version 1.1.

Car pourquoi se faire "bip" par les dépendances quand il suffit d'intégrer un framework de 4 Go pour 3 fonctions qui pèsent 3Ko, et plusieurs fois dans le projet...

Ben oui, si la machine demande plus de puissance à cause d'un framework, on la change, ça va plus vite.

On fait vite ou on fait bien ? that is the question.

[A3gisS3c]

Je vois dans les crises sécuritaires actuelles un problème plus profond :
L'architecture système repose sur une notion de couche et les développeurs ne comprennent plus rien aux bases, voir en ont rien à "bip".
Combien de fois j'ai pu entendre, j'en ai rien à faire de comment ça marche tant que ça marche de la part de nombreux développeurs (et pas uniquement Java ).
Il nous font "bip" tous ces administrateurs système avec leur "bip" de mise à jour qui casse mon super code de la mort qui tue tout. Parce que le problème, ce n'est pas nous, mais forcément les autres...
Combien de fois je suis épouvanté par le fait que juste pour afficher "Hello World", il faut un serveur avec 2 processeurs et 64Go de mémoire? Moi qui es commencé sur des systèmes avec des Pentium III et 64 Mo de ram.
Car pourquoi se faire "bip" par les dépendances quand il suffit d'intégrer un framework de 4 Go pour 3 fonctions qui pèsent 3Ko, et plusieurs fois dans le projet...

Mais moi qui fait un peu de programmation, mais qui suis administrateur système de vocation, je pleure.
Pour moi, le minimum est le mieux. Je pleure quand je dois faire 5 mises à jour de noyau Linux parce qu’il y a une faille sur une fonctionnalité que nous n'utilisons pas, mais vous comprenez avoir une personne qui compile un noyau qui correspond à notre besoin, ça coûte trop chère alors on utilise un noyau générique qui pèse 150Mo alors que l'on pourrait utiliser un noyau de 50 Mo qui ne demande pas de mise à jour régulière. Je regrettes ces serveur qui ont un Uptime de 3000 jours, car ayant un noyau optimisé pour leur matériel et n'utilisant pas le chargement dynamique de module du noyau Linux, n'ont pas de failles du moins connue...

Perso je ne laisse absolument pas le choix aux devs.
MAJ et reboot des serveurs de production automatisés une fois par mois. Avec de la Debian/Redhat, tu ne crains pas grand chose concernant la stabilité.

Un uptime de 300 jours est inconcevable d'un point de vue sécurité.

[Escapetiger]

Je vois dans les crises sécuritaires actuelles un problème plus profond :
L'architecture système repose sur une notion de couche et les développeurs ne comprennent plus rien aux bases, voir en ont rien à "bip".
Combien de fois j'ai pu entendre, j'en ai rien à faire de comment ça marche tant que ça marche de la part de nombreux développeurs (et pas uniquement Java ).
Il nous font "bip" tous ces administrateurs système avec leur "bip" de mise à jour qui casse mon super code de la mort qui tue tout. Parce que le problème, ce n'est pas nous, mais forcément les autres...

Mais moi qui fait un peu de programmation, mais qui suis administrateur système de vocation, je pleure.
Pour moi, le minimum est le mieux. Je pleure quand je dois faire 5 mises à jour de noyau Linux parce qu’il y a une faille sur une fonctionnalité que nous n'utilisons pas, mais vous comprenez avoir une personne qui compile un noyau qui correspond à notre besoin, ça coûte trop chère alors on utilise un noyau générique qui pèse 150Mo alors que l'on pourrait utiliser un noyau de 50 Mo qui ne demande pas de mise à jour régulière. Je regrettes ces serveur qui ont un Uptime de 3000 jours, car ayant un noyau optimisé pour leur matériel et n'utilisant pas le chargement dynamique de module du noyau Linux, n'ont pas de failles du moins connue...

Entièrement d'accord,

En tant qu'administrateur système et initié au développement également (via Cobol, le shell ksh, bash ...) au départ sur Mainframe (Ordinateur central), c'est effectivement une philosophie de la rigueur qui est difficilement applicable au quotidien dans des environnements inter-dépendants, complexifiés par les couches logicielles, le TTM (Time To Market) exigé (cf. le déploiement continu, DevOps, DevSecOps ...).

Sous la pression commune à nous tou.te.s, selon leur formation (parfois low-cost en 3, 6 mois), beaucoup de développeurs n'ont pas (plus) le temps, pas l'envie voire ne comprennent pas bien tous les rouages de la compatibilité ascendante et descendante; l'exigence de cloisonnement des environnements de développement, test, pré-production, production, le concept et les bonnes pratiques issues de ITIL (Information Technology Infrastructure Library) etc.

Comme par exemple dans ce blog de developpez dont on peut s'inspirer à propos de la compatibilté :

Définissons la compatibilité descendante :

Le nouveau serveur est compatible avec la version cliente précédente
Le nouveau client est compatible avec la version serveur précédente

Compatibilité ascendante :
l’ancien client est compatible avec la nouvelle version serveur
l’ancienne version serveur est compatible avec la nouvelle version client

En fait, c’est quand on développe une nouvelle version qu’il faut se poser la question. (Je connais des développeurs qui se sont fait des noeuds au cerveau avec ça, lol)
(.../...)

Source :
https://blog.developpez.com/cobos/
Le blog du développeur mainframe agile
Modernisons les usines de dev COBOL Mainframe

[tmcuh]

J'ai jamais compris qu'un programmeur voulait dépendre d'une librairie (de plusieurs Mo) qui va écrire dans un fichier un log.txt. Cet Class est reproduite en 30 min (en y mettant pleins de contrôles) et utilisé dans tous vos projets, pourquoi dépendre d'un Framework que tout le monde utilise et qui étant open source permet de trouver des failles plus facilement ?
Y'a une réelle fénéantise des développeur nouvelle génération c'est une certitude.

[Christophe]

c'est pas forcément de la fainéantise, mais prendre un truc déjà fait c'est toujours plus rapide que de coder, donc quand on met la pression sur les délais...

[miaous]

J'ai jamais compris qu'un programmeur voulait dépendre d'une librairie (de plusieurs Mo) qui va écrire dans un fichier un log.txt. Cet Class est reproduite en 30 min (en y mettant pleins de contrôles) et utilisé dans tous vos projets, pourquoi dépendre d'un Framework que tout le monde utilise et qui étant open source permet de trouver des failles plus facilement ?
Y'a une réelle fénéantise des développeur nouvelle génération c'est une certitude.

si tu utilise des frameworks différent ( un pour le web / un autre pour la bdd/ un troisième pour généré des document au format XXX ...) et que chaqu'un à sont propre système de log , quand tu doit configuré le tout tu t'amuserai.

[Bruno]

Le ministère de la Défense belge subit une cyberattaque en raison d'une vulnérabilité de Log4j,
l'identité des auteurs de l'attaque est toutefois inconnue

Le ministère belge de la défense a déclaré le 16 décembre avoir découvert une attaque sur son réseau informatique. L'attaque qui a eu lieu la semaine dernière en exploitant l'une des vulnérabilités de Log4j a paralysé certaines activités du ministère. « La Défense a découvert une attaque sur son réseau informatique avec accès à Internet. Des mesures de quarantaine ont été rapidement prises pour isoler les parties touchées. Cette attaque fait suite à l'exploitation de la vulnérabilité Log4j, qui a été rendue publique la semaine dernière et pour laquelle les spécialistes informatiques du monde entier s'engouffrent dans la brèche », a déclaré, Olivier Severin le porte-parole du ministère.

Depuis jeudi dernier, l'armée belge est aux prises avec les conséquences d'une grave cyberattaque. Une partie du réseau informatique ne peut être utilisée pour l'instant, précise le porte-parole. Le système de messagerie, par exemple, est en panne depuis plusieurs jours. L'attaque informatique s'est produite après qu'une faille de sécurité dans le logiciel ait été découverte la semaine dernière seulement.

Comme indiqué précédemment, l'attaque à la Défense a été causée par une faille dans la sécurité du logiciel Log4j d'Apache, largement utilisé. La faille de sécurité est apparue juste avant le week-end et représente un risque important pour les réseaux d'entreprise du monde entier, car de nombreuses applications bien connues utilisent le logiciel en question pour conserver les "journaux".

Selon le fournisseur israélien de solutions de cybersécurité Check Point Software Technologies, un groupe de pirates informatiques liés au régime iranien, surnommé Charming Kitten ou APT 35, a exploité la faille de Log4j pour lancer des attaques contre sept cibles en Israël, dont des sites gouvernementaux.

Log4j est une bibliothèque de journalisation open source basée sur Java utilisée dans des millions d'applications. Il y a quelques jours, une vulnérabilité dans Log4J a été découverte. Elle permet à un cybercriminel de provoquer une exécution de code arbitraire à distance s'il a la capacité de soumettre une donnée à une application qui utilise la bibliothèque log4j pour journaliser l'évènement.

Grâce à Log4j, les entreprises technologiques peuvent vérifier si leurs applications fonctionnent correctement. S'il y a un défaut quelque part dans une application, un message d'erreur est envoyé via Log4j au fabricant, qui peut alors déterminer si une réparation est nécessaire. Amazon, Apple, Cloudflare, Tesla, Minecraft et Twitter, entre autres, utilisent également Log4j.

L’attaque a été causée par une faille dans la sécurité du logiciel Log4j d'Apache, largement utilisé, selon le ministère de la Défense. La faille de sécurité est apparue juste avant le week-end et représente un risque important pour les réseaux d'entreprise du monde entier, car de nombreuses applications bien connues utilisent le logiciel en question pour conserver des "journaux".

La semaine dernière, des avertissements ont été lancés concernant les problèmes causés par la fuite dans le logiciel largement utilisé. Les entreprises spécialisées en cybersécurité ont indiqué que le nombre d'attaques profitant de cette faille se multiplient. Pour remédier à cette situation, les membres de l’Apache Software Fondation ont développé un patch.

Les chercheurs ont signalé qu'il existe au moins deux vulnérabilités dans le correctif, publié sous le nom de Log4J 2.15.0, et que les attaquants exploitent activement l'une d'entre elles ou les deux contre des cibles du monde qui ont déjà appliqué la mise à jour. Les chercheurs ont exhorté les organisations à installer un nouveau correctif, publié en tant que version 2.16.0, dès que possible pour corriger la vulnérabilité, qui est suivie comme CVE-2021-45046.

Le correctif précédent, ont déclaré les chercheurs, « était incomplet dans certaines configurations autres que celles par défaut » et permettait aux attaquants d'effectuer des attaques par déni de service, ce qui facilite généralement la mise hors ligne des services vulnérables jusqu'à ce que les victimes redémarrent leur serveurs ou prennent d'autres mesures. La version 2.16.0 « résout ce problème en supprimant la prise en charge des modèles de recherche de messages et en désactivant la fonctionnalité JNDI par défaut », selon l'avis de vulnérabilité lié ci-dessus.

Des chercheurs de la société de sécurité Praetorian ont déclaré qu'il y avait une vulnérabilité encore plus grave dans 2.15.0 (une faille de divulgation d'informations qui peut être utilisée pour télécharger des données à partir des serveurs concernés).

Le Centre de cybersécurité de Belgique, une organisation gouvernementale, a publié un communiqué de presse indiquant que « Les entreprises qui utilisent le logiciel Apache Log4j et qui n'ont pas encore pris de mesures peuvent s'attendre à des problèmes majeurs dans les jours et les semaines à venir. » La semaine dernière, l'Agence pour la cybersécurité et la sécurité des infrastructures (CISA) du gouvernement américain a publié une directive d'urgence exigeant que les agences fédérales prennent des mesures correctives concernant la vulnérabilité d'Apache Log4j avant le 23 décembre 2021.

Source : VRT

Et vous ?

Quel est votre avis sur le sujet ?

Voir aussi :

Jamais deux sans trois : Apache révèle un autre bogue dans la bibliothèque de journalisation Log4J, le troisième correctif majeur en dix jours est une faille de récursivité infinie

Plus de 35 000 packages Java impactés par les vulnérabilités Log4j, selon un rapport de l'équipe open source de Google

Des cybercriminels exploitent activement la faille critique dans Log4J : plus de 840 000 attaques ont été détectées, le spectre d'un scénario rappelant Heartbleed fait surface

Les cybercriminels exploitent la faille "zero-day", alors que les entreprises prennent 97 jours en moyenne pour mettre en œuvre les correctifs, selon HP Wolf Security

[A3gisS3c]

Mon avis? Bien fait pour le ministère de la défense Belge.

Une faille pareille ça se corrige dans la minute, pas deux semaines après.

[marsupial]

Je suis d'accord mais je ne saurai pas trop prompte à jeter la pierre car les belges n'ont peut-être pas les ressources nécessaires. pour appliquer le correctif. Le monde entier défend et attaque sur cette vulnérabilité, et le temps joue contre les défenseurs. Plus le temps passe, plus il risque d'y avoir des attaques victorieuses. Et tout le monde ne dit pas s'il a été powned donc les belges sont loin d'être les seuls.

[A3gisS3c]

C'est vrai mais ce n'est pas parce que le serveur n'est pas patché qu'il est vulnérable.
Ca veut aussi dire qu'ils ont ouvert un sacré flux ANY en destination de sortie et ça ce n'est pas vraiment pardonnable de la part d'un ministère de la défense.

Bon et bien sur qu'ils n'ont aucun IPS, certainement aucun EDR, qu'ils n'ont fait aucun audit et donc aucun patch/mitigation. Donc par extrapolation qu'ils n'ont aucun ingénieur sécurité.

[TotoParis]

Mon avis? Bien fait pour le ministère de la défense Belge.

Une faille pareille ça se corrige dans la minute, pas deux semaines après.

Ah le sale gosse ! Gros prétentieux en plus !
Bonhomme, si c'était aussi simple. Les YAKA-FAUKON...on en a plein !