Resumen

La lógica de validación de URL aplicada al manejar /appsuite/api/oxodocumentfilter&action=addfile adolece de tres defectos que pueden usarse para ejecutar un ataque SSRF de Tiempo de Verificación Tiempo de Uso (ToCToU). Este problema permite a actores maliciosos ejecutar solicitudes HTTP GET en servicios de red internos y puede provocar la filtración de información protegida.

Defecto #1: Vulnerabilidad de Tiempo de Verificación Tiempo de Uso (ToCToU)

La lógica de validación de URL en el método URITools.getFinalURL implementado aquí sufre una vulnerabilidad ToCToU

URL u = new URL(url);
if (validator.isPresent()) {
    Optional<OXException> exception = validator.get().apply(u);
    if (exception.isPresent()) {
        throw exception.get();
    }
}

URLConnection urlConnnection = u.openConnection();

En el código anterior, la resolución DNS del nombre de host de la URL de entrada se realiza tanto en el momento de la verificación (validator.get().apply(u)) como en el momento del uso (u.openConnection()) llamando al método InetAddress.getByName. Por lo tanto, si un atacante puede cambiar el resultado de la resolución DNS después de la verificación y antes del uso, puede eludir el validador. Este defecto por sí solo es extremadamente difícil de explotar debido a las siguientes limitaciones:

1. Por defecto, InetAddress.getByName almacena en caché los resultados de la resolución DNS durante 30 segundos si la resolución tiene éxito y durante 10 segundos si falla.
2. El intervalo de tiempo entre validator.get().apply(u) y u.openConnection() es extremadamente pequeño (menos de un milisegundo para URLs normales). El Defecto #2 se utiliza para eludir esta limitación.

Defecto #2: La longitud de la URL de entrada no está limitada

El validador de URL AddFileAction.validator implementado aquí no valida la longitud de la URL de entrada. Al proporcionar una URL de gran tamaño, el atacante puede aumentar el intervalo de tiempo entre las llamadas al método InetAddress.getByName en el momento de la verificación y en el momento del uso. Un intervalo de tiempo más grande permite al atacante explotar fácilmente el Defecto #1.

Defecto #3: El validador de URL permite la URL de entrada si falla su resolución DNS

El método HostList.contains implementado aquí devuelve false si la resolución DNS del nombre de host de la URL de entrada falla.

// Need to resolve as last resort
try {
    return contains(InetAddress.getByName(toCheck), false);
} catch (UnknownHostException e) {
    // Cannot be resolved
    return false;
}

El AddFileAction.validator llama al método blackImageUrlHostlist.contains para verificar si el nombre de host de la URL de entrada o la dirección IP a la que resuelve está en la lista negra. Si un atacante hace que la resolución DNS del nombre de host falle, las comprobaciones de dirección IP se omiten y la URL se acepta.

Estrategia de ataque

Considere un nombre de host randomid.dns.pointer.pw con un servidor de nombres autoritativo controlado por el atacante. La estrategia de ataque consiste en hacer que la resolución DNS de randomid.dns.pointer.pw falle en el momento de la verificación (validator.get().apply(u);) y tenga éxito en el momento del uso (u.openConnection()). Esto permite al atacante eludir los filtros de lista negra de direcciones IP y ejecutar una solicitud HTTP GET en cualquier dirección IP en la lista negra. El atacante puede seguir los siguientes pasos para ejecutar este ataque:

1. Activar la caché de InetAddress.getByName en el servidor ejecutando la acción addfile con los datos de solicitud {"add_imageurl": "http://randomid.dns.pointer.pw"}. En este momento, el servidor DNS autoritativo se configurará para que falle la resolución DNS de randomid.dns.pointer.pw devolviendo el estado SERVFAIL. InetAddress.getByName almacenará en caché este resultado de fallo durante 10 segundos.
2. Anotar la hora en que se recibió la respuesta de la solicitud anterior. Esta es la hora de inicio de la caché.
3. Indicar al servidor de nombres autoritativo del dominio pointer.pw que devuelva 127.0.0.1 para las solicitudes DNS de tipo A del nombre de host randomid.dns.pointer.pw.
4. Dormir durante la duración especificada desde la hora de inicio de la caché, de modo que en el siguiente paso InetAddress.getByName devuelva la respuesta en caché (SERVFAIL) en el momento de la verificación y devuelva 127.0.0.1 en el momento del uso ().

Pasos para reproducir

1. Instalar golang desde https://golang.org/dl/

2. Instalar Open-Xchange y Documents en una máquina virtual con al menos 4GB de RAM siguiendo las guías https://oxpedia.org/wiki/index.php?title=AppSuite:Open-Xchange_Installation_Guide_for_Debian_9.0 y https://oxpedia.org/wiki/index.php?title=AppSuite:Documents_Installation_Guide#Debian_GNU.2FLinux_9.0_.28valid_from_v7.10.29

3. Descargar y extraer el archivo poc.zip

4. Abrir terminal / línea de comandos y establecer el directorio actual en la carpeta extraída de poc.zip

5. Ejecutar el comando

   root@kitploit:~

    go run . -serverRoot="http://172.16.66.130" -username="testuser" -password="secret" -targetPath="appsuite/v=7.10.3-9.20200409.083030/apps/themes/logo.png" -targetPort="80" -payloadSize=25 -startSleepDuration=6600
   

   donde 172.16.66.130 es la dirección IP de la MV