dungsocool/cve-2017-18349Guía paso a paso de la explotación de RCE por deserialización de Fastjson CVE-2017-18349, cubriendo la identificación de la superficie de ataque, el fingerprinting, la inyección JNDI y la obtención de una shell reversa en un entorno de laboratorio Docker.
Comencemos con lo que se ejecuta en el entorno. Listo todos los contenedores activos:
docker ps
La víctima expone solo un puerto: 8090
Actualmente, aún no tengo claro el objetivo. De los resultados de docker ps, el sistema solo publica un servicio notable externamente en el puerto 8090, que está mapeado al servicio interno del contenedor. Esta es la principal superficie de ataque a analizar.
⇒ Lo consulto directamente con Curl para obtener más información
curl -i 192.168.3.137:8090/
Análisis de la respuesta:
Content-Type: application/json;charset=UTF-8.{"age": 25, "name": "Bob"}.⇒ Reflexión: Al acceder al puerto 8090, el servidor devuelve datos JSON. Esto indica que el endpoint no solo sirve una página web estática, sino que tiene un backend que procesa solicitudes y serializa datos en JSON para devolverlos al cliente. De los resultados de docker ps, el comando que se ejecuta dentro del contenedor muestra señales de ser una aplicación Java, por lo que la siguiente dirección de inspección es identificar los analizadores JSON comunes en Java.
En Java, bibliotecas JSON populares como Jackson, Gson y Fastjson se comportan de manera diferente al encontrarse con entradas inusuales. Por lo tanto, podemos utilizar la técnica de Fingerprinting basado en errores. El error devuelto a veces revela directamente la biblioteca o el mecanismo de procesamiento interno. Entre ellas, Fastjson es un objetivo que necesita verificación temprana porque las versiones antiguas tenían múltiples vulnerabilidades críticas relacionadas con la deserialización AutoType.
Aquí, no afirmo de inmediato que el backend use Fastjson. Solo elijo Fastjson como la primera dirección de verificación porque tiene una huella clara a través de la clave @type, y si es una versión antigua de Fastjson, la capacidad de explotación puede ir mucho más allá de un error de análisis estándar, potencialmente incluso llevando a RCE.
Fastjson tiene una característica muy útil para el fingerprinting: reconoce la clave especial @type. Si el backend usa Fastjson y el cuerpo de la solicitud enviado al flujo de deserialización soporta AutoType, el analizador puede intentar interpretar el valor de @type como un nombre de clase Java.
Por lo tanto, envío un payload que contiene @type apuntando a una clase inexistente. El objetivo de este paso no es explotar de inmediato, sino observar si el backend reacciona a @type.
curl -i -X POST -H "Content-Type: application/json" \
-d '{"@type":"com.non.existent.Class"}' \
http://192.168.3.137:8090/
Si el backend usara un analizador JSON estándar y no le importara @type, este campo podría ser ignorado o tratado como una clave normal en el JSON. Sin embargo, aquí el backend reacciona con un comportamiento relacionado con el tipo (type not match), lo que significa que la solicitud ingresó al flujo de procesamiento de mapeo de clase/tipo.
El mensaje "type not match" es una firma característica que a menudo se encuentra cuando Fastjson procesa @type pero la clase especificada no coincide con el tipo de datos esperado por el endpoint, o la clase no existe/no está permitida para ser deserializada.
⇒ Reflexión: El backend realmente analiza el cuerpo JSON de la solicitud POST, el campo @type no se ignora, el analizador tiene un mecanismo de procesamiento de metadatos de tipo, y el error devuelto coincide con el comportamiento de Alibaba Fastjson. Por lo tanto, podemos concluir con alta confianza que el backend está usando Alibaba Fastjson.**
Después del paso de fingerprinting, no puedo concluir de inmediato que el sistema sea explotable. Que el backend use Fastjson solo prueba que la solicitud JSON ingresa al flujo de procesamiento de @type.
Para ejecutar un exploit RCE, se debe verificar lo siguiente:
⇒ Reflexión: El error type not match muestra que el backend reacciona a @type, pero el payload actual solo usa una clase falsa para provocar un error. Para una explotación real, necesitamos reemplazar esa clase falsa con una clase real presente en Java/JDK que sea capaz de crear comportamientos de salida como la consulta JNDI.
Para determinar la versión, verifico directamente dentro del contenedor/aplicación.
Después de identificar que la aplicación está empaquetada como el archivo /usr/src/fastjsondemo.jar, procedo con un análisis profundo de esta estructura de paquete para buscar la biblioteca de procesamiento JSON. Al verificar la estructura del directorio BOOT-INF/lib/ se revela el archivo fastjson-1.2.24.jar (Figura X).
El uso de la versión exacta 1.2.24 — la primera y más famosa versión afectada por la vulnerabilidad de deserialización sin ningún mecanismo de defensa autoType — nos permite confirmar que el sistema es vulnerable a CVE-2017-18349.
Encontrar fastjson-1.2.24.jar confirma que la aplicación usa una versión muy antigua de Fastjson, perteneciente al grupo afectado por la falla de deserialización AutoType. En esta versión, el mecanismo de control sobre AutoType no se ajustó como en versiones posteriores, por lo que, en cuanto a las condiciones de la biblioteca, el sistema es susceptible a la explotación a través de clases gadget como JdbcRowSetImpl.
Sin embargo, la explotabilidad real aún depende de cómo el endpoint invoca a Fastjson. Si la aplicación analiza JSON en una clase fija, establecer el payload @type en el objeto raíz podría llevar al error "type not match". Por lo tanto, después de identificar la versión, debemos continuar analizando la JVM, la clase gadget y el comportamiento de devolución de llamada LDAP para confirmar si la cadena de explotación realmente llega a la consulta JNDI.
1. Análisis de las Barreras de la JVM
Además de la versión de Fastjson, la versión de Java también es un factor decisivo. Verifico la JVM dentro del contenedor:
java -version
Esta es información crítica porque las cadenas de explotación de Fastjson típicamente dependen de la Inyección JNDI. Las versiones más nuevas de Java han bloqueado la carga de clases desde codebases externos a través de LDAP/RMI de forma predeterminada. Sin embargo, Java 8u102 es una versión antigua que aún no tiene estos mecanismos de bloqueo.
Por lo tanto, si el atacante puede desencadenar una consulta JNDI, la JVM de la víctima tiene la capacidad de descargar la clase desde un servidor HTTP externo y cargarla en tiempo de ejecución.