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 !

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

Le , par Sandra Coret

37PARTAGES

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

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

Avatar de thamn
Membre averti https://www.developpez.com
Le 31/01/2022 à 2:45
Citation Envoyé par Sandra Coret Voir le message
[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
2  0 
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