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 !

Plus de 35 000 packages Java impactés par les vulnérabilités Log4j, selon un rapport de l'équipe open source de Google

Le , par Stéphane le calme

259PARTAGES

13  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
Vous avez lu gratuitement 6 articles depuis plus d'un an.
Soutenez le club developpez.com en souscrivant un abonnement pour que nous puissions continuer à vous proposer des publications.

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

Avatar de gabriel21
Membre chevronné 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 A3gisS3c
Membre expérimenté 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 Escapetiger
Expert éminent sénior 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 
Avatar de sekaijin
Expert éminent https://www.developpez.com
Le 24/12/2021 à 16:40
Lister les dépendances par transitivité pour connaitre les projet "Potentiellement" impactés
N'est en soit pas très compliqué mais très largement insuffisant surtout si on fait ça sur maven central.
En effet Maven Central garde aussi toute les vielles versions donc même s'il y a eu des corrections les version non corrigé restent.

On peut très vite avoir des chiffres énorme sans pour autant que ce soit la cata.

Quant à ce que que j'ai lu ici sur YAKAFOKON c'est très loin d'être si facile. Je m'occupe d'un outil qui est composé de centaines d'éléments divers avec un chargement dynamique la bête a tourné 8 ans sans interruption, avec des mise à jour à chaud, un changement de serveur physique à chaud (juste des arrêts partiels de certain composants quelques minutes).
Arriver à qualifier la compatibilité de plusieurs centaines de composants est un très long travail. Il nous est déjà arrivé de revenir en arrière après plusieurs mois de travail parce qu'un composants n'était plus compatible avec l'ensemble.

Quant à l'approche de google si j'avais suivi la même approche j'aurais à ce jour environs 200 projet impactés.
Hors tous dépendent d'une librairie qui est compilé avec log4j (donc une dépendance). Mais cette librairie importe une partie seulement de log4j et supprime tout le code inutile. La partie impactée par le PB de sécurité n'est plus dans le code de la lib. les 200 projets ne sont donc pas impactés.

à contraio je suis tombé sur un dev qui importe par transitivité un clone de log4j qui lui embarque le code en question et là l'approche de Google ne l'a pas trouvé et pour cause. Ouf il s'agissait d'un démonstrateur pas de prod.

Donc à tous les YAKAFOKON Oui il est très simple dans le gestionnaire de dépendance de surcharger la version de log4j pour en choisir une non impactée.
Mais sur les millions de lignes de code comment garantir que ce changement ne va pas introduire de bug ?
On pourrait imaginer que finalement ce ne sont que des log c'est pas si grave si on n'a pas la trace tant que le prog fonctionne mais voilà un changement de version de log4j sans précaution et up un nullpointerexception dans un log.info et le prog ne fonctionne plus.

Il n'y a rien de simple. C'est un travail permanent, une vigilance, et des mois de tests pour valider un assemblage.

A+JYT
5  0 
Avatar de TJ1985
Membre chevronné https://www.developpez.com
Le 14/01/2022 à 9:34
C'est ce qui m'a toujours effrayé lorsque j'ai assisté à l'explosion des bibliothèques et plateformes en ligne. Pour avoir commis une fois un bug dans une librairie partagée, je mesure pleinement l'impact que ça peut avoir. Là, j'avais encore la main dessus, et sur l'ensemble des applications qui l'utilisaient et ça a quand même fait des dégâts. Mais si elle avait été lâchée dans la nature... à moi la peur !
J'ai l'impression que nous avons perdu la tête. Toutes les entreprises ne font pas du commerce en ligne, toutes n'ont pas besoin d'un cloud externe et beaucoup bénéficieraient des services d'un bon analyste bien plus que d'une SSII avide de rentabilité - pour elle-même.
6  1 
Avatar de gabriel21
Membre chevronné https://www.developpez.com
Le 25/01/2022 à 11:36
Le mail ressemble beaucoup à des mails que je peux voir passé en interne ou du client quand le service SSI panique et comme il savent pas où ils habitent, ni ce que font les administrateurs et les développeurs, ils leurs posent la totalité des questions que le RSSI ou tout autre directeur leur a posé.
L'affaire est cocasse, surtout la réponse... Ah bon, vous ne travaillez pas pour nous...
Il s'agit là plus d'une incompétence personnel que d'une société, même si l'ultra procéduralisation et les équipes aux périmètres restreints et hermétiques peuvent être la cause profonde de ce genre de situation.
J'ai par exemple eu le cas d'une demande pour savoir si on avait bien patché une vulnérabilité noyau Windows sur nos serveurs applicatifs qui tournaient sur RHEL et AIX....
Des perles de ce type, j'en vois malheureusement très souvent.
5  0 
Avatar de dolu02
Membre averti https://www.developpez.com
Le 25/01/2022 à 10:47
Citation Envoyé par walfrat Voir le message
Personnellement je demande a voir la fin de l'histoire avant de basher la société.

Le premier mail de la société peut paraître agressif et stupide mais ça peut ni plus ni moins venir de personnes qui font ce genre de mail aussi bien à des sociétés privés sous contrat qu'a des gens du monde open source sans contrat, car ils ignorent la différence.

En outre le second mail de la société me paraît être un signe qu'ils sont pas si mal tombé.
C'est justement ce qui leur est reproché, d'être ignorants. S'ils ont des IT en interne (on peut le supposer pour une telle entreprise), pourquoi ne pas leur demander ce qu'il faut faire?
5  1 
Avatar de valtena
Membre confirmé https://www.developpez.com
Le 26/01/2022 à 15:06
Citation Envoyé par AoCannaille Voir le message
Le ton n'est pas arrogant, le mail est lisse, factuel et surtout impersonnel. En un mot : Une communication Professionnelle. Si tu trouve ce mail arrongant, j'espère que tu ne travaille pas dans des grosses boites car c'est tout simplement la seule méthode qu'ils ont pour communiquer par écrit.
Le mail arrive avec pas mal d'impératif. Quand tu lis la tournure du mail la réponse est due. C'est assez arrogant en dehors d'un lien de subordination. Qu'il soit lissé et automatisé n'enlève rien à la chose.
5  1 
Avatar de gabriel21
Membre chevronné https://www.developpez.com
Le 22/12/2021 à 12:23
Citation Envoyé par tabouret Voir le message
Un uptime de 300 jours est inconcevable d'un point de vue sécurité.
Peux tu expliquer en quoi c'est un problème de sécurité?
Si tu as :
- un noyau dédié qui n'embarque que le nécessaire et surtout pas de modules dynamiques (utile sur les stations de travail, inutile sur les serveurs);
- pas de mise à jour de sécurité sur les parties intégrés au noyau;
- pas besoin des nouvelles fonctionnalités;
- pas besoin des optimisations.

Il s'agit là de préconisations faite par l'ANSI, il y a encore 3 ans, lors d'un audit de sécurité sur les serveurs d'un OIV. L'agence disait déjà ça, il y a 20 ans pour les Unix, Linux, tout en conseillant l'application immédiates des patchs utiles avec redémarrage si nécessaire, voir passage sur ban de test pour certains serveurs industriels dont un arrêt brutal peux avoir des conséquences dramatiques.

Le fait que la majorité des patchs Windows nécessite un redémarrage est une problématique interne à Microsoft et effectivement sous Windows un Uptime de plus de 35 jours est purement suicidaire. Chez certains OIV, les serveurs Windows redémarrent automatiquement tous les 30 jours, ce qui est assez rare car finalement, la plupart serveurs ont tendance à être redémarré tous les 15 jours. C'est d’ailleurs une des raisons qui font que je me suis spécialisé sous Linux.
4  1