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 !

Le premier correctif de la vulnérabilité critique zero day Log4J a sa propre vulnérabilité qui est déjà exploitée
Les entreprises sont exhortées à utiliser le second

Le , par Stéphane le calme

112PARTAGES

11  0 
Depuis que la vulnérabilité a été découverte la semaine dernière, le monde de la cybersécurité est passé à la vitesse supérieure pour identifier les applications vulnérables, détecter les attaques potentielles et atténuer les exploits autant que possible. Néanmoins, les hacks sérieux utilisant l'exploit sont presque certains.

Jeudi de la semaine dernière, le monde a appris l'exploitation dans la nature d'une faille zero day dans Log4J, un utilitaire de journalisation. Jusqu'à présent, les chercheurs ont observé des attaquants utilisant la vulnérabilité Log4j pour installer des ransomwares sur des serveurs de pots de miel, des machines délibérément rendues vulnérables dans le but de suivre les nouvelles menaces. Une entreprise de cybersécurité a signalé que près de la moitié des réseaux d'entreprise qu'elle surveillait avaient vu des tentatives d'exploitation de la vulnérabilité. Le PDG de Cloudflare, un fournisseur de sécurité de sites Web et de réseaux, a annoncé très tôt que la menace était si grave que l'entreprise déploierait une protection par pare-feu pour tous les clients, y compris ceux qui ne bénéficiaient pas d'une formule payante. Mais les nouvelles concrètes sur l'exploitation dans la nature restent rares, probablement parce que les victimes ne savent pas ou ne veulent pas encore reconnaître publiquement que leurs systèmes ont été violés.

Ce qui est sûr, c'est que la portée de la vulnérabilité est énorme. Une liste des logiciels concernés compilée par la Cybersecurity and Infrastructure Security Agency (CISA) (et limitée aux seules plateformes logicielles d'entreprise) s'étend sur plus de 500 éléments. Une liste de toutes les applications concernées s'étendrait sans aucun doute à plusieurs milliers d'autres.

Certains noms de la liste seront familiers au public (Amazon, IBM, Microsoft), mais certains des problèmes les plus alarmants sont survenus avec des logiciels qui restent dans les coulisses. Des fabricants tels que Broadcom, Red Hat et VMware créent des logiciels sur lesquels les entreprises clientes créent leurs activités, répartissant efficacement la vulnérabilité au niveau de l'infrastructure de base de nombreuses entreprises. Cela rend le processus de détection et d'élimination des vulnérabilités d'autant plus difficile, même après la publication d'un correctif pour la bibliothèque affectée.

Même selon les normes de vulnérabilités très médiatisées, Log4Shell frappe une partie inhabituellement importante d'Internet. Cela reflète le fait que le langage de programmation Java est largement utilisé dans les logiciels d'entreprise, et pour les logiciels Java, la bibliothèque Log4j est extrêmement courante.

« J'ai effectué des requêtes dans notre base de données pour voir chaque client qui utilisait Log4j dans l'une de leurs applications », explique Jeremy Katz, co-fondateur de Tidelift, une entreprise qui aide d'autres organisations à gérer les dépendances des logiciels open source. « Et la réponse était : chacun d'entre eux qui a des applications écrites en Java ».

La découverte d'un bogue facilement exploitable trouvé dans un langage principalement axé sur l'entreprise fait partie de ce que les analystes ont appelé une « tempête presque parfaite » autour de la vulnérabilité Log4j. N'importe quelle entreprise peut utiliser de nombreux programmes contenant la bibliothèque vulnérable (dans certains cas, avec plusieurs versions dans une seule application).

« Java existe depuis de nombreuses années et il est très utilisé dans les entreprises, en particulier les grandes », explique le directeur technique de Cloudflare, John Graham-Cumming. « C'est un grand moment pour les personnes qui gèrent des logiciels au sein des entreprises, et elles exécuteront les mises à jour et les atténuations aussi rapidement que possible. »

Compte tenu des circonstances, « aussi vite qu'elles le peuvent » est un terme très subjectif. Les mises à jour logicielles pour les organisations telles que les banques, les hôpitaux ou les agences gouvernementales sont généralement effectuées à l'échelle des semaines et des mois, et non des jours ; généralement, les mises à jour nécessitent de nombreux niveaux de développement, d'autorisation et de test avant d'être intégrées à une application en direct.


En attendant, les mesures d'atténuation qui peuvent être déployées rapidement constituent une étape intermédiaire cruciale, permettant de gagner un temps précieux tandis que les entreprises, grandes et petites, se démènent pour identifier les vulnérabilités et déployer des mises à jour. C'est là que les correctifs au niveau de la couche réseau ont un rôle clé à jouer : étant donné que les programmes malveillants communiquent avec leurs opérateurs via Internet, les mesures qui restreignent le trafic Web entrant et sortant peuvent constituer un pis-aller pour limiter les effets de l'exploit.

Cloudflare était une organisation qui a évolué rapidement, a expliqué Graham-Cumming, ajoutant de nouvelles règles pour son pare-feu qui bloquaient les requêtes HTTP contenant des chaînes caractéristiques du code d'attaque Log4j. ExpressVPN a également modifié son produit pour se protéger contre Log4Shell, mettant à jour les règles VPN pour bloquer automatiquement tout le trafic sortant sur les ports utilisés par LDAP - un protocole que l'exploit utilise pour récupérer des ressources à partir d'URL distantes et les télécharger sur une machine vulnérable.

