Guide pas à pas de l'exploitation RCE par désérialisation Fastjson CVE-2017-18349, couvrant l'identification de la surface d'attaque, la prise d'empreintes, l'injection JNDI et l'acquisition d'un shell inverse dans un environnement de laboratoire Docker.
Commençons par voir ce qui s'exécute dans l'environnement. Je liste tous les conteneurs actifs :
docker ps
La victime n'expose qu'un seul port : 8090
Actuellement, je n'ai pas encore une vision complète de la cible. D'après les résultats de docker ps, le système ne publie qu'un seul service notable en externe sur le port 8090, qui est mappé au service interne du conteneur. C'est la principale surface d'attaque à analyser.
⇒ Je l'interroge directement avec Curl pour en savoir plus
curl -i 192.168.3.137:8090/
Analyse de la réponse :
Content-Type: application/json;charset=UTF-8.{"age": 25, "name": "Bob"}.⇒ Réflexion : Lors de l'accès au port 8090, le serveur renvoie des données JSON. Cela indique que le point d'accès ne sert pas simplement une page web statique, mais possède un backend qui traite les requêtes et sérialise les données en JSON pour les renvoyer au client. D'après les résultats de docker ps, la commande exécutée dans le conteneur montre des signes d'une application Java. La prochaine direction d'inspection est donc d'identifier les analyseurs JSON courants en Java.
En Java, les bibliothèques JSON populaires comme Jackson, Gson et Fastjson se comportent différemment face à des entrées inhabituelles. On peut donc utiliser la technique d'identification par erreur (Error-based Fingerprinting). L'erreur renvoyée révèle parfois directement la bibliothèque ou le mécanisme de traitement interne. Parmi elles, Fastjson est une cible à vérifier tôt car les anciennes versions présentaient plusieurs vulnérabilités critiques liées à la désérialisation AutoType.
Ici, je n'affirme pas immédiatement que le backend utilise Fastjson. Je choisis seulement Fastjson comme première direction de vérification car il possède une empreinte claire via la clé @type, et s'il s'agit bien d'une ancienne version de Fastjson, la capacité d'exploitation peut aller bien au-delà d'une simple erreur d'analyse, pouvant potentiellement mener à une exécution de code à distance (RCE).
Fastjson possède une caractéristique très utile pour l'identification : il reconnaît la clé spéciale @type. Si le backend utilise Fastjson et que le corps de la requête envoyé dans le flux de désérialisation prend en charge AutoType, l'analyseur peut tenter d'interpréter la valeur de @type comme un nom de classe Java.
Par conséquent, j'envoie une charge utile contenant @type pointant vers une classe inexistante. L'objectif de cette étape n'est pas d'exploiter immédiatement, mais d'observer si le backend réagit à @type.
curl -i -X POST -H "Content-Type: application/json" \
-d '{"@type":"com.non.existent.Class"}' \
http://192.168.3.137:8090/
Si le backend utilisait un analyseur JSON standard et ne se souciait pas de @type, ce champ pourrait simplement être ignoré ou traité comme une clé normale du JSON. Cependant, ici le backend réagit avec un comportement lié au type (type not match), ce qui signifie que la requête est entrée dans le flux de traitement de correspondance classe/type.
Le message « type not match » est une signature caractéristique souvent rencontrée lorsque Fastjson traite @type mais que la classe spécifiée ne correspond pas au type de données attendu par le point d'accès, ou que la classe n'existe pas / n'est pas autorisée à être désérialisée.
⇒ Réflexion : Le backend analyse bien le corps JSON de la requête POST, le champ @type n'est pas ignoré, l'analyseur possède un mécanisme de traitement des métadonnées de type, et l'erreur renvoyée correspond au comportement d'Alibaba Fastjson. On peut donc conclure avec une forte confiance que le backend utilise Alibaba Fastjson.**
Après l'étape d'identification, je ne peux pas immédiatement conclure que le système est exploitable. Le fait que le backend utilise Fastjson prouve seulement que la requête JSON entre dans le flux de traitement de @type.
Pour exécuter une exploitation RCE, les éléments suivants doivent être vérifiés :
⇒ Réflexion : L'erreur « type not match » montre que le backend réagit à @type, mais la charge utile actuelle utilise seulement une fausse classe pour déclencher une erreur. Pour une exploitation réelle, nous devons remplacer cette fausse classe par une classe réelle présente dans Java / JDK capable de créer des comportements sortants comme une recherche JNDI.
Pour déterminer la version, je vérifie directement à l'intérieur du conteneur / de l'application.
Après avoir identifié que l'application est empaquetée sous la forme du fichier /usr/src/fastjsondemo.jar, je procède à une analyse approfondie de cette structure de package pour rechercher la bibliothèque de traitement JSON. La vérification de la structure du répertoire BOOT-INF/lib/ révèle le fichier fastjson-1.2.24.jar (Figure X).
L'utilisation exactement de la version 1.2.24 – la première et la plus célèbre version affectée par la vulnérabilité de désérialisation sans aucun mécanisme de défense AutoType – nous permet de confirmer que le système est vulnérable à CVE-2017-18349.
La découverte de fastjson-1.2.24.jar confirme que l'application utilise une version très ancienne de Fastjson, appartenant au groupe affecté par la faille de désérialisation AutoType. Dans cette version, le mécanisme de contrôle sur AutoType n'était pas aussi renforcé que dans les versions ultérieures, donc en ce qui concerne les conditions de la bibliothèque, le système est sensible à l'exploitation via des classes gadgets telles que JdbcRowSetImpl.
Cependant, l'exploitabilité réelle dépend encore de la manière dont le point d'accès invoque Fastjson. Si l'application analyse le JSON dans une classe fixe, placer la charge utile @type à l'objet racine pourrait conduire à l'erreur « type not match ». Par conséquent, après avoir identifié la version, nous devons continuer à analyser la JVM, la classe gadget et le comportement de rappel LDAP pour confirmer si la chaîne d'exploitation atteint effectivement la recherche JNDI.
1. Analyse des barrières de la JVM
Outre la version de Fastjson, la version de Java est également un facteur déterminant. Je vérifie la JVM à l'intérieur du conteneur :
java -version
Il s'agit d'une information critique car les chaînes d'exploitation de Fastjson reposent généralement sur l'injection JNDI. Les versions plus récentes de Java bloquent par défaut le chargement de classes depuis des codebases externes via LDAP / RMI. Cependant, Java 8u102 est une ancienne version qui ne possède pas encore ces mécanismes de blocage.