ALLOT :  Vulnérabilité Zero-Day Log4j, ce que vous devez savoir !

ALLOT :  Vulnérabilité Zero-Day Log4j, ce que vous devez savoir !

560 420 2SB - Distributeur à valeur ajoutée - Solutions de Cybersécurité

On ne s’ennuie jamais dans le domaine de la sécurité.
C’est une bataille constante entre les hackers et les experts en cybersécurité.

Mais, de temps en temps, il y a un événement de sécurité majeur ou la découverte d’une nouvelle vulnérabilité zero-day critique qui peut littéralement détruire Internet!
La vulnérabilité zero-day Log4j, avec un score CVSS parfait de 10.0 et classée comme gravité “Critique”, est l’un de ces méga-événements de sécurité !

Le vendredi 10 décembre, le monde de la sécurité informatique a été secoué par la divulgation de Log4j (CVE-2021-44228), une vulnérabilité zero-day critique dans la bibliothèque de journalisation Java Apache Log4j, largement utilisée, qui permet aux attaquants d’exécuter du code à distance et d’accéder à des machines.

Alors, qu’est-ce que Log4j ? A quoi sert-il ? Pourquoi cette vulnérabilité est-elle si critique ? Que pouvez-vous faire pour vous en protéger ? Dans ce blog, nous vous présenterons des informations sur Log4j, et comment vous pouvez y faire face.

Qu’est-ce que Log4j ?

Apache Log4j est un utilitaire de journalisation basé sur Java, qui fait partie des services de journalisation Apache.
Log4j est utilisé pour la journalisation des capacités ou l’enregistrement d’une activité.
L’utilisation typique de Log4j est la définition des niveaux de journalisation (fatal, erreur, avertissement, etc.), les mécanismes d’écriture dans différents fichiers de journalisation, le dépannage des problèmes ou le suivi des données dans les programmes, les modèles de roulement des journaux, etc.
Le fait que Log4j soit gratuit le rend extrêmement populaire et largement utilisé dans la plupart des services web.

Vulnérabilité de Log4j

Le groupe de bénévoles de l’Apache Software Foundation a été alerté le 24 novembre d’une vulnérabilité dans Log4j, qui a entraîné une exécution de code à distance après qu’un membre de l’équipe de sécurité du cloud d’Alibaba l’ai découverte.

Le 10 décembre, un avertissement inhabituel a provoqué une onde de choc dans la communauté de la cybersécurité après que les fabricants du jeu vidéo Minecraft qui ont partagé la vulnérabilité dans un blog, alertant les joueurs que des hackers avaient identifié une faille dans leur jeu qui pourrait être utilisée pour infiltrer leurs ordinateurs.

Allot_Blog_message_from_minecraft-750

“Bonjour à tous ! Plus tôt dans la journée, nous avons identifié une vulnérabilité sous la forme d’un exploit dans Log4j – une bibliothèque de journalisation Java commune.
Cet exploit affecte de nombreux services, dont Minecraft Java Edition.
Cette vulnérabilité pose un risque potentiel de compromission de votre ordinateur, et bien que cet exploit ait été corrigé avec toutes les versions du client du jeu, vous devez toujours prendre les mesures suivantes pour sécuriser votre jeu et vos serveurs.”

Pourquoi est-ce si important ?

La vulnérabilité Log4j est relativement simple à exploiter et son impact est dramatique.
Par exemple, les attaquants cherchent à prendre position dans les réseaux afin de vendre cet accès aux opérateurs de ransomware.
D’autres attaques peuvent utiliser la vulnérabilité de Log4j pour télécharger un cheval de Troie malveillant, qui peut ensuite déclencher le téléchargement d’un fichier .exe qui peut, à son tour, installer un crypto-miner ou tout autre logiciel malveillant sur l’appareil compromis afin d’accéder aux données et services critiques.

Étant donné que Log4j est intégré dans un large éventail d’applications, de services, de plateformes cloud, d’applications Web, de services de messagerie et d’outils logiciels d’entreprise (écrits en Java) et utilisés par des organisations et des particuliers dans le monde, l’impact potentiel peut toucher des millions d’appareils dans le monde entier.

Attaques dans le monde

Depuis la publication de la vulnérabilité de Log4j, on signale chaque minute des cyberattaquants qui tentent de l’exploiter.
Les attaquants tentent déjà de scanner internet à la recherche d’instances vulnérables de Log4j.

“Plus de 35 000 paquets Java, soit plus de 8 % du dépôt central Maven (le plus important dépôt de paquets Java), ont été touchés par les vulnérabilités Log4j récemment divulguées”, ont écrit James Wetter et Nicky Ringland de l’équipe Open Source Insights de Google dans un blog.

Selon Google, la grande majorité des paquets Java vulnérables dans Maven Central empruntent log4j “indirectement”; c’est-à-dire que log4j est une dépendance d’une dépendance utilisée par le paquet.
Pour plus de clarté, Google a partagé un diagramme simple de cette relation dans son blog.

Allot_blog_direct_indirect_dep_red_shading_from_Google-627

Sur les 35 863 paquets identifiés par Google, environ 7 000 seulement empruntaient directement log4j, ce qui indique que tous les développeurs n’ont peut-être pas une visibilité adéquate de leurs logiciels.
“Le manque de visibilité des utilisateurs sur leurs dépendances et leurs dépendances transitives a rendu difficile l’application de correctifs ; il a également rendu difficile la détermination du rayon d’action complet de cette vulnérabilité”, ont-ils expliqué.

Alors, quel est le meilleur moyen d’atténuer la vulnérabilité de Log4j ?

La vulnérabilité, qui a été publiée sous le nom de CVE-2021-44228, affecte les fonctionnalités JNDI d’Apache Log4j version 2 (2.0 à 2.12.1 et 2.13.0 à 2.15.0) utilisées dans la configuration, les messages de journal et les paramètres, qui ne protègent pas contre le contrôle par un attaquant de LDAP et d’autres terminaux liés à JNDI.

Un attaquant qui peut contrôler les messages de journal ou les paramètres des messages de journal peut exécuter du code arbitraire chargé à partir de serveurs LDAP lorsque la substitution de recherche de message est activée. Depuis Log4j 2.15.0, ce comportement a été désactivé par défaut.

L’Apache Software Foundation a donc publié la version 2.15.0 pour corriger la faille en espérant que le problème est derrière nous.
Mais ce n’est pas le cas…

Quelques jours après la sortie de la version 2.15.0, il a été découvert que cette version est vulnérable aux attaques DoS et vous connaissez la suite… Une nouvelle CVE a été publiée sous le nom de CVE-2021-45046, qui était initialement classée comme étant de gravité “faible” avec un score de risque de base de 3,7, a été modifiée en “critique” avec un score de base de 9,0.
Une nouvelle version 2.16.0 de Log4j a été publiée pour corriger cette vulnérabilité.

Nous avons désormais la version 2.16.0, qui “corrige tout”.
Donc, on peut penser que cette crise est derrière nous. Mais, nous avons dit que c’est une bataille sans fin?

La version 2.16.0 s’est avérée également vulnérable aux attaques DoS et cette fois, elle a été classée comme “élevée” avec un score CVSS de base de 7,5 sous CVE-2021-45105.

Pour corriger cette vulnérabilité, la version 2.17.0 de log4j (pour Java 8) a été publiée et permet uniquement l’expansion récursive des “chaînes de recherche dans la configuration”.
Dans toute autre utilisation, seule la recherche de niveau supérieur est résolue et non les recherches imbriquées.

Le point de vue d’Allot

Une fois la vulnérabilité de Log4j découverte, les experts en cybersécurité d’Allot l’ont analysée pour voir si les solutions Allot (composées d’Allot Smart et d’Allot Secure) étaient vulnérables et un avis de sécurité a été publié pour y remédier.
Après une analyse approfondie des solutions et services d’Allot destinés aux FSC et aux entreprises, il a été déterminé que la grande majorité d’entre eux n’étaient pas vulnérables.
Un correctif a été immédiatement publié pour corriger les composants vulnérables.

Je recommande vivement la mise en œuvre des correctifs, non seulement pour les produits Allot, mais aussi pour tout produit déployé sur le réseau qui dispose d’un correctif ou d’un correctif pour combler cette vulnérabilité critique.

En outre, il est fortement recommandé de déployer des règles de système de prévention des intrusions (IPS) pour détecter et prévenir les modèles d’attaque.
En raison de la nature critique de cette vulnérabilité, Allot a ajouté une nouvelle signature à ses plateformes d’intelligence réseau, déployées en ligne dans les FSC et les réseaux d’entreprise.
La nouvelle signature est disponible en tant que correctif “à chaud” sous ERT-PP 3.153.90 pour détecter les attaques Log4j et ajouter une autre couche de protection à vos appareils, services et applications qui utilisent Log4j et sont exposés à la vulnérabilité.

La nouvelle détection des attaques Log4j est également disponible dans la prochaine mise à jour du protocol pack, prévue le 22 décembre.

Source : Allot

En savoir plus concernant les solutions Allot : Ici
Contactez-nous : ici