
Informe de laboratorio paso a paso que demuestra la omisión de autenticación de InfluxDB CVE-2019-20933 mediante tokens JWT falsificados, incluida la explotación, la post-explotación y la guía de remediación.
Comenzando por lo que se está ejecutando en el entorno. Enumero todos los contenedores activos:
docker ps

La víctima expone un único puerto: 8086.
Actualmente, no dispongo de información detallada sobre el objetivo. Según la salida de docker ps, el sistema solo expone externamente un servicio destacable en el puerto 8086, que está mapeado al servicio dentro del contenedor. Esta es la principal superficie de ataque a analizar.
En lugar de acceder a él inmediatamente a través del navegador, procedemos a realizar el fingerprinting del servicio con Nmap para determinar qué servicio se está ejecutando en el puerto 8086:
nmap -sV -sC -p 8086 192.168.3.137

Los resultados del escaneo muestran que el puerto 8086 es el servicio HTTP de InfluxDB OSS 1.6.6. Se trata de una base de datos de series temporales expuesta a través de una API HTTP, no de una aplicación web típica.
InfluxDB es una base de datos de series temporales (TSDB) de código abierto escrita en Go. A diferencia de los RDBMS (optimizados para transacciones precisas) o Elasticsearch (optimizado para la búsqueda de texto), InfluxDB fue creada con un único propósito: Gestionar volúmenes masivos de escritura (alto rendimiento de escritura) y consultar datos a lo largo del eje temporal con baja latencia.

Dado que el servicio ha sido identificado como InfluxDB, el siguiente paso es consultar cómo se comunica InfluxDB con los clientes. Según la documentación de la API HTTP de InfluxDB v1, el puerto 8086 es el puerto predeterminado de la API HTTP. Los endpoints importantes incluyen:
/ping: comprueba el estado operativo del servidor./query: envía consultas InfluxQL para leer metadatos o datos./write: escribe datos de series temporales en la base de datos.⇒ Reflexión: Después de que Nmap identifica el servicio como InfluxDB http admin 1.6.6, no continuamos probándolo como un sitio web estándar. Para aplicaciones web, normalmente buscamos rutas, formularios de inicio de sesión o directorios. Sin embargo, con InfluxDB, la superficie de ataque reside dentro de la API HTTP. Por lo tanto, debemos pasar a probar los endpoints estándar de la API de InfluxDB para determinar si la API requiere autenticación. En consecuencia, el siguiente paso de la prueba no es acceder a / mediante el navegador, sino enviar solicitudes directamente a los endpoints de la API de InfluxDB.
/pingDespués de identificar el puerto 8086 como la API HTTP de InfluxDB, comprueba el endpoint /ping para confirmar que el servicio está operativo:
curl -i <http://192.168.3.137:8086/ping>

La respuesta 204 No Content confirma que InfluxDB está operando con normalidad. Las cabeceras confirman además que la versión del servicio es InfluxDB OSS 1.6.6
/querycurl -i -s "http://192.168.3.137:8086/query?q=SHOW+DATABASES"

El endpoint /query no permite consultas directas sin credenciales de autenticación. Esto confirma que InfluxDB tiene la autenticación habilitada y bloquea todas las consultas anónimas enviadas al sistema.
Paso a reflexionar: ¿tiene la versión 1.6.6 de InfluxDB alguna vulnerabilidad que permita eludir el mecanismo de autenticación?

Al consultar las bases de datos públicas de vulnerabilidades, las versiones de InfluxDB anteriores a 1.7.6 están afectadas por CVE-2019-20933. Se trata de una vulnerabilidad de omisión de autenticación (Authentication Bypass) dentro de la función de autenticación de InfluxDB, relacionada con el manejo de tokens JWT con un secreto compartido vacío.
Dado que el objetivo ejecuta InfluxDB 1.6.6, que es inferior a la versión parcheada 1.7.6, el servicio se encuentra dentro del rango de versiones afectadas.
Se puede concluir:
Service: InfluxDB OSS
Version: 1.6.6
Authentication: Enabled
CVE mapping: CVE-2019-20933
Impact: Authentication Bypass
Status: Version vulnerable
⇒ Reflexión: Inicialmente, el endpoint /query devuelve 401 Unauthorized, lo que indica que el mecanismo de autenticación está activo. Sin embargo, tener la autenticación habilitada no significa seguridad absoluta. Cuando la version se identifica como 1.6.6, debemos correlacionarla con los CVE conocidos. Los resultados indican que esta versión se encuentra dentro del rango afectado por CVE-2019-20933, lo que significa que es posible eludir el mecanismo de autenticación que protege el endpoint /query. Basándonos en estos resultados de identificación, la fase de explotación se centrará en verificar CVE-2019-20933 mediante la generación de un token JWT adecuado para eludir la autenticación y ejecutar consultas contra el endpoint /query.
La vulnerabilidad CVE-2019-20933 se produce en la función authenticate dentro del archivo services/httpd/handler.go de InfluxDB anterior a la versión 1.7.6.
InfluxDB admite la autenticación mediante JSON Web Tokens (JWT) para las solicitudes a la API HTTP. Al recibir una solicitud con la cabecera:
Authorization: Bearer <token>
InfluxDB realizará los siguientes pasos:
shared-secret del archivo influxdb.conf para que actúe como clave secreta en la verificación de la firma del token.username de los claims para determinar el usuario que ejecuta la consulta.En las versiones afectadas, si la autenticación JWT está habilitada pero el parámetro shared-secret no está configurado, el valor del secreto puede procesarse como una cadena vacía ("").
El sistema no logra validar adecuadamente la fortaleza de seguridad del secreto antes de verificar la firma del JWT. Esto permite a un atacante construir un JWT personalizado, firmarlo con un secreto vacío y luego establecer el claim username como una cuenta válida del sistema, como admin si esta cuenta existe en el laboratorio.
Cuando este token se envía a través de la cabecera Authorization: Bearer <token>, InfluxDB utiliza el mismo secreto vacío para verificar la firma. Si la firma coincide y el nombre de usuario existe, la solicitud será autorizada sin requerir la contraseña real del usuario.
El flujo de procesamiento se puede resumir de la siguiente manera: