IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Sécurité Discussion :

Log4Shell : la menace n'a pas disparu et pourrait refaire surface si l'industrie ne fait pas attention


Sujet :

Sécurité

  1. #81
    Communiqués de presse

    Femme Profil pro
    Rédacteur technique
    Inscrit en
    mai 2018
    Messages
    1 867
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 32
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Rédacteur technique
    Secteur : Communication - Médias

    Informations forums :
    Inscription : mai 2018
    Messages : 1 867
    Points : 139 287
    Points
    139 287
    Par défaut Comment les entreprises ont répondu à Log4Shell, selon Qualys Cloud Platform
    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."

    Nom : Qualys-Log4Shell-Infographic-1070x5250-1.png
Affichages : 2461
Taille : 270,9 Ko

    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
    Publication de communiqués de presse en informatique. Contribuez au club : corrections, suggestions, critiques, ... Contactez le service news et Rédigez des actualités

  2. #82
    Communiqués de presse

    Femme Profil pro
    Rédacteur technique
    Inscrit en
    mai 2018
    Messages
    1 867
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 32
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Rédacteur technique
    Secteur : Communication - Médias

    Informations forums :
    Inscription : mai 2018
    Messages : 1 867
    Points : 139 287
    Points
    139 287
    Par défaut Les 10 principales cibles attaquables par Log4j, qui continue d'être un problème pour les entreprises,
    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.

    Nom : Log4j-most-attckable-640x476.png
Affichages : 2134
Taille : 156,1 Ko

    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
    Publication de communiqués de presse en informatique. Contribuez au club : corrections, suggestions, critiques, ... Contactez le service news et Rédigez des actualités

  3. #83
    Chroniqueur Actualités

    Homme Profil pro
    Dirigeant
    Inscrit en
    juin 2016
    Messages
    2 869
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Bénin

    Informations professionnelles :
    Activité : Dirigeant
    Secteur : Aéronautique - Marine - Espace - Armement

    Informations forums :
    Inscription : juin 2016
    Messages : 2 869
    Points : 61 564
    Points
    61 564
    Par défaut Un nouveau groupe de travail sur la cybersécurité affirme que la faille du logiciel Log4j est "endémique"
    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.

    Nom : nj.png
Affichages : 11685
Taille : 28,3 Ko

    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.

    Nom : jn.png
Affichages : 3899
Taille : 82,6 Ko

    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
    Contribuez au club : corrections, suggestions, critiques, ... Contactez le service news et Rédigez des actualités

  4. #84
    Expert éminent Avatar de marsupial
    Homme Profil pro
    Retraité
    Inscrit en
    mars 2014
    Messages
    1 607
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Autre

    Informations professionnelles :
    Activité : Retraité

    Informations forums :
    Inscription : mars 2014
    Messages : 1 607
    Points : 6 344
    Points
    6 344
    Par défaut
    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 ?
    Repeat after me
    Le monsieur lutte pour la défense des libertés individuelles et collectives

    Repeat after me...

  5. #85
    Membre actif
    Homme Profil pro
    Consultant
    Inscrit en
    novembre 2013
    Messages
    29
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Marne (Champagne Ardenne)

    Informations professionnelles :
    Activité : Consultant
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : novembre 2013
    Messages : 29
    Points : 258
    Points
    258
    Par défaut
    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.

  6. #86
    Communiqués de presse

    Femme Profil pro
    Rédacteur technique
    Inscrit en
    mai 2018
    Messages
    1 867
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 32
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Rédacteur technique
    Secteur : Communication - Médias

    Informations forums :
    Inscription : mai 2018
    Messages : 1 867
    Points : 139 287
    Points
    139 287
    Par défaut Log4Shell toujours exploité six mois plus tard, selon Trustwave SpiderLabs Telemetry
    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."

    Nom : log4shell.png
