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 !

Une vulnérabilité Log4J extrêmement critique met une grande partie d'Internet en danger

Le , par you.baddi

45PARTAGES

6  0 
L'Apache Software Foundation a publié des correctifs pour contenir une vulnérabilité zero-day activement exploitée affectant la bibliothèque de journalisation Apache Log4j Java largement utilisée qui pourrait être militarisée pour exécuter du code malveillant et permettre une prise de contrôle complète des systèmes vulnérables.

Suivi comme CVE-2021-44228 et par les surnoms Log4Shell ou LogJam, le problème concerne un cas d'exécution de code à distance (RCE) non authentifié sur toute application qui utilise l'utilitaire open-source et affecte les versions Log4j 2.0-beta9 jusqu'à 2.14. 1. Le bogue a obtenu un score parfait de 10 sur 10 dans le système d'évaluation CVSS, ce qui indique la gravité du problème.

"Un attaquant qui peut contrôler les messages de journal ou les paramètres de message de journal peut exécuter du code arbitraire chargé à partir de serveurs LDAP lorsque la substitution de recherche de message est activée", a déclaré la Fondation Apache dans un avis. "À partir de Log4j 2.15.0, ce comportement a été désactivé par défaut."

Sauvegardes automatiques GitHub
L'exploitation peut être réalisée par une seule chaîne de texte, ce qui peut déclencher une application pour atteindre un hôte externe malveillant s'il est connecté via l'instance vulnérable de Log4j, donnant effectivement à l'adversaire la possibilité de récupérer une charge utile à partir d'un serveur distant et l'exécuter localement. Les responsables du projet ont crédité Chen Zhaojun de l'équipe de sécurité du cloud d'Alibaba d'avoir découvert le problème.

Log4j est utilisé comme package de journalisation dans une variété de logiciels populaires différents par un certain nombre de fabricants , notamment Amazon, Apple iCloud, Cisco , Cloudflare , ElasticSearch, Red Hat , Steam, Tesla, Twitter et des jeux vidéo tels que Minecraft . Dans le cas de ce dernier, les attaquants ont pu obtenir un RCE sur les serveurs Minecraft en collant simplement un message spécialement conçu dans la boîte de discussion.

Une immense surface d'attaque
« La vulnérabilité zero-day d'Apache Log4j est probablement la vulnérabilité la plus critique que nous ayons vue cette année », a déclaré Bharat Jogi, responsable principal des vulnérabilités et des signatures chez Qualys. "Log4j est une bibliothèque omniprésente utilisée par des millions d'applications Java pour la journalisation des messages d'erreur. Cette vulnérabilité est insignifiante à exploiter."

Les entreprises de cybersécurité BitDefender , Cisco Talos , Huntress Labs et Sonatype ont toutes confirmé des preuves d' une analyse massive des applications affectées à l'état sauvage pour les serveurs vulnérables et les attaques enregistrées contre leurs réseaux de pots de miel suite à la disponibilité d'un exploit de preuve de concept ( PoC ). "Il s'agit d'une attaque peu qualifiée qui est extrêmement simple à exécuter", a déclaré Ilkka Turunen de Sonatype.

GreyNoise, comparant la faille à Shellshock , a déclaré avoir observé une activité malveillante ciblant la vulnérabilité à partir du 9 décembre 2021. La société d'infrastructure Web Cloudflare a noté qu'elle bloquait environ 20 000 demandes d'exploitation par minute vers 18h00 UTC vendredi, avec la plupart des tentatives d'exploitation en provenance du Canada, des États-Unis, des Pays-Bas, de la France et du Royaume-Uni

Compte tenu de la facilité d'exploitation et de la prévalence de Log4j dans l'informatique d'entreprise et DevOps, les attaques dans la nature visant les serveurs sensibles devraient s'intensifier dans les prochains jours, ce qui rend impératif de corriger la faille immédiatement. La société de cybersécurité israélienne Cybereason a également publié un correctif appelé « Logout4Shell » qui comble la lacune en utilisant la vulnérabilité elle-même pour reconfigurer l'enregistreur et empêcher une nouvelle exploitation de l'attaque.

"Cette vulnérabilité Log4j (CVE-2021-44228) est extrêmement grave. Des millions d'applications utilisent Log4j pour la journalisation, et tout ce que l'attaquant a à faire est de faire en sorte que l'application enregistre une chaîne spéciale", a déclaré l' expert en sécurité Marcus Hutchins dans un tweet.

source : thehackernews

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

