Dificultad | Very Easy |
SO objetivo | Linux |
Servicios | MySQL/MariaDB |
Técnicas | Enumeración Nmap - Acceso remoto a base de datos - Enumeración de esquemas SQL |
Flag | Flag única |
Tiempo estimado | 15 minutos |
Introducción
Sequel es una de las máquinas del Starting Point de Hack The Box, pensada para introducir al lector en la enumeración y explotación de servicios de bases de datos expuestos en red. A diferencia de otras máquinas del Starting Point, aquí no hay una fase de escalada de privilegios en el sistema operativo: todo el reto se resuelve interactuando directamente con un servidor MariaDB mal configurado, que permite el acceso como usuario root sin contraseña.
El objetivo es sencillo de enunciar pero muy representativo de errores reales de configuración: encontrar el servicio de base de datos, conectarse a él y navegar por sus esquemas hasta dar con la información sensible (en este caso, la flag) guardada dentro de una tabla.
Conceptos clave
Antes de entrar en materia conviene tener claros un par de términos:
MySQL/MariaDB: motores de bases de datos relacionales muy usados en aplicaciones web. MariaDB es un fork de MySQL, compatible con el mismo protocolo y cliente.
root de la base de datos: es el usuario administrador del motor de base de datos, no el usuario root del sistema operativo. Tener acceso como root en MySQL permite leer y modificar cualquier base de datos, pero no implica automáticamente tener acceso al sistema Linux subyacente.
Esquema (schema): la estructura de una base de datos: qué tablas contiene y qué columnas tiene cada tabla.
Una mala práctica común (y el corazón de esta máquina) es dejar el usuario administrador de la base de datos sin contraseña y, además, exponer el puerto del servicio a redes que no deberían tener acceso directo a él.
Reconocimiento
Lanzamos un escaneo de nmap con detección de versiones (-sV) para identificar qué servicios están corriendo en el objetivo y con qué versión, ya que muchas veces la versión de un servicio delata configuraciones por defecto o vulnerabilidades conocidas.
nmap -sV -p- 10.129.155.90
Salida de nmap mostrando el resultado del escaneo sobre el puerto 3306.
El escaneo revela que el único puerto abierto de interés es el 3306/tcp, correspondiente al servicio mysql. El script mysql-info de nmap (que se ejecuta automáticamente en el escaneo de versiones) nos da información valiosa sin siquiera conectarnos manualmente:
Versión: 5.5.5-10.3.27-MariaDB-0+deb10u1, es decir, un MariaDB corriendo sobre Debian 10.
Auth Plugin: mysql_native_password, el mecanismo de autenticación estándar.
El sistema operativo detectado por huella (OS details) es Linux, coherente con el deb10u1 de la versión.
Con un solo servicio expuesto, la ruta de ataque queda bastante clara: todo pasa por ese motor de base de datos. El siguiente paso lógico es intentar conectarnos directamente con el cliente de mysql.
Enumeración
Primer intento de conexión
Probamos conectarnos como root (una prueba habitual cuando un servicio de base de datos queda expuesto, ya que muchas instalaciones por defecto o mal aseguradas dejan a este usuario sin contraseña):
mysql -h 10.129.155.90 -u root
Primer intento de conexión, que falla por un requisito de TLS/SSL, y segundo intento fallido usando un parámetro incorrecto.
La conexión falla con el error SSL is required, but the server does not support it. Esto es una contradicción propia del propio servidor: exige una conexión cifrada por TLS/SSL, pero al mismo tiempo no tiene el soporte correctamente configurado para completarla. Es un problema de configuración, no una medida de seguridad real.
Intentamos entonces indicarle al cliente que no use SSL con --ssl-mode=DISABLED, pero esa sintaxis no es válida para la versión del cliente mysql que tenemos instalada (unknown variable 'ssl-mode=DISABLED'), así que hay que usar la sintaxis equivalente para versiones más antiguas del cliente.
Conexión exitosa
Cambiamos el parámetro por --ssl=0, que es la forma en que los clientes MySQL más antiguos (como el de Kali/Debian en este caso) desactivan la negociación SSL:
mysql -h 10.129.155.90 -u root --ssl=0
Conexión exitosa a la base de datos como root, sin necesidad de contraseña.
La conexión se establece sin pedir contraseña alguna. Esto confirma la vulnerabilidad principal de la máquina: el usuario root de MariaDB no tiene contraseña asignada, y el servicio está expuesto a la red sin ninguna restricción adicional (como un firewall o un bind-address limitado a localhost).
Ya dentro del prompt de MariaDB, el siguiente paso natural es ver qué bases de datos existen en el servidor:
SHOW DATABASES;
Listado de bases de datos disponibles en el servidor.
Aparecen cuatro bases de datos: information_schema y performance_schema (que son internas de MySQL/MariaDB y no interesan para este reto), mysql (la base de datos de administración del propio motor) y, la que realmente llama la atención, htb: un nombre que claramente no es parte de una instalación estándar y que apunta a contenido puesto ahí específicamente para el reto.
Explorando la base de datos htb
Nos movemos a esa base de datos y listamos sus tablas:
USE htb;
SHOW TABLES;
Para entender qué información guarda cada tabla antes de consultarla, revisamos también su estructura de columnas con SHOW COLUMNS:
SHOW COLUMNS FROM config;
SHOW COLUMNS FROM users;
Tablas config y users dentro de la base de datos htb, junto con sus columnas.
La base htb contiene dos tablas:
users: con columnas id, username y email. Es la típica tabla de una aplicación, con datos de usuarios.
config: con columnas id, name y value. Este patrón nombre/valor es habitual para guardar parámetros de configuración de una aplicación, y es justo el tipo de tabla donde suelen "esconderse" datos sensibles como flags, credenciales o parámetros internos.
Dado ese patrón, la tabla config es la candidata más clara para revisar su contenido completo.
Explotación (obtención de la información sensible)
No hay una vulnerabilidad de inyección SQL ni de escalada que explotar aquí: el "exploit" real ya ocurrió al lograr autenticarnos como root sin contraseña. Lo que queda es simplemente consultar el contenido de la tabla config, algo que cualquier usuario con acceso de lectura sobre esa base puede hacer:
SELECT * FROM config;
Contenido completo de la tabla config, incluyendo la flag.
La tabla devuelve siete filas con distintos parámetros de configuración (timeout, security, auto_logon, max_size, flag, enable_uploads, authentication_method). Entre ellas está la fila con name = flag, cuyo valor es directamente la flag del reto:
7b4bec00d1a39e3dd4e021ec3d915da8
Es un buen recordatorio de que no toda vulnerabilidad requiere una técnica sofisticada: aquí el problema de fondo es que se guardó información sensible en texto plano dentro de una tabla de configuración accesible por cualquiera que logre autenticarse, combinado con un usuario administrador sin contraseña.
Flag
Flag: 7b4bec00d1a39e3dd4e021ec3d915da8
Obtenida al consultar la tabla config de la base de datos htb (ver Imagen 6).
Lecciones aprendidas / Conclusión
Sequel es una máquina corta, pero deja varias ideas muy aplicables a entornos reales:
Nunca dejar el usuario administrador de una base de datos sin contraseña, sobre todo si el servicio está expuesto más allá de localhost.
Restringir el acceso de red al motor de base de datos: un servicio como MySQL/MariaDB casi nunca debería estar accesible directamente desde fuera de la red interna de la aplicación; para eso existen los firewalls, las reglas de bind-address y las listas de control de acceso.
No almacenar secretos en texto plano dentro de tablas de configuración. Si una fila con nombre flag puede leerse en texto plano con un simple SELECT, en un entorno real esa misma tabla podría contener API keys, contraseñas de otros sistemas o tokens de sesión.
Configurar correctamente TLS/SSL si se va a exigir: un servidor que "exige" SSL pero no lo soporta correctamente no está agregando seguridad, solo fricción, y termina invitando a los atacantes (y administradores) a desactivarlo, como hicimos nosotros con --ssl=0.
Desde la perspectiva defensiva, esta máquina resume bien el principio de defensa en profundidad: ni la autenticación, ni la exposición de red, ni el almacenamiento de datos deberían depender de una sola capa de seguridad bien configurada.