Affichages : 86679
Taille : 31,1 Ko

    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
    Publication de communiqués de presse en informatique. Contribuez au club : corrections, suggestions, critiques, ... Contactez le service news et Rédigez des actualités

  7. #87
    Membre expert

    Profil pro
    activité : oui
    Inscrit en
    janvier 2014
    Messages
    1 255
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : activité : oui

    Informations forums :
    Inscription : janvier 2014
    Messages : 1 255
    Points : 3 359
    Points
    3 359
    Par défaut
    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é.
    Pensez à utiliser les pouces d’appréciation, pour participer à la visibilité de l'apport d'un propos, ou l'intérêt que vous y prêtez... qu'il soit positif ou négatif.

  8. #88
    Communiqués de presse

    Femme Profil pro
    Rédacteur technique
    Inscrit en
    mai 2018
    Messages
    1 867
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Âge : 32
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Rédacteur technique
    Secteur : Communication - Médias

    Informations forums :
    Inscription : mai 2018
    Messages : 1 867
    Points : 139 287
    Points
    139 287
    Par défaut Trois organisations sur quatre sont encore vulnérables à Log4Shell, selon Tenable
    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."

    Nom : tenable.jpg
Affichages : 890
Taille : 12,5 Ko

    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
    Publication de communiqués de presse en informatique. Contribuez au club : corrections, suggestions, critiques, ... Contactez le service news et Rédigez des actualités

  9. #89
    Chroniqueur Actualités
    Avatar de Anthony
    Homme Profil pro
    Rédacteur technique
    Inscrit en
    novembre 2022
    Messages
    142
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Gironde (Aquitaine)

    Informations professionnelles :
    Activité : Rédacteur technique

    Informations forums :
    Inscription : novembre 2022
    Messages : 142
    Points : 2 285
    Points
    2 285
    Par défaut Le nombre de téléchargements de versions Log4j vulnérables reste élevé un an après l'incident
    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.

    Nom : log4j-chart-2.png
Affichages : 960
Taille : 69,6 Ko

    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 »
    Contribuez au club : corrections, suggestions, critiques, ... Contactez le service news et Rédigez des actualités

  10. #90
    Chroniqueur Actualités
    Avatar de Bruno
    Homme Profil pro
    Rédacteur technique
    Inscrit en
    mai 2019
    Messages
    1 223
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Cameroun

    Informations professionnelles :
    Activité : Rédacteur technique
    Secteur : High Tech - Produits et services télécom et Internet

    Informations forums :
    Inscription : mai 2019
    Messages : 1 223
    Points : 24 484
    Points
    24 484
    Par défaut Log4Shell : la menace n'a pas disparu et pourrait refaire surface si l'industrie ne fait pas attention
    Log4Shell : la menace n'a pas disparu et pourrait refaire surface si l'industrie ne fait pas attention,
    72 % des entreprises restent sensibles à Log4Shell, selon Tenable

    Les projets de vacances de décembre des informaticiens ont été bouleversés l'année dernière par la divulgation d'un bogue majeur dans l'outil Log4j, largement utilisé. Cette découverte a entraîné des mois d'activité fébrile pour corriger la vulnérabilité, mais un an plus tard, elle a disparu du radar. Selon les experts en sécurité, la menace n'a pas disparu pour autant et pourrait refaire surface si l'industrie ne fait pas attention.

    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.

    Nom : log4jV.jpg