Avatar de Stéphane le calme
Chroniqueur Actualités https://www.developpez.com
Le 25/01/2022 à 9:00
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 »

Daniel Stenberg, le créateur de cURL, a reçu un courriel en provenance d'une entreprise appartenant au Fortune 500, le classement des 500 premières entreprises américaines classées selon l'importance de leur chiffre d'affaires. Ladite entreprise (ou ses clients) utilisait probablement cURL et, dans le contexte de la vulnérabilité dans la bibliothèque de journalisation Apache log4j, lui a posé une série de questions pour savoir entre autres si cURL s'appuyait sur log4j. « Si vous êtes une entreprise de plusieurs milliards de dollars et que vous êtes préoccupé par log4j, pourquoi ne pas simplement envoyer un e-mail aux auteurs OSS à qui vous n'avez jamais rien payé et exiger une réponse gratuite dans les 24 heures avec beaucoup d'informations ? » a-t-il demandé en présentant le courriel qu'il a reçu

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

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

Des correctifs ont été proposés mais, tour à tour, il a été découvert des faiblesses dans leurs réponses. Au total, les chercheurs ont découvert quatre vulnérabilités en prenant en considération les surfaces d'attaques laissées par trois correctifs proposés pour combler la même faille.

Le créateur de cURL interrogé

cURL (abréviation de client URL request library : « bibliothèque de requêtes aux URL pour les clients » ou see URL : littéralement « voir URL ») est une interface en ligne de commande, destinée à récupérer le contenu d'une ressource accessible par un réseau informatique. La ressource est désignée à l'aide d'une URL et doit être d'un type supporté par le logiciel. Le logiciel permet de créer ou modifier une ressource (contrairement à wget), il peut ainsi être utilisé en tant que client REST.

Le programme cURL implémente l'interface utilisateur et repose sur la bibliothèque logicielle libcurl, développée en langage C. Celle-ci est ainsi accessible aux développeurs qui veulent disposer des fonctionnalités d'accès au réseau dans leurs programmes. Des interfaces ont été créées dans de nombreux langages (C++, Java, .NET, Perl, PHP, Ruby...).

La bibliothèque supporte notamment les protocoles DICT, file, FTP, FTPS, Gopher, HTTP, HTTPS, IMAP, IMAPS, LDAP, LDAPS, POP3, POP3S, RTSP, SCP, SFTP, SMB, SMBS, SMTP, SMTPS, Telnet et TFTP.

Son créateur, Daniel Stenberg, a été contacté dans le contexte de la faille log4j par une entreprise disposant d'une capitalisation boursière lui permettant de figurer dans le Fortune 500. Dans un billet de blog, il a indiqué :

« Le vendredi 21 janvier 2022, j'ai reçu cet e-mail. J'ai tweeté à ce sujet et ça a décollé.

« L'e-mail provient d'une entreprise multimilliardaire figurant dans le Fortune 500 qui pourrait apparemment utiliser un produit contenant mon code, ou peut-être qu'ils ont des clients qui le font. Qui sait?

« Je suppose qu'ils le font pour des raisons de conformité et qu'ils ont "oublié" que leurs composants open source ne sont pas automatiquement fournis par des "partenaires" auxquels ils peuvent simplement demander ces informations.

« J'ai répondu très brièvement à l'e-mail et j'ai dit que je serais heureux de répondre avec des détails dès que nous aurons signé un contrat de support.

« Je pense que cela est peut-être un bon exemple de la pyramide open source et que les utilisateurs des couches supérieures ne pensent pas du tout à la façon dont les couches inférieures sont maintenues. Construire une maison sans se soucier du sol sur lequel se trouve la maison ».


Dans son tweet et dans son billet de blog, il supprime le nom de l'entreprise et en donne les raisons : « J'ai très probablement le droit de vous dire qui ils sont, mais je préfère quand même ne pas le faire. (Surtout si je parviens à décrocher un contrat commercial rentable avec eux.) Je pense que nous pouvons trouver ce niveau de droit dans de nombreuses entreprises ».

Et de continuer en ces termes :

« Le niveau d'ignorance et d'incompétence montré dans ce seul e-mail est ahurissant.

« Bien qu'ils ne disent même pas spécifiquement quel produit ils utilisent, aucun code avec lequel j'ai jamais été impliqué ou dont j'ai les droits d'auteur n'utilise log4j et n'importe quel débutant ou meilleur ingénieur pourrait facilement le vérifier.

