tadash10/exploiting-cve-2021-44228-log4shell-in-a-banking-environmentObjectif : Démontrer l'exploitation de la vulnérabilité Log4Shell (CVE-2021-44228) dans un environnement d'application bancaire simulé.
Objectif : Démontrer l'exploitation de la vulnérabilité Log4Shell (CVE-2021-44228) dans un environnement d'application bancaire simulé.
Périmètre :
1: Mettre en place une application bancaire vulnérable utilisant Apache Log4j. 2:Créer un payload pour exploiter la vulnérabilité, permettant une exécution de code à distance. 3:Démontrer des techniques de post-exploitation, telles que l'exfiltration de données et le mouvement latéral. 4:Implémenter et documenter des stratégies de détection et d'atténuation, y compris le correctif (patching) et la surveillance réseau. 5:Procédure détaillée du processus d'exploitation, y compris les outils utilisés (par exemple, JNDI Exploit Kit, Burp Suite).
Plongeons dans la création d'un payload pour exploiter la vulnérabilité Log4Shell (CVE-2021-44228) et parvenir à une exécution de code à distance dans le scénario fictif d'exercice de la machine virtuelle.
Pour créer le payload, nous devons comprendre la nature de la vulnérabilité. La vulnérabilité Log4Shell permet aux attaquants d'injecter du code malveillant dans le fichier de configuration de la bibliothèque Log4j, qui est ensuite exécuté par l'application concernée. Le payload sera conçu pour déclencher cette vulnérabilité et exécuter du code arbitraire sur le système cible.
Voici un aperçu de base des étapes pour créer le payload :
Identifier le fichier de configuration Log4j : déterminez l'emplacement du fichier de configuration Log4j dans l'environnement de l'application bancaire cible. En général, ce fichier s'appelle log4j2.xml ou log4j.properties.
Créer le payload d'exploitation : créez une configuration Log4j malveillante incluant une recherche Java Naming and Directory Interface (JNDI) pour exécuter du code arbitraire. Ce payload peut être incorporé dans le fichier log4j2.xml.
xml
Remplacez "your-attacker-server" par l'adresse IP ou le nom d'hôte de votre machine d'attaque en écoute sur le port 4444.
Héberger le payload : configurer un listener sur votre machine d'attaque pour recevoir la connexion et exécuter le code arbitraire.
Déclaration XML :
xml
Déclaration XML standard.
Élément de configuration :
xml
L'élément racine de la configuration Log4j.
Appenders :
xml
Définit un appender Socket nommé "evil".
L'attribut host spécifie le serveur de l'attaquant.
L'attribut port spécifie le port du serveur de l'attaquant.
SerializedLayout indique que les événements de journalisation seront sérialisés et envoyés sur le réseau, ce qui peut constituer un risque de sécurité car cela pourrait permettre une exécution de code à distance (RCE) via des attaques par désérialisation.
Loggers :
xml
<Loggers>
<Root level="all">
<AppenderRef ref="evil" />
</Root>
</Loggers>
Définit le niveau de journalisation sur all, ce qui signifie que tous les messages de journalisation (debug, info, warn, error, etc.) seront capturés.
L'AppenderRef référence l'appender "evil" défini précédemment, ce qui signifie que tous les messages de journalisation seront envoyés au serveur de l'attaquant.
Retour
Risques de sécurité :
Exécution de code à distance (RCE) : l'utilisation d'un SerializedLayout avec un appender Socket distant peut permettre à un attaquant d'exécuter du code arbitraire sur le système s'il contrôle le serveur et envoie un payload malveillant. Il s'agit d'une vulnérabilité de sécurité critique.
Exfiltration de données : cette configuration peut facilement conduire à l'envoi de données sensibles à un serveur distant non autorisé, entraînant des fuites de données.
Pratiques de journalisation inappropriées :
La journalisation vers un serveur distant non fiable est extrêmement peu sûre et va à l'encontre des bonnes pratiques de journalisation sécurisée.
La journalisation au niveau all dans un environnement de production peut entraîner une inondation des journaux, des problèmes de performance et une exposition potentielle d'informations sensibles.
Recommandations d'atténuation :
Évitez les layouts sérialisés : n'utilisez pas SerializedLayout dans une configuration de journalisation sauf en cas d'absolue nécessité et assurez-vous que le serveur récepteur est fiable et sécurisé.
Validez les points de terminaison de journalisation : assurez-vous que tous les points de terminaison de journalisation se trouvent dans des environnements fiables et contrôlés.
Utilisez des layouts sûrs : utilisez des layouts plus sûrs comme PatternLayout qui ne présentent pas de risques de sérialisation.
Restreignez les niveaux de journalisation : utilisez des niveaux de journalisation appropriés (par exemple, info, warn, error) et évitez d'utiliser all sauf à des fins de débogage spécifiques dans un environnement sécurisé.
Exemple de configuration plus sûre
Voici un exemple de configuration Log4j plus sûre :
xml
nc -nlvp 4444
Déclencher la vulnérabilité : déployer le fichier de configuration Log4j malveillant dans l'environnement cible, en remplaçant le fichier de configuration d'origine.
Exécution de l'exploit : une fois la configuration malveillante chargée par l'instance Log4j vulnérable, elle tentera d'établir une connexion avec le serveur de l'attaquant, conduisant à une exécution de code à distance.
Vérifier l'exécution : vérifiez le listener sur votre machine d'attaque pour confirmer que le payload a été exécuté avec succès.
Il est essentiel de noter que ce payload est destiné à des fins éducatives et de test dans un environnement contrôlé. Dans des scénarios réels, exploiter des vulnérabilités comme Log4Shell sans autorisation est illégal et contraire à l'éthique. Assurez-vous toujours d'avoir une permission et une autorisation explicites avant d'effectuer des tests de sécurité ou des activités de test d'intrusion.