Affichages : 1067
Taille : 90,7 Ko

    Lorsqu'il a été révélé pour la première fois au début du mois de décembre 2021, le bogue Log4Shell a été décrit comme l'une des vulnérabilités de sécurité les plus graves jamais rencontrées. Il visait un outil populaire de journalisation de l'activité dans les logiciels Java, conçu pour aider à garder une trace des erreurs et à diagnostiquer les problèmes de performance. Grâce à sa grande utilité, Log4j a été intégré dans des milliers de logiciels et a été trouvé dans une grande variété de services commerciaux, y compris Amazon Web Services et le jeu vidéo Minecraft. Qui plus est, le bogue a permis aux attaquants de prendre le contrôle total des systèmes vulnérables en toute simplicité.

    Cela a entraîné une course effrénée pour combler les lacunes. La fondation Apache Software, qui gère l'outil open source, a rapidement publié un correctif, et les organisations ont passé des mois à analyser leurs systèmes et à mettre à jour leurs logiciels. Mais plus d'un an plus tard, la société de cybersécurité Tenable affirme que 72 % des entreprises restent sensibles à Log4Shell. Et, fait inquiétant, un grand nombre d'organisations qui avaient corrigé le bogue l'ont depuis réintroduit dans leurs systèmes en installant des logiciels vulnérables, déclare Bernard Montel, directeur technique et stratège en sécurité chez Tenable.

    Le 9 décembre 2021, 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. La vulnérabilité dans Log4J 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. 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.

    Comme dit précedement, Log4Shell est une vulnérabilité logicielle dans Apache Log4j 2, une bibliothèque Java populaire permettant de consigner les messages d'erreur dans les applications. La vulnérabilité, publiée sous le nom de CVE-2021-44228, permet à un attaquant distant de prendre le contrôle d'un appareil sur Internet si l'appareil exécute certaines versions de Log4j 2.

    Apache a publié un correctif pour CVE-2021-44228, version 2.15, le 6 décembre 2021. Cependant, ce correctif laissait une partie de la vulnérabilité non corrigée, ce qui a donné lieu à CVE-2021-45046 et à un deuxième correctif, version 2.16, publié le 13 décembre. Apache a publié un troisième correctif, la version 2.17, le 17 décembre pour corriger une autre vulnérabilité connexe, CVE-2021-45105. Un quatrième correctif, 2.17.1, a été publié le 28 décembre pour corriger une autre vulnérabilité, CVE-2021-44832.

    Les attaquants peuvent exploiter cette vulnérabilité en utilisant des messages texte pour contrôler un ordinateur à distance. L'Apache Software Foundation, qui publie la bibliothèque Log4j 2, a attribué à la vulnérabilité un score CVSS de 10, le score de gravité le plus élevé, en raison de son potentiel d'exploitation à grande échelle et de la facilité avec laquelle les attaquants malveillants peuvent l'exploiter. Alors que les mesures d'atténuation évoluent et que les dégâts se déploient, les principes fondamentaux de la vulnérabilité Log4j ne changeront pas.

    Le chercheur en sécurité Chen Zhaojun d'Alibaba, la plus grande société de commerce électronique de Chine, a signalé pour la première fois la vulnérabilité à la Fondation Apache (un projet open-source) le 24 novembre. Ils ont découvert l'attaque le 9 décembre sur des serveurs qui hébergent le jeu Minecraft. Après une analyse forensique plus poussée, ils ont réalisé que les cybercriminels avaient découvert la faille plus tôt, et l'exploitaient depuis au moins le 1er décembre 2021.

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

    « Lorsqu'ils ont mis en place un plan pour le réparer il y a environ un an, ils pensaient l'avoir fait », dit-il. « Ils ont nettoyé, ils ont identifié, ils ont scanné, ils ont patché leurs logiciels et pour eux, ils ont fait ce qu'ils avaient à faire. Ils ont juste oublié le fait que la surface d'attaque se déplace. »

    Tenable estime que la proportion de machines vulnérables à l'exploit est passée d'une sur dix en décembre dernier à seulement 2,5 % en octobre dernier. Mais jusqu'à un tiers de ces machines avaient déjà été entièrement corrigées et ont depuis été réinfectées par Log4Shell. Selon Montel, une partie du problème réside dans le fait que Log4j est profondément enfoui dans un grand nombre de bibliothèques logicielles courantes.

    Il n'est souvent pas évident de savoir si l'utilitaire est inclus dans un outil particulier, et même lorsqu'il l'est, la plupart des développeurs ne sont pas suffisamment sensibilisés à la sécurité pour vérifier s'il s'agit de la version la plus récente, compte tenu notamment de la pression qu'ils subissent pour produire du code rapidement, ajoute-t-il. Des recherches menées par la société de sécurité Sonatype il y a un an ont révélé que 65 % des téléchargements de Log4j concernaient des versions vulnérables de l'outil.

    Au niveau organisationnel, Montel pense également qu'après l'énorme pression exercée pour traiter la vulnérabilité au cours des premiers mois, il était presque inévitable que les gens se déconcentrent une fois qu'ils avaient l'impression d'avoir remédié au problème. Il pense qu'il existe des analogies évidentes avec la pandémie de Covid-19, au cours de laquelle des mesures rigoureuses telles que les fermetures ont rapidement permis de maîtriser le virus, avant qu'il ne réapparaisse lorsque les choses se sont à nouveau détendues. « Il [Log4j] revient », affirme Montel. « Il est toujours là quelque part, il suffit d'observer les vagues ».

    Un rapport de juillet du Cyber Safety Review Board du ministère de la Sécurité intérieure indique que le bug était devenu « endémique » et qu'il était susceptible de rester un problème pendant des années, voire des décennies. Et les données recueillies par la société de sécurité Imperva ont montré que si les attaques exploitant le bug ont considérablement diminué depuis les deux premiers mois de 2022, on observe une augmentation constante depuis novembre, le 3 décembre de cette année ayant vu les attaques quotidiennes les plus élevées depuis la découverte de la vulnérabilité.

    Imperva estime qu'environ 7 % de ces attaques sont couronnées de succès. Mais bien qu'il y ait eu quelques piratages très médiatisés - dont ceux menés par des pirates chinois parrainés par l'État en mars et une attaque iranienne contre une agence fédérale américaine en novembre - jusqu'à présent, le bug n'a pas été à la hauteur des prédictions terribles faites l'année dernière. « Bien que de nombreuses entreprises aient été touchées, le nombre d'attaques a été largement inférieur à ce qui avait été prévu », explique Gabi Stapel, analyste de la recherche sur les menaces chez Imperva.

    Il a cependant mis en lumière la dépendance de nombreuses entreprises à l'égard de codes tiers et open source sur lesquels elles n'ont que peu de contrôle ou de visibilité. « Historiquement, les entreprises se sont concentrées sur le risque introduit par leurs fournisseurs immédiats et les logiciels critiques dont elles dépendent », explique Stapel. « Les organisations doivent adopter un modèle de menace qui inclut toutes les parties de la chaîne d'approvisionnement. »

    Le coût et la complexité de la réponse à Log4Shell ont certainement incité à mettre de plus en plus l'accent sur la sécurisation de la chaîne d'approvisionnement des logiciels et à stimuler la transparence, déclare Eric Goldstein, directeur adjoint exécutif pour la cybersécurité à la Cybersecurity and Infrastructure Security Agency (CISA). « Une multitude de nouveaux outils, entreprises et produits ont vu le jour l'année dernière pour aider à mieux comprendre les dépendances logicielles, et Log4j est souvent utilisé comme motivation principale pour l'innovation et l'adoption », explique-t-il.

    L'un des remèdes potentiels promus par la CISA est le Software Bill of Materials (SBOM). Il s'agit d'un inventaire de tous les composants d'une application logicielle, conçu pour permettre aux développeurs de repérer plus facilement toute dépendance à l'égard de parties de code potentiellement dangereuses. Le gouvernement américain a indiqué qu'ils pourraient bientôt devenir une exigence pour les logiciels fournis aux agences fédérales.

    Pour que cette approche ait réellement un impact, elle doit cependant se déplacer plus en amont, déclare Brian Behlendorf, directeur général de l'Open Source Security Foundation (OSSF), afin que même les paquets ou bibliothèques de logiciels libres originaux que les développeurs assemblent pour créer des applications soient accompagnés de leurs propres SBOM. Pour y parvenir, il faudra probablement créer de nouveaux outils qui simplifient ce processus et les intégrer aux outils de création de logiciels existants, explique Behlendorf, car « il peut être difficile d'inciter les développeurs à fournir un effort supplémentaire ».

    L'industrie dans son ensemble doit également mieux se coordonner et être plus proactive en matière de sécurisation des outils open source sur lesquels elle s'appuie, dit-il. Selon Behlendorf, les projets individuels ne disposent tout simplement pas des ressources financières ou humaines nécessaires pour effectuer des tâches telles que la révision du code. « Il y a tout simplement un décalage entre la valeur que doit recevoir l'écosystème et la capacité à rassembler ce type de ressources », dit-il. « Ce dont nous avons besoin, c'est d'institutions capables d'agréger la demande d'un meilleur examen de ces choses et de canaliser les ressources vers des objectifs ciblés et faciles à atteindre. »

    Source : IEEE

    Et vous ?

    Quel est votre avis sur le sujet ?

    Voir aussi :

    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 »

    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 »
    Contribuez au club : corrections, suggestions, critiques, ... Contactez le service news et Rédigez des actualités

Discussions similaires

  1. Réponses: 0
    Dernier message: 26/07/2021, 13h02
  2. Réponses: 0
    Dernier message: 25/06/2021, 15h24
  3. Réponses: 1
    Dernier message: 13/08/2020, 16h43
  4. Réponses: 5
    Dernier message: 12/05/2020, 16h44
  5. Réponses: 6
    Dernier message: 01/02/2018, 17h28

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo