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 !

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

Le , par Stéphane le calme

231PARTAGES

18  0 
Une vulnérabilité dans Log4J permet à un attaquant 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. Les entreprises spécialisées en cybersécurité indiquent que le nombre d'attaques profitant de cette faille se multiplient. 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.

Apache Log4j, qu'est-ce que c'est ? Quelle est la sévérité de la faille ?

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

Des preuves de concept ont déjà été publiées. Cette vulnérabilité fait désormais l'objet d'une exploitation active.

La sévérité de la brèche est maximale 10 sur l’échelle CVSS.

Voici la liste des systèmes affectés :
  • Apache Log4j versions 2.0 à 2.14.1
  • Apache Log4j versions 1.x (versions obsolètes) sous réserve d'une configuration particulière.
  • Les produits utilisant une version vulnérable de Apache Log4j : les CERT nationaux européens tiennent à jour une liste complète des produits et de leur statut vis-à-vis de la vulnérabilité

Le CERT-FR recommande de réaliser une analyse approfondie des journaux réseau. Les motifs suivants permettent d'identifier une tentative d'exploitation de cette vulnérabilité lorsqu'ils sont utilisés dans les URLs ou certaines en-têtes HTTP comme user-agent :

Code : Sélectionner tout
1
2
${jndi:
$%7Bjndi:     (prend en compte un obscurcissement simple)
Cependant, les attaquants peuvent utiliser des moyens d’obscurcissement pour contourner les motifs de détection précédents. Les motifs suivants permettent de prendre en compte certaines méthodes d'obscurcissement mais peuvent provoquer des faux positifs :

Code : Sélectionner tout
1
2
3
4
5
6
7
8
9
10
${${
${::-
%24%7B%3A%3A-
${env:
${date:
${lower:
${upper:
hostName}
}${
${                   (génère beaucoup de faux positifs, mais très exhaustif)
Afin de déterminer si une tentative d'exploitation a réussi, et dans le cas où vous disposeriez de journaux contenant des requêtes DNS, il est recommandé de les corréler aux résultats des motifs précédemment énoncés. En effet, si l’exécution d'une requête de type ${jndi:xxx://nom.domaine.com} a fonctionné, une résolution DNS sera alors effectuée pour résoudre le nom de domaine externe nom.domaine.com. L'émission d'une requête DNS peut également faire l'objet d'une trace dans les journaux du serveur applicatif. Ainsi, il peut être utile de chercher le motif com.sun.jndi.dns.DnsContext@ dans ces journaux. Une résolution de domaine externe ne signifie pas qu'une exécution de code a réussi mais permet de confirmer que l'application est vulnérable. Il sera donc nécessaire de poursuivre l'analyse des journaux pour détecter une compromission.

Il est fortement recommandé d'utiliser la version 2.15.0 de log4j dès que possible. Cependant, en cas de difficulté de migration vers cette version, les contournements ci-dessous peuvent être appliqués temporairement :
  • Pour les applications utilisant les versions 2.7.0 et ultérieures de la bibliothèque log4j, il est possible de se prémunir contre toute attaque en modifiant le format des évènements à journaliser avec la syntaxe %m{nolookups} pour les données qui seraient fournies par l'utilisateur. Cette modification impose de modifier le fichier de configuration de log4j pour produire une nouvelle version de l'application. Cela requiert donc d'effectuer de nouveau les étapes de validation technique et fonctionnelle avant le déploiement de cette nouvelle version.
  • Pour les applications utilisant les versions 2.10.0 et ultérieures de la bibliothèque log4j, il est également possible de se prémunir contre toute attaque en modifiant le paramètre de configuration log4j2.formatMsgNoLookups à la valeur true, par exemple lors du lancement de la machine virtuelle Java avec l'option -Dlog4j2.formatMsgNoLookups=true. Une autre alternative consiste à supprimer la classe JndiLookup dans le paramètre classpath pour éliminer le vecteur principal d'attaque (les chercheurs n'excluent pas l'existence d'un autre vecteur d'attaque).

Plus de 840 000 attaques ont été lancées

Selon des chercheurs, des pirates, dont des groupes soutenus par l'État chinois mais aussi par la Russie, ont lancé plus de 840 000 attaques contre des entreprises dans le monde depuis vendredi dernier via cette vulnérabilité.

Le groupe de cybersécurité Check Point a déclaré que les attaques liées à la vulnérabilité s'étaient accélérées au cours des 72 heures depuis vendredi et qu'à certains moments, ses chercheurs voyaient plus de 100 attaques par minute. L’éditeur a également observé une forte créativité dans l’adaptation de l’attaque. Parfois, plus de 60 nouvelles variations apparaissent en moins de 24 heures, introduisant de nouvelles techniques d’obfuscation ou de codage.


Les auteurs incluent des « attaquants du gouvernement chinois », selon Charles Carmakal, directeur de la technologie de la cyber-entreprise Mandiant.

La faille de Log4J permet aux attaquants de prendre le contrôle à distance des ordinateurs exécutant des applications en Java.

Jen Easterly, directrice de l'Agence américaine de cybersécurité et de sécurité des infrastructures (CISA), a déclaré aux dirigeants de l'industrie que la vulnérabilité était « l'une des plus graves que j'ai vues de toute ma carrière, sinon la plus grave », selon les médias américains. Des centaines de millions d'appareils sont susceptibles d'être touchés, a-t-elle déclaré.

Check Point a déclaré que dans de nombreux cas, les pirates prenaient le contrôle d'ordinateurs pour les utiliser pour miner de la crypto-monnaie ou pour faire partie de botnets, de vastes réseaux d'ordinateurs pouvant être utilisés pour submerger les sites Web de trafic, pour envoyer du spam ou pour d'autres fins illégales.

Pour Kaspersky, la plupart des attaques proviennent de la Russie.

La CISA et le National Cyber ​​Security Center du Royaume-Uni ont maintenant émis des alertes exhortant les organisations à effectuer des mises à niveau liées à la vulnérabilité Log4J, alors que les experts tentent d'évaluer les retombées. Amazon, Apple, IBM, Microsoft et Cisco font partie de ceux qui se sont précipités pour publier des correctifs, mais aucune violation grave n'a été signalée publiquement jusqu'à présent.

La vulnérabilité est la dernière à toucher les réseaux d'entreprise, après l'émergence de failles au cours de la dernière année dans les logiciels couramment utilisés de Microsoft et de la société informatique SolarWinds. Ces deux vulnérabilités auraient été initialement exploitées par des groupes d'espionnage soutenus par l'État de Chine et de Russie respectivement.

Carmakal de Mandiant a déclaré que les acteurs soutenus par l'État chinois tentaient également d'exploiter le bogue Log4J mais ont refusé de partager plus de détails. Des chercheurs de SentinelOne ont également déclaré aux médias qu'ils avaient observé des pirates informatiques chinois tirer parti de la vulnérabilité.

Selon Check Point, près de la moitié de toutes les attaques ont été menées par des cyber-attaquants connus. Ceux-ci comprenaient des groupes utilisant Tsunami et Mirai, des logiciels malveillants qui transforment les appareils en botnets, ou des réseaux utilisés pour lancer des piratages contrôlés à distance tels que des attaques par déni de service. Il comprenait également des groupes utilisant XMRig, un logiciel qui exploite la monnaie numérique Monero.

« Avec cette vulnérabilité, les attaquants obtiennent une puissance presque illimitée - ils peuvent extraire des données sensibles, télécharger des fichiers sur le serveur, supprimer des données, installer un ransomware ou pivoter vers d'autres serveurs », a déclaré Nicholas Sciberras, responsable de l'ingénierie chez Acunetix, scanner de vulnérabilités. Il a été « étonnamment facile » de déployer une attaque, a-t-il déclaré, ajoutant que la faille serait « exploitée pendant des mois à venir ».

La source de la vulnérabilité est un code défectueux développé par des bénévoles de l'association à but non lucratif Apache Software Foundation, qui gère plusieurs projets open source, soulevant des questions sur la sécurité des parties vitales de l'infrastructure informatique. Log4J a été téléchargé des millions de fois.

La faille est passée inaperçue depuis 2013, estiment les experts. Matthew Prince, directeur général du cybergroupe Cloudflare, a déclaré qu'elle avait commencé à être activement exploité à partir du 1er décembre, bien qu'il n'y ait eu aucune « preuve d'exploitation de masse avant la divulgation publique » d'Apache la semaine suivante.


Pour sa part, Bitdefender a vu des tentatives d'installations d’un ransomware baptisé Khonsari et d’une porte dérobée appelée Orcus, réalisées grâce à Log4Shell :

« Alors que la plupart des attaques observées jusqu'à présent semblent cibler des serveurs Linux, nous avons également vu des attaques contre des systèmes exécutant le système d'exploitation Windows. Pour ces attaques, nous avons détecté la tentative de déploiement d'une famille de ransomwares appelée Khonsari.

« Cette tentative d'exploitation de la vulnérabilité Log4j utilise la classe malveillante hxxp://3.145.115[.]94/Main.class pour télécharger une charge utile supplémentaire. Le dimanche 11 décembre, Bitdefender a observé cette charge utile comme un téléchargement de fichier binaire .NET malveillant depuis hxxp://3.145.115[.]94/zambo/groenhuyzen.exe. Il s'agit d'une nouvelle famille de ransomwares, appelée Khonsari d'après l'extension utilisée sur les fichiers cryptés.

« Une fois exécuté, le fichier malveillant listera tous les lecteurs et les chiffrera entièrement, à l'exception du lecteur C:\. Sur le lecteur C:\, Khonsari chiffrera uniquement les dossiers suivants*:
  • C:\Utilisateurs\<utilisateur>\Documents
  • C:\Utilisateurs\<utilisateur>\Vidéos
  • C:\Utilisateurs\<utilisateur>\Images
  • C:\Utilisateurs\<utilisateur>\Téléchargements
  • C:\Utilisateurs\<utilisateur>\Bureau

« Les fichiers avec les extensions .ini et .lnk sont ignorés. L'algorithme utilisé pour le cryptage est AES 128 CBC utilisant PaddingMode.Zeros. Après chiffrement, l'extension .khonsari est ajoutée à chaque fichier ».

Sources : Check Point, Kaspersky, NetLab 360, CERT-FR, Cados Security, Bitdefender

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

Avatar de gabriel21
Membre expérimenté https://www.developpez.com
Le 21/12/2021 à 23:48
Je vois dans les crises sécuritaires actuelles un problème plus profond :
L'architecture système repose sur une notion de couche et les développeurs ne comprennent plus rien aux bases, voir en ont rien à "bip".
Combien de fois j'ai pu entendre, j'en ai rien à faire de comment ça marche tant que ça marche de la part de nombreux développeurs (et pas uniquement Java ).
Il nous font "bip" tous ces administrateurs système avec leur "bip" de mise à jour qui casse mon super code de la mort qui tue tout. Parce que le problème, ce n'est pas nous, mais forcément les autres...
Combien de fois je suis épouvanté par le fait que juste pour afficher "Hello World", il faut un serveur avec 2 processeurs et 64Go de mémoire? Moi qui es commencé sur des systèmes avec des Pentium III et 64 Mo de ram.
Car pourquoi se faire "bip" par les dépendances quand il suffit d'intégrer un framework de 4 Go pour 3 fonctions qui pèsent 3Ko, et plusieurs fois dans le projet...

Mais moi qui fait un peu de programmation, mais qui suis administrateur système de vocation, je pleure.
Pour moi, le minimum est le mieux. Je pleure quand je dois faire 5 mises à jour de noyau Linux parce qu’il y a une faille sur une fonctionnalité que nous n'utilisons pas, mais vous comprenez avoir une personne qui compile un noyau qui correspond à notre besoin, ça coûte trop chère alors on utilise un noyau générique qui pèse 150Mo alors que l'on pourrait utiliser un noyau de 50 Mo qui ne demande pas de mise à jour régulière. Je regrettes ces serveur qui ont un Uptime de 3000 jours, car ayant un noyau optimisé pour leur matériel et n'utilisant pas le chargement dynamique de module du noyau Linux, n'ont pas de failles du moins connue...
9  0 
Avatar de vanquish
Membre chevronné https://www.developpez.com
Le 25/01/2022 à 10:52
Je suis dans le gratuit (pas l'open source) et je suis régulièrement confronté au problème.
C'est toujours un peu désagréable mais très compréhensible.
Déjà généralement votre interlocuteur est dans la structure depuis 3 ans, alors que le produit est là depuis 15.
Il sait que c'est là, mais n'a aucune idée du modèle économique, parce que ce n'est pas son boulot et qu'il a 150 autres sous-système qu'il ne fait que superviser.

Et en vrai, c'est rarement une question d'argent.
Quand on lui explique que c'est gratuit, ça lui pose souvent un problème, car gratuit cela veux dire pas de contrat et donc personne sur qui rejeter la responsabilité en cas de problème.
Il en a, rétrospectivement, des sueurs froides.
Certains utilisateurs qui pourraient avoir le produit gratuitement préfère payer pour avoir un lien contractuel.
9  1 
Avatar de marsupial
Expert éminent https://www.developpez.com
Le 20/12/2021 à 7:36
Des fois, cela a du bon d'être retraité...

Joyeuses fêtes à tous les admins !
6  0 
Avatar de walfrat
Membre émérite https://www.developpez.com
Le 20/12/2021 à 12:18
Citation Envoyé par Fleur en plastique Voir le message
Ce que ça m'inspire, c'est que Apache et Java, c'est de la M.

Mais surtout, ce qui est de loin le pire, c'est le fait de faire des projets qui incluent je ne sais combien de dépendances externes, et donc la moindre faille dans un composant, même mineur comme ici, met en danger tout le Web parce que je ne sais combien de projets l'incluent par paresse.

De la même manière, la moindre dépendance qui disparaît du jour au lendemain peut empêcher le fonctionnement de milliers de projets, c'était arrivé à Node.Js.

Je sais bien que réinventer la roue n'est pas une bonne chose, mais j'ai toujours milité pour limiter le nombre de dépendances externes dans mes projets. Ma règle d'or : si les doigts d'une main ne suffisent pas à compter les projets externes dont dépendent mon propre projet, c'est qu'il y en a trop et un jour ou l'autre, ça va me péter à la gueule.

On en a ici la preuve.
C'est débile comme raisonnement, la faille de log4j, faut utiliser log4j pour qu'elle soit exploitable.
Avoir log4j dans ton classpath ne rend pas ton application vulnérable.

Et comment compte tu le nombre de projet dont tu dépend ? Spring c'est un projet ? Ou tu compte un projet par Spring-context,Spring-orm,Spring-tx ?

Tu compte Apache tomcat comme une dépendance dans ton projet ? Et l'OS de déploiement c'est aussi une dépendance ?

Enfin, entre ton codage, et celui de librairie éprouvé (open source ou non), le tiens aura sans doute largement plus de failles de sécurité.
6  0 
Avatar de tabouret
Membre éclairé https://www.developpez.com
Le 25/01/2022 à 10:24
Quelqu'un peut m'expliquer le lien entre Curl et Log4j?

Sinon on peut aussi demander à Nespresso s'il sont sensibles à Log4j dans la foulée.
6  0 
Avatar de marsupial
Expert éminent https://www.developpez.com
Le 15/12/2021 à 16:15
Pour l'instant l'intéressant avec l'open source est qu'on dispose de patchs rapides. Mais tellement utilisé qu'on est pas loin d'une catastrophe. Log4j n'étant plus amélioré depuis 2013 d'après ce que j'ai compris de ars technica, la faille est exploitée depuis sa révélation et le patch 2.16.0 est urgent pour être utilisé sans risque. La faille date de 2013 et n'a été découverte que le 23 novembre 2021 par des chercheurs en sécurité d'Alibaba.
5  0 
Avatar de grunk
Modérateur https://www.developpez.com
Le 15/12/2021 à 17:03
Si on pouvait supprimer la mention "Apache" quand on parle de Log4J svp ... j'en peux plus de devoir expliquer que les serveurs web Apache n'ont rien à voir avec cette faille et que non ca ne sert à rien de tous les couper tant qu'on aura pas patcher votre application web qui n'est de toute manière pas concernée
5  0 
Avatar de chrtophe
Responsable Systèmes https://www.developpez.com
Le 20/12/2021 à 8:45
Quand on utilise Java le samedi à Broadway, ça hacke comme à Meudon.
6  1 
Avatar de marsupial
Expert éminent https://www.developpez.com
Le 20/12/2021 à 9:44
Si à chaque faille découverte on devait tout jeter, on retourne à la machine à écrire. Plus de 60 000 failles logicielles découvertes en un an(source dvp) , personne n'est épargné.
5  0 
Avatar de Escapetiger
Expert éminent https://www.developpez.com
Le 24/12/2021 à 13:34
Nous sommes dans un forum spécialisé mais tout de même pour une question de clarté avec tous ces sigles :

IPS
« Un système de prévention d'intrusion (ou IPS, intrusion prevention system) est un outil des spécialistes en sécurité des systèmes d'information, similaire aux systèmes de détection d'intrusion (ou IDS, intrusion detection system), permettant de prendre des mesures afin de diminuer les impacts d'une attaque. C'est un IDS actif, il peut par exemple détecter un balayage automatisé malveillant, et bloquer les ports.

Les IPS peuvent donc parer les attaques connues et inconnues. Comme les IDS, ils ne sont pas fiables à 100 % et risquent même en cas de faux positif de bloquer du trafic légitime.
(.../...) »

EDR
« Un logiciel de type EDR désigne une technologie émergente de détection des menaces sur les EndPoints (ordinateurs, serveurs). Ce terme Endpoint Detection and Response (EDR), est utilisé pour la première fois en juillet 2013 par Anton Chuvakin1 de la société Gartner.
(.../...)
Combiné avec un moteur basé sur de l'intelligence artificielle, le logiciel EDR est très réactif dans la détection et l'arrêt de menaces (Malwares, virus, attaques zero Day, menaces persistantes avancées, ...). L'intelligence artificielle lui permet d'être auto-apprenant et de ne pas devoir se connecter sur internet pour mettre à jour des bases de données.
»

Sources Wikipedia :

Système de prévention d'intrusion

Endpoint detection and response
5  0