Comment les équipes de sécurité de Cloudflare ont réagi à la vulnérabilité de Log4j 2

Chez Cloudflare, lorsque nous découvrons l’existence d’une nouvelle faille de sécurité, nous réunissons rapidement des équipes pour répondre à deux questions distinctes : (1) que pouvons-nous faire pour nous assurer que les infrastructures de nos clients sont protégées, et (2) que pouvons-nous faire pour nous assurer que notre propre environnement est sécurisé. Hier, le 9 décembre 2021, lorsqu’une grave vulnérabilité du célèbre package de journalisation Java Log4j a été publiquement divulguée, nos équipes de sécurité sont entrées en action pour aider à répondre à la première question, puis répondre à la seconde. Cette publication explore la seconde.

Nous examinons les détails du fonctionnement de cette vulnérabilité dans une publication de blog distincte (Examen de la vulnérabilité Log4j2 (CVE-2021-44228)), mais en résumé, cette vulnérabilité permet à un acteur malveillant d’exécuter du code sur un serveur distant. En raison de l’utilisation répandue de Java et de Log4j, il s’agit probablement de l’une des vulnérabilités les plus graves sur Internet depuis Heartbleed et ShellShock. La vulnérabilité est répertoriée sous la référence CVE-2021-44228. La description CVE indique que la vulnérabilité affecte les versions Log4j2 <= 2.14.1 et qu’elle est corrigée dans la version 2.15. La vulnérabilité affecte également toutes les versions de Log4j 1.x ; toutefois, cette version a atteint la fin de vie et comporte d’autres failles de sécurité qui ne seront pas corrigées. La mise à jour vers la version 2.15 est l’action recommandée. Vous pouvez également lire comment nous avons mis à jour les règles de pare-feu WAF pour aider à protéger nos clients dans cette publication : Atténuation de la vulnérabilité RCE zero-day de Log4j –CVE-2021-44228

Une des premières choses que nous faisons lorsque nous répondons à un incident est de commencer à établir une chronologie des événements que nous devons examiner et comprendre dans le contexte de la situation. Voici des exemples tirés de notre chronologie de cet événement :

• 09-12-2021 16:57 UTC - Réception sur developers.cloudflare.com d’un rapport de Hackerone concernant la vulnérabilité RCE de Log4j

• 10-12-2021 09:56 UTC - Transmission de la première règle de pare-feu WAF à l’ensemble de règles Cloudflare Specials

• 10-12-2021 10:00 UTC - Ouverture d’un INCIDENT de développement formel ; le travail commence pour identifier les éléments de Log4j que nous devons corriger

• 10-12-2021 10:33 UTC - Déploiement de Logstash avec un correctif pour atténuer la vulnérabilité

• 10-12-2021 10:44 UTC - La deuxième règle de pare-feu WAF est en ligne, intégrée aux règles gérées de Cloudflare

• 10-12-2021 10:50 UTC - Début du redémarrage d’ElasticSearch avec un correctif pour atténuer la vulnérabilité

• 10-12-2021 11:05 UTC - Fin du redémarrage d’ElasticSearch, qui n’est plus vulnérable

• 10-12-2021 11:45 UTC - Bitbucket a reçu un correctif et n’est plus vulnérable

• 10-12-2021 21:22 UTC - Clôture et classement comme Information du rapport de Hackerone après qu’il ait été impossible de reproduire l’incident

Une question importante lorsque l’on remédie à une vulnérabilité d’un logiciel, et qui pourrait bien être la question la plus difficile à laquelle doit répondre une entreprise dans ce cas particulier, est la suivante : quels sont tous les endroits dans lesquels est effectivement exécuté le logiciel vulnérable ?

Si la vulnérabilité est présente dans un logiciel propriétaire dont une licence est accordée par une entreprise au reste du monde, la réponse est simple : il suffit de trouver ce logiciel. Dans ce cas, toutefois, c’était beaucoup plus difficile. Log4j est un logiciel largement utilisé, que les personnes autre que les développeurs Java ne connaissent probablement pas. Notre première action a consisté à nous familiariser à nouveau avec tous les endroits de notre infrastructure dans lesquels nous exécutons des logiciels sur JVM, afin de déterminer quels composants logiciels pouvaient être vulnérables à ce problème.

Nous avons pu établir un inventaire de tous les logiciels en cours d’exécution sur JVM, grâce à nos référentiels de code centralisés. Nous avons utilisé ces informations pour rechercher et déterminer chacune de nos applications Java individuelles, si elle contenait ou non Log4j et quelle version de Log4j était compilée dans celle-ci.

Nous avons découvert que nos systèmes ElasticSearch, LogStash et Bitbucket contenaient des instances du package Log4j vulnérable entre les versions 2.0 et 2.14.1. Nous avons pu utiliser les stratégies d’atténuation décrites dans la documentation officielle de sécurité de Log4j pour corriger le problème. Pour chaque instance de Log4j, nous avons soit supprimé la classe JndiLookup du chemin de classe :

zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Ou alors, nous avons défini la propriété système d’atténuation dans la configuration de log4j :

log4j2.formatMsgNoLookups

Nous avons pu atténuer rapidement ce problème dans ces packages en appliquant ces stratégies, en attendant la publication de nouvelles versions des packages.

Avant même d’avoir dressé la liste des endroits internes dans lesquels était exécuté le logiciel vulnérable, nous avons commencé par examiner les rapports externes (de HackerOne, de notre programme de primes aux bugs et d’un message public publié sur GitHub) suggérant que nous pourrions être en danger.

Nous avons identifié au moins deux rapports qui semblaient indiquer que Cloudflare était vulnérable et compromise. Un des rapports contenait la capture d’écran suivante :

Cet exemple cible notre documentation pour développeurs, hébergée à l’adresse https://developer.cloudflare.com. Sur le côté droit, l’auteur de l’attaque démontre qu’une requête DNS a été reçue pour la charge utile qu’il a envoyée à notre serveur. Cependant, l’adresse IP signalée ici est 173.194.95.13, un membre d’un sous-réseau IPv4 appartenant à Google ( 173.194.94.0/23).

La documentation pour développeurs de Cloudflare est hébergée sous forme d’instance Cloudflare Worker et sert uniquement des ressources statiques. Le référentiel est public. L’instance Worker utilise la bibliothèque d’analyses de Google, comme indiqué ici ; par conséquent, nous supposons que l’auteur de l’attaque ne recevait pas une requête depuis Cloudflare, mais via les serveurs de Google.

Nos serveurs de back-end reçoivent les fichiers journaux de Workers, mais l’exploitation de la vulnérabilité n’était pas non plus possible dans ce cas, puisque nous appliquons les robustes politiques de trafic sortant de Kubernetes, qui empêchent la transmission d’appels vers Internet. Les seules communications autorisées sont celles adressées à un ensemble restreint de services internes.

Pendant que nous collections d’autres informations, nous avons reçu un rapport similaire par le biais de notre programme de divulgation des vulnérabilités, mais le chercheur n’a pas été en mesure de reproduire le problème. Cela a confirmé notre hypothèse selon laquelle il s’agissait de serveurs tiers, et qu’ils avaient peut-être corrigé le problème.

Bien que nous utilisions les versions du logiciel décrites ci-dessus, grâce à notre rapidité de réaction et à notre approche de défense en profondeur, nous ne pensons pas que Cloudflare ait été compromise. Nous avons réalisé des efforts considérables pour valider cette supposition, et nous continuerons à travailler sur cette initiative jusqu’à ce que nous sachions tout sur cette vulnérabilité. Voici quelques informations sur les initiatives que nous avons prises ici.

Pendant que nous nous efforcions d’évaluer et d’isoler tous les contextes dans lesquels le logiciel vulnérable pouvait être exécuté, en appliquant les correctifs nécessaires, nous avons lancé un flux de travail distinct afin d’analyser si l’une de ces instances avait été exploitée.  Notre méthodologie de détection et de réponse est conforme aux pratiques standard d’intervention en cas d’incident informatique de l’industrie, et a été déployée avec rigueur afin de confirmer si l’une de nos ressources était effectivement compromise. Nous avons ensuite adopté une approche à plusieurs facettes, décrite ci-après.

