Skip to content
KitploitKITPLOIT
HerramientasExploitsBlog
Log in
Enviar
HerramientasExploitsBlog
Enviar

¡Herramientas de Hacking, PenTest y Ciberseguridad para tu Arsenal de Seguridad!

Kitploit es un directorio de herramientas de hacking, ciberseguridad y pentesting. Descubre las últimas actualizaciones de proyectos para encontrar vulnerabilidades, analizar sistemas, automatizar pruebas y fortalecer tu seguridad.

··Feeds·Contacto·Privacidad·© 2026 Kitploit

Directorio de Herramientas

Categorías

Ver todas las categorías
Loading categories
CVE-2019-20933 — 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. | Kitploit
Herramientas/GitHubGitHub/dungsocool/cve-2019-20933
Autenticación y AutorizaciónAnálisis de VulnerabilidadesExplotaciónCTFPruebas de PenetraciónAprendizaje y EducaciónSeguridad de Bases de DatosLabs y Práctica
GitHubdungsocool/cve-2019-20933

CVE-2019-20933

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.

15hace 4 mesesAún no revisado

Más Populares

Ver todos →

Descubre las herramientas más usadas por nuestra comunidad.

Explora todas las herramientas

Explora nuestra colección de herramientas

Ver todas las herramientas →
Compartir
Ver Repositorio

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

image.png

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

image.png

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.

image.png

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>

image.png

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"

image.png

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?

image.png

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:

Descargar herramienta