« Dans la version image de l'e-mail, j'ai complété les champs de nom pour mieux anonymiser l'expéditeur, et dans le texte ci-dessous, je les ai remplacés par NNNN. (Et oui, il est très curieux qu'ils envoient des requêtes sur log4j maintenant, apparemment très tard.) »

Les courriels

Citation Envoyé par L'entreprise
Cher partenaire de l'équipe Haxx,

Vous recevez ce message car NNNN utilise un produit que vous avez développé. Nous vous demandons d'examiner et de répondre dans les 24 heures suivant la réception de cet e-mail. Si vous n'êtes pas la bonne personne, veuillez transmettre ce message au contact approprié.

Comme vous le savez peut-être déjà, une vulnérabilité zero-day récemment découverte affecte actuellement la bibliothèque de journalisation Java Apache Log4j à l'échelle mondiale, permettant potentiellement aux attaquants de prendre le contrôle total des serveurs concernés.

La sécurité et la protection des informations confidentielles de nos clients sont notre priorité absolue. En tant que partenaire clé au service de nos clients, nous devons comprendre vos plans de risque et d'atténuation de cette vulnérabilité.

Veuillez répondre aux questions suivantes en utilisant le modèle fourni ci-dessous.

1. Si vous utilisez une bibliothèque de journalisation Java pour l'une de vos applications, quelles versions de Log4j sont en cours d'exécution ?

2. Y a-t-il eu des incidents de sécurité confirmés dans votre entreprise ?

3. Si oui, quels applications, produits, services et versions associées sont impactés ?

4. Certains produits et services NNNN ont-ils été touchés ?

5. Les informations non publiques ou personnelles de NNNN ont-elles été affectées ?

6. Si oui, veuillez fournir immédiatement les détails des informations concernées NNNN.

7. Quel est le délai (MM/JJ/AA) pour terminer la correction ? Énumérez les étapes NNNN, y compris les dates pour chacune.

8. Quelle action est requise de la part de NNNN pour terminer cette correction ?

Dans un effort pour maintenir l'intégrité de cette enquête, nous vous demandons de ne pas partager les informations relatives à NNNN en dehors de votre entreprise et de réserver cette demande au personnel concerné uniquement.

Merci d'avance pour votre prompte attention à cette demande et votre partenariat !

Sincèrement,

Sécurité des informations NNNN

Les informations contenues dans ce message peuvent être CONFIDENTIELLES et sont destinées uniquement au destinataire prévu. Toute utilisation non autorisée, diffusion des informations ou copie de ce message est interdite. Si vous n'êtes pas le destinataire prévu, veuillez en informer immédiatement l'expéditeur et supprimer ce message.
Le 24 janvier, le père de cURL a reçu cette réponse, de la même adresse et elle cite sa réponse :

Citation Envoyé par Entreprise
Salut David,

Merci pour votre réponse. Êtes-vous en train de dire que nous ne sommes pas un client de votre organisation ?

/ [prénom de la personne qui s'adresse à David]
Le père de cURL a de nouveau répondu (22h29 CET le 24 janvier) à ce courriel qui l'identifiait comme étant "David". Etant donné qu'il y a une histoire à propos d'un David qui a affronté le géant Goliath, il n'a pas pu s'empêcher d'en faire une blague :

Citation Envoyé par Daniel Stenberg
Salut Goliath,

Non, vous n'avez aucun contrat établi avec moi ou toute autre personne chez Haxx à qui vous avez adressé cet e-mail, demandant beaucoup d'informations. Vous n'êtes pas notre client, nous ne sommes pas votre client. De plus, vous n'avez pas précisé de quel produit il s'agissait.

Ainsi, nous pouvons soit établir une telle relation, soit vous êtes libre de chercher vous-même des réponses à vos questions.

Je ne peux que présumer que vous avez intégré notre adresse e-mail et nos coordonnées dans vos systèmes, car nous produisons de nombreux logiciels open source largement utilisés.

Meilleurs vœux,
Daniel
Source : Daniel Stenberg (billet de blog, Tweet)

Et vous ?

Que pensez-vous de la démarche de l'entreprise du Fortune 500 ?
Que pensez-vous de la réponse de David Stenberg ?

Voir aussi :

GitHub restaure le compte du dev qui a intentionnellement corrompu ses bibliothèques, certains développeurs estiment que la suspension était déraisonnable puisqu'il s'agissait de son propre code
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
24  0 
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.
8  1 
Avatar de marsupial
Expert confirmé 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 chevronné 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 confirmé 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 confirmé 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