Notre inventaire des ressources et nos outils d’analyse de code nous ont permis d’identifier l’ensemble des applications et services utilisant Apache Log4j. Pendant que ces applications étaient examinées et mises à niveau, si nécessaire, nous avons effectué une analyse complète de ces services et hôtes. Plus précisément, le code d’exploitation de la vulnérabilité CVE-2021-44228 repose sur des modèles particuliers dans les messages de fichiers journaux et les paramètres, par exemple, \$\{jndi :(ldap[s]?|rmi|dns):/[^\n]+. Pour chaque service potentiellement affecté, nous avons effectué une analyse des fichiers journaux, afin d’exposer toute tentative d’exploitation.

Nos analyses du réseau nous permettent d’identifier les comportements suspects sur le réseau pouvant être symptomatiques d’une tentative d’exploitation ou d’une exploitation avérée de notre infrastructure. Nous avons examiné les données de notre réseau afin d’identifier les aspects suivants :

1. Activité suspecte du trafic entrant et sortantEn analysant les connexions entrantes et sortantes suspectes, nous avons pu examiner notre environnement et déterminer si certains de nos systèmes présentaient des signes indiquant qu’ils avaient été activement compromis.

2. Systèmes et services ciblésEn comparant des analyses de modèles avec les données de notre réseau, nous avons découvert les systèmes et services ciblés par les acteurs de la menace. Ceci nous a permis d’effectuer des recherches corrélatives dans notre inventaire de ressources et d’approfondir l’examen de chaque hôte, afin de déterminer si l’une de ces machines était exposée à la vulnérabilité ou était activement exploitée.

3. Indicateurs réseauL’analyse décrite ci-dessus nous a permis de mieux étudier l’infrastructure des différents acteurs de la menace et d’identifier les indicateurs réseau utilisés dans les tentatives d’exploitation de cette vulnérabilité. Le trafic sortant vers ces indicateurs a été bloqué dans Cloudflare Gateway.

Nous avons pu mettre en corrélation nos flux d’analyse des fichiers journaux et d’analyse du réseau pour compléter notre analyse des points de terminaison. À partir des résultats de ces deux analyses, nous avons pu élaborer des critères d’analyse des points de terminaison permettant d’identifier d’autres systèmes potentiellement affectés et d’analyser les points de terminaison individuels à la recherche de signes indiquant qu’ils étaient activement compromis. Nous avons employé les techniques suivantes :

Analyse basée sur la signature

Nous sommes en train de déployer des règles de détection personnalisées dans Yara afin d’alerter en cas d’exploitation de la vulnérabilité. Ces règles seront déployées dans l’agent Endpoint Detection and Response, exécuté sur l’ensemble de notre infrastructure et dans notre outil centralisé de gestion des informations et des événements de sécurité (SIEM).

Analyse d’exécution et de persistance de processus anormaux

Cloudflare collecte et analyse continuellement les événements liés aux processus des points de terminaison de notre infrastructure. Nous avons utilisé ces événements pour rechercher des techniques de post-exploitation, telles que le téléchargement de codes d’exploitation de vulnérabilité de seconde phase, des processus enfants anormaux, etc.

Toutes ces approches ne nous ont permis de trouver aucune preuve de compromission.

Dans l’analyse ci-dessus, nous nous sommes concentrés sur l’examen du code et des données que nous générons nous-mêmes. Mais comme la plupart des entreprises, nous utilisons également des logiciels pour lesquels nous avons souscrit une licence auprès de tiers. Lorsque nous avons commencé à enquêter sur cette affaire, nous nous sommes également associés à l’équipe informatique de l’entreprise pour établir une liste de tous les fournisseurs tiers principaux et tous les sous-traitants secondaires, afin de déterminer s’ils étaient concernés. Nous sommes actuellement en train de recevoir et d’examiner les réponses des fournisseurs. Tous les fournisseurs que nous considérons comme critiques, et qui sont affectés par cette vulnérabilité, seront désactivés et bloqués jusqu’à ce que leurs logiciels aient été entièrement corrigés.

En répondant à cet incident, nous avons identifié plusieurs approches pour lesquelles notre approche de défense en profondeur s’est avérée efficace.

1. Restriction du trafic sortant

La restriction de la capacité à contacter le serveur d’origine est une composante essentielle de la Kill Chain permettant de rendre beaucoup plus difficile l’exploitation des vulnérabilités. Comme nous l’avons indiqué plus haut, nous appliquons les politiques réseau de Kubernetes pour restreindre le trafic sortant vers Internet dans nos déploiements. Dans ce contexte, cela permet d’éviter l’étape suivante de l’attaque, et la connexion réseau aux ressources contrôlées par l’auteur de l’attaque est interrompue.

Tous nos services externes sont protégés par Cloudflare. Les serveurs d’origine de ces services sont mis en place via des extractions d’origine authentifiées. Cela signifie qu’aucun des serveurs n’est directement exposé à l’Internet.

2.   Utilisation de Cloudflare pour sécuriser Cloudflare

Tous nos services internes sont protégés par notre produit Zero Trust, Cloudflare Access. Par conséquent, une fois que nous avons appliqué les correctifs nécessaires à la surface d’attaque limitée que nous avions identifiée, toute tentative d’exploitation des systèmes de Cloudflare ou de clients utilisant Access aurait nécessité l’authentification de l’auteur de l’attaque.

Et parce que nous avons déployé le produit Cloudflare WAF dans le cadre de nos initiatives visant à utiliser Cloudflare pour sécuriser Cloudflare, nous avons bénéficié de tout le travail effectué pour protéger nos clients. Toutes les nouvelles règles de pare-feu WAF écrites pour offrir une protection contre cette vulnérabilité ont été mises à jour avec l’action par défaut BLOCK. Comme tous les autres clients qui ont déployé le pare-feu WAF, nous sommes désormais protégés, sans aucune action requise de notre part.

Tandis que notre réponse à cette situation difficile se poursuit, nous espérons que cet aperçu de nos efforts aidera d’autres personnes. Nous sommes reconnaissants pour tout le soutien que nous avons reçu de l’intérieur et de l’extérieur de Cloudflare.

Nous tenons à remercier Evan Johnson, Anjum Ahuja, Sourov Zaman, David Haynes et Jackie Keith, qui ont également contribué à cette publication de blog.