5 questions sur « Log4Shell », la faille informatique qui menace des milliers d'entreprises

Des milliers d'entreprises sont affectées par une vulnérabilité grave, fraîchement découverte dans la bibliothèque logicielle Log4j. Si des correctifs existent déjà pour réparer la faille, des cybercriminels tentent de profiter qu'ils ne soient pas encore déployés pour infecter leurs victimes avec des logiciels malveillants. Explications.
François Manens
Log4Shell concerne des milliers d'entreprises.
Log4Shell concerne des milliers d'entreprises. (Crédits : Kacper Pempel)

Mauvaise nouvelle pour les défenseurs. Ce 10 décembre, l'Agence nationale de la sécurité des systèmes d'information (Anssi), a publié une alerte au sujet d'une vulnérabilité dans Apache Log4j, un composant logiciel utilisé par des milliers d'entreprises.

Cette faille, baptisée « Log4Shell », permet à des attaquants de prendre le contrôle de l'appareil visé. Autrement dit, elle pourrait leur permettre d'infecter des milliers d'entreprises et autres organisation. Heureusement, l'Apache Software Foundation a déjà publié une mise à jour pour corriger la faille. Désormais, les équipes de cybersécurité sont engagées dans un contre-la-montre : elles doivent déployer la mise à jour avant que les attaquants n'exploitent la faille. Pour mieux comprendre la crise qui se profile, nous avons sélectionné 5 questions, et y avons répondu.

Qu'est ce que Log4Shell ?

Log4Shell (suivi sous l'identifiant CVE-2021-44228) est une vulnérabilité zero-day, c'est-à-dire une faille informatique qui n'avait pas de correctif quand elle a été découverte. Concrètement, des hackers peuvent la viser avec une cyberattaque pour prendre le contrôle à distance d'un appareil ou d'une application.

La vulnérabilité se trouve dans une bibliothèque logicielle Java nommée Log4j, un ensemble de fichiers très couramment utilisé pour gérer la journalisation, c'est-à-dire l'historique des actions effectuées sur une application.

Log4Shell a été rendue publique sur Twitter le 9 décembre par un chercheur chinois, dans un message accompagné d'une preuve de concept (POC), c'est-à-dire d'une démonstration de l'exploitation de la faille. De plus, le chercheur a déposé le code de sa POC sur la plateforme de partage Github.

Comment Log4Shell est-elle exploitée ?

Pour utiliser la faille à leurs fins, les hackers créent une requête (c'est-à-dire une commande sous forme de code informatique) spécifique, puis l'envoient à l'application visée. Lorsque l'application va essayer de "journaliser" la requête, l'attaque va se déclencher.

D'après les chercheurs de LunaSec, les attaquants pourront ensuite forcer l'appareil sur lequel tourne Log4j à télécharger un logiciel malveillant. Ils pourront enfin se servir de ce dernier (un shell, dans le jargon) pour lancer des commandes sur l'appareil ou l'application infecté, depuis une machine en leur possession. A partir de là, ils auront la possibilité de commettre tous types de méfaits, du simple vol de données au déploiement d'un rançongiciel.

Qui est concerné ?

Des milliers d'entreprises, organisations et administrations, et par conséquent leurs clients. Log4j est inclus dans la quasi-totalité des suites logicielles de l'Apache Software Foundation (utilisées dans les serveurs web), ainsi que dans d'autres projets open-source comme ElasticSearch (gestion de base de données). Plus de 3 milliards de machines utilisent Java, et bon nombre d'entre elles emploient Log4j.

Le problème, c'est que si certaines grosses organisations ont conscience qu'elles utilisent Log4j, ce n'est pas le cas d'une majorité. Or, impossible pour elles de réparer un problème dont elles n'ont pas conscience. C'est pourquoi l'Anssi recommande de « prendre contact avec le développeur ou l'éditeur pour vérifier s'ils sont exposés à cette vulnérabilité et si un correctif est disponible. »

De premières recherches, repérées par The Recordont identifié des entreprises qui possèdent des serveurs vulnérables à l'attaque : Apple, Amazon, Twitter, Cloudflare, ou encore Tendent et Baidu. Des milliers d'autres devraient également être concernées.

Est-ce grave ?

Oui : la faille a reçu le score maximal de 10/10 sur CVSSv3, l'échelle de criticité de référence en cybersécurité. Deux raisons à cette note :

  • Log4Shell peut être exploitée à distance, ce qui signifie qu'un attaquant n'a qu'à interagir avec un appareil vulnérable depuis chez lui pour le pirater. Par conséquent, il peut viser des milliers d'appareils à la fois.
  • Pas besoin de compétences techniques vraiment avancées pour exploiter la faille, d'autant plus que des preuves de concept circulent déjà en ligne.

La situation est d'autant plus préoccupante que les entreprises Bad Packets et Greynoise ont observé que certains acteurs malveillants scannent déjà Internet à la recherche de serveurs vulnérables à l'attaque. Autrement dit, la course entre défenseurs et attaquants a déjà commencé, et ces derniers ont pris de l'avance.

Comment s'en protéger ?

Apache Software Foundation, l'organisation éditrice de Log4j, a publié en urgence, ce 10 décembre un correctif de sécurité. Les versions à jour (à partir de la 2.15.0) de Log4j ne sont donc plus vulnérables à l'attaque.

Mais il existe aussi un moyen d'ajuster Log4j pour se protéger de l'attaque. Le chercheur qui a publié la preuve de concept précise que les attaques ne fonctionnent que si une option contenue dans Log4j est désactivée. Il suffit donc de l'activer, ce que seront faire une majorité d'éditeurs.

Le problème, comme souvent en cybersécurité, c'est que les mises à jour ne sont pas immédiates dans de nombreuses organisations. Et puisque la vulnérabilité a été découverte la veille du week-end, il est probable que des entreprises ne la corrigent pas avant lundi, voire plus longtemps.

François Manens

Sujets les + lus

|

Sujets les + commentés

Commentaire 0

Votre email ne sera pas affiché publiquement.
Tous les champs sont obligatoires.

Il n'y a actuellement aucun commentaire concernant cet article.
Soyez le premier à donner votre avis !

-

Merci pour votre commentaire. Il sera visible prochainement sous réserve de validation.