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

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

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

Le , par Sandra Coret

34PARTAGES

6  0 
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

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de damthemad
Membre actif https://www.developpez.com
Le 23/07/2022 à 10:31
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.
2  0 
Avatar de marsupial
Expert éminent https://www.developpez.com
Le 18/07/2022 à 17:52
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 ?
1  0 
Avatar de Steinvikel
Membre expert https://www.developpez.com
Le 09/09/2022 à 13:47
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é.
1  0 
Avatar de chrtophe
Responsable Systèmes https://www.developpez.com
Le 10/04/2024 à 19:05
Tellement peu standards que les hyperviseurs VMWare non patchés sont vulnérables, exemple le plus connu pour moi.
1  0 
Avatar de vdaburon
Membre à l'essai https://www.developpez.com
Le 10/04/2024 à 18:00
Bonjour,
Concernant les vulnérabilités de log4j1.2.x, j'ai regardé les conditions pour exploiter les vulnérabilités.
Il s'agit de vulnérabilité sur les appenders (système d'écriture des logs) très peu utilisés comme écrire les logs directement en base de données JDBX, ou envoyé dans des files de message JMS ou via des connexions réseaux distantes.

Si on fait des logs dans des fichiers locaux de façon beaucoup plus classique pas de problème.

Je ne dis pas que ces vulnérabilités ne sont pas graves, je dis qu'elles ne sont pas pour des cas standards d'utilisation.

Et donc dire qu'il y a 4 vulnérabilités et donc que le risque est important n'est pas vrai.

C'est juste pour relativiser l'article sur les dangers de ne pas changer de version des librairies ayants des vulnérabilités.
Cordialement
Vincent DAB.
0  0