« Nous voulions mettre un plafond là-dessus, pas seulement pour le bien de nos clients mais pour le bien de tous les autres – un peu comme avec Covid et les vaccins », explique Membrey.

Au moins deux vulnérabilités existent dans le premier correctif proposé

Les développeurs open source ont rapidement publié une mise à jour qui corrigeait la faille et ont exhorté tous les utilisateurs à l'installer immédiatement.

Après cela, les chercheurs ont signalé qu'il existe au moins deux vulnérabilités dans le correctif, publié sous le nom de Log4J 2.15.0, et que les attaquants exploitent activement l'une d'entre elles ou les deux contre des cibles du monde réel qui ont déjà appliqué la mise à jour. Les chercheurs exhortent les organisations à installer un nouveau correctif, publié en tant que version 2.16.0, dès que possible pour corriger la vulnérabilité, qui est suivie comme CVE-2021-45046.

Le correctif précédent, ont déclaré les chercheurs mardi soir, « était incomplet dans certaines configurations autres que celles par défaut » et permettait aux attaquants d'effectuer des attaques par déni de service, ce qui facilite généralement la mise hors ligne des services vulnérables jusqu'à ce que les victimes redémarrent leur serveurs ou prennent d'autres mesures. La version 2.16.0 « résout ce problème en supprimant la prise en charge des modèles de recherche de messages et en désactivant la fonctionnalité JNDI par défaut », selon l'avis de vulnérabilité lié ci-dessus.

Mercredi, des chercheurs de la société de sécurité Praetorian ont déclaré qu'il y avait une vulnérabilité encore plus grave dans 2.15.0 (une faille de divulgation d'informations qui peut être utilisée pour télécharger des données à partir des serveurs concernés).

« Dans nos recherches, nous avons démontré que la version 2.15.0 peut toujours permettre l'exfiltration de données sensibles dans certaines circonstances », a écrit le chercheur prétorien Nathan Sportsman. « Nous avons transmis les détails techniques du problème à la Fondation Apache, mais dans l'intervalle, nous recommandons fortement aux clients de passer à la version 2.16.0 le plus rapidement possible. »

Les chercheurs n'ont pas fourni de détails supplémentaires sur la vulnérabilité car ils ne voulaient pas fournir d'informations qui permettraient aux pirates de l'exploiter plus facilement. Cependant, ils ont publié la vidéo suivante qui montre leur exploit de preuve de concept en action :


Les chercheurs du réseau de diffusion de contenu Cloudflare, quant à eux, ont déclaré mercredi que CVE-2021-45046 était désormais en exploitation active. La société a exhorté les gens à mettre à jour vers la version 2.16.0 dès que possible.

Le post de Cloudflare n'a pas indiqué si les attaquants utilisent la vulnérabilité uniquement pour effectuer des attaques DoS ou s'ils l'exploitent également pour voler des données.

« Les attaquants sophistiqués exploiteront la vulnérabilité, établiront un mécanisme de persistance, puis disparaîtront »

Une application logicielle obsolète pourrait toujours recevoir un niveau de protection décent d'un VPN mis à jour, même si cela ne remplace pas un correctif approprié.

Malheureusement, étant donné la gravité de la vulnérabilité, certains systèmes seront compromis, même avec des correctifs rapides déployés. Et il peut s'écouler beaucoup de temps, voire des années, avant que les effets ne se fassent pleinement sentir.

« Les attaquants sophistiqués exploiteront la vulnérabilité, établiront un mécanisme de persistance, puis disparaîtront », a déclaré Daniel Clayton, vice-président des services mondiaux de cybersécurité chez Bitdefender. « Dans deux ans, nous entendrons parler de violations importantes, puis nous apprendrons que les données ont été volées il y a deux ans. »

Le bogue de Log4j met une fois de plus en évidence la nécessité et le défi de financer adéquatement les projets open source. Bloomberg a rapporté plus tôt cette semaine que de nombreux développeurs impliqués dans le course pour développer un correctif pour la bibliothèque Log4j étaient des bénévoles non rémunérés, malgré l'utilisation mondiale du logiciel dans les applications d'entreprise.

L'une des dernières vulnérabilités à secouer Internet, Heartbleed, a également été causée par un bogue dans une bibliothèque open source largement utilisée, OpenSSL. À la suite de ce bogue, des entreprises technologiques comme Google, Microsoft et Facebook se sont engagées à investir plus d'argent dans des projets open source essentiels à l'infrastructure Internet. Mais à la suite des retombées de Log4j, il est clair que la gestion des dépendances reste un problème de sécurité sérieux que nous ne sommes probablement pas près de résoudre.

« Lorsque vous regardez la plupart des gros piratages qui se sont produits au fil des ans, ce n'est normalement pas quelque chose de vraiment sophistiqué qui défait les grandes entreprises », explique Clayton. « C'est quelque chose qui n'a pas été corrigé ».

Sources : Cloudflare, GitHub, Praetorian, produits affectés (GitHub CISA)

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

Avatar de gabriel21
Membre éprouvé 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 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 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 
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 
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 chrtophe
Responsable Systèmes https://www.developpez.com
Le 21/12/2021 à 10:56
Est-ce vraiment Java le problème ? ou plutôt l'utilisation de composants externes mal programmée, ou des failles de la JVM ?
Pour ce dernier aspect, les postes faillibles :
- sont-ils à jour au niveau Java ?
- L'utilisation d’une JVM autre que celle d'Oracle est il plus sûr ?
4  0 
Avatar de TJ1985
Membre expérimenté 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.
5  1 
Avatar de gabriel21
Membre éprouvé 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