Pentests et Log4J : comment exploiter un système vulnérable

Dans cet article, nous testons un système vulnérable et montrons comment un shell distant peut être obtenu à l'aide d'un exploit open source Log4j accessible à tous.

Introduction

Cette vulnérabilité critique, étiquetée CVE-2021-44228, affecte un grand nombre de clients, car le composant Apache Log4j est largement utilisé dans les logiciels commerciaux et open source. De plus, les attaquants de rançongiciels militarisent l'exploit Log4j pour augmenter leur portée auprès d'un plus grand nombre de victimes à travers le monde.

Notre démonstration est fournie à des fins éducatives à un public plus technique dans le but de mieux faire comprendre le fonctionnement de cet exploit.

Raxis estime qu'une meilleure compréhension de la composition des exploits est le meilleur moyen pour les utilisateurs d'apprendre à combattre les menaces croissantes sur Internet.

Storyboard de l'exploit Log4j

La vulnérabilité Apache Log4j, CVE-2021-44228 ( https://nvd.nist.gov/vuln/detail/CVE-2021-44228 ), affecte un grand nombre de systèmes, et les attaquants exploitent actuellement cette vulnérabilité pour les utilisateurs connectés à Internet. systèmes à travers le monde.

Pour démontrer l'anatomie d'une telle attaque, Raxis fournit une démonstration étape par étape de l'exploit en action. Dans notre démonstration, nous faisons des hypothèses sur l'environnement réseau utilisé pour le serveur victime qui permettrait à cette attaque d'avoir lieu.

Il existe certainement de nombreuses façons d'empêcher cette attaque de réussir, comme l'utilisation de configurations de pare-feu plus sécurisées ou d'autres dispositifs de sécurité réseau avancés, cependant, nous avons sélectionné une configuration de sécurité « par défaut » commune aux fins de démonstration de cette attaque.

Serveur victime

Tout d'abord, notre serveur victime est un serveur Web Tomcat 8 qui utilise une version vulnérable d'Apache Log4j et est configuré et installé dans un conteneur Docker.

Le conteneur docker nous permet de démontrer un environnement distinct pour le serveur victime qui est isolé de notre environnement de test. Notre serveur Tomcat héberge un exemple de site Web disponible sur https://github.com/cyberxml/log4j-poc et est configuré pour exposer le port 8080 pour le serveur Web vulnérable.

Aucun autre port entrant pour ce conteneur Docker n'est exposé autre que 8080. Le conteneur Docker autorise le trafic sortant, similaire à la configuration par défaut de nombreux réseaux de serveurs.

Notez que ce référentiel GitHub particulier comportait également une version intégrée du code d'attaque et de la charge utile Log4j, cependant, nous l'avons désactivé pour notre exemple afin de fournir une vue des écrans tels qu'ils sont vus par un attaquant. Nous n'utilisons que les parties du serveur Web Tomcat 8, comme indiqué dans la capture d'écran ci-dessous.

Figure 1 : Code d'exécution du serveur Web de démonstration Tomcat 8 de la victime vulnérable à l'exploit Log4j

Ensuite, nous devons configurer le poste de travail de l'attaquant. À l'aide du code d'exploitation de https://github.com/kozmer/log4j-shell-poc, Raxis configure trois sessions de terminal, appelées Netcat Listener, Python Web Server et Exploit, comme indiqué ci-dessous.

Écouteur Netcat, Port 9001

La session Netcat Listener, indiquée dans la figure 2, est un écouteur Netcat s'exécutant sur le port 9001. Cette session consiste à attraper le shell qui nous sera transmis par le serveur victime via l'exploit.

Figure 2 : écouteur Netcat de l'attaquant sur le port 9001

Serveur Web Python, Port 80

La session Python Web Server de la figure 3 est un serveur Web Python exécuté sur le port 80 pour distribuer la charge utile au serveur victime.

Figure 3 : Serveur Web Python de l'attaquant pour distribuer la charge utile

Code d'exploitation, port 1389

La session Exploit, illustrée à la Figure 4, est le code d'exploitation Log4j de preuve de concept fonctionnant sur le port 1389, créant un serveur LDAP armé.

Ce code redirigera le serveur victime pour télécharger et exécuter une classe Java obtenue à partir de notre serveur Web Python exécuté sur le port 80 ci-dessus.

La classe Java est configurée pour générer un shell sur le port 9001, qui est notre écouteur Netcat dans la figure 2.

Figure 4 : Code d'exploitation Log4J de l'attaquant

Exécuter l'attaque

Maintenant que le code est mis en scène, il est temps d'exécuter notre attaque. Nous nous connecterons au serveur Web de la victime à l'aide d'un navigateur Web Chrome.

Notre chaîne d'attaque, illustrée à la figure 5, exploite JNDI pour envoyer une requête LDAP à la session d'exploitation de l'attaquant s'exécutant sur le port 1389.

Figure 5 : Site Web de la victime et chaîne d'attaque

La chaîne d'attaque exploite une vulnérabilité dans Log4j et demande qu'une recherche soit effectuée sur le serveur LDAP armé de l'attaquant.

Pour ce faire, une requête sortante est effectuée du serveur victime vers le système de l'attaquant sur le port 1389. La session Exploit de la figure 6 indique la réception de la connexion LDAP entrante et la redirection effectuée vers le serveur Web Python de notre attaquant.

Figure 6 : Session d'exploitation de l'attaquant indiquant la connexion entrante et la redirection

La session Exploit a envoyé une redirection vers notre serveur Web Python, qui sert une classe Java armée contenant du code pour ouvrir un shell.

Cette classe Java a été configurée à partir de notre session Exploit et n'est servie que sur le port 80 par le serveur Web Python. Le journal de connexion est illustré à la figure 7 ci-dessous.

Figure 7 : Serveur Web Python de l'attaquant envoyant le shell Java

La dernière étape de notre attaque est celle où Raxis obtient le shell avec le contrôle du serveur de la victime. La classe Java envoyée à notre victime contenait du code qui ouvrait un shell distant à la session netcat de notre attaquant, comme illustré à la figure 8.

L'attaquant a désormais le contrôle total du serveur Tomcat 8, bien que limité à la session docker que nous avions configurée dans ce scénario de test.

Figure 8 : Accès de l'attaquant au Shell contrôlant le serveur de la victime

Conclusion

Comme nous l'avons démontré, la vulnérabilité Log4j est un processus en plusieurs étapes qui peut être exécuté une fois que vous avez les bonnes pièces en place. Raxis voit ce code implémenté dans des robots d'attaque de ransomware qui recherchent sur Internet des systèmes à exploiter.

Il s'agit certainement d'un problème critique qui doit être résolu dès que possible, car ce n'est qu'une question de temps avant qu'un attaquant n'atteigne un système exposé.

Également publié ici