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

Le , par Sandra Coret

35PARTAGES

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

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