• un conjunto de instrucciones iniciales del servidor,
• incluyendo el comando LOAD DATA LOCAL INFILE, que permite al servidor solicitar al cliente que le envíe un archivo local.

2.2. Problema

Adminer no valida correctamente las respuestas del servidor MySQL en las versiones vulnerables.

Resultado:

“Lee este archivo local en la máquina o contenedor que aloja Adminer y envíamelo.”

Este mecanismo está relacionado con el paquete MySQL: 0xFB | filename → desencadena la lectura local del archivo.

Por qué la versión 4.6.2 es vulnerable

Adminer 4.6.2 permitía a un usuario especificar un servidor MySQL externo y conectarse libremente. Sin embargo, MySQL también permitía —por defecto— el uso de:

• LOAD DATA LOCAL INFILE
• en modo automático cuando ciertos servidores solicitaban un archivo.

Por lo tanto: Adminer → se conecta al servidor malicioso → el servidor malicioso solicita un archivo → Adminer lo envía.

Esta es la esencia de la vulnerabilidad.

3. Condiciones de explotación

El atacante debe:

1. Alojar un servidor MySQL malicioso (Rogue MySQL Server).
2. Lograr que Adminer se conecte a su servidor:
   • mediante un error de configuración,
   • mediante una interfaz expuesta públicamente,
   • mediante una acción de un usuario (ataque de tipo “supply host”).
3. El servidor MySQL rogue envía un paquete LOAD DATA LOCAL INFILE.
4. Adminer lee un archivo local.
5. El archivo se envía al atacante.

No se necesita ninguna contraseña de root para exfiltrar un archivo local: es Adminer quien ejecuta la acción como una aplicación PHP en el servidor objetivo.

4. Consecuencias de la vulnerabilidad

4.1. Compromiso de la confidencialidad

El atacante puede:

• leer /etc/passwd (de la entidad que aloja adminer: máquina host o contenedor),
• leer /etc/shadow (según los permisos del usuario PHP),
• recuperar los archivos de configuración,
• robar las credenciales de conexión MySQL,
• extraer toda la información accesible por el usuario web.

4.2. Escalada de impacto

Con las credenciales MySQL robadas (paso secundario), luego puede:

• conectarse a la base interna real,
• leer los datos,
• escribir en las tablas,
• inyectar cargas maliciosas.

5. Demostración práctica (PoC) — Arquitectura del laboratorio

El PoC se realiza en un entorno aislado y contenedorizado para evitar cualquier riesgo.

5.1. Componentes del laboratorio

1. Adminer vulnerable (versión 4.6.2) Rol: víctima Expuesto localmente a través de localhost:8080
2. MySQL legítimo (opcional) Rol: simular una base de datos real
3. Rogue MySQL Server (Python) Rol: atacante Envía los paquetes 0xFB filename para forzar a Adminer a leer un archivo local.

5.2. Estructura de la carpeta

6. Desarrollo del PoC: ¿cómo se manifiesta la vulnerabilidad?

6.1. Iniciar el laboratorio

6.2. Conexión desde Adminer al Rogue Server

En http://localhost:8080:

• Sistema: MySQL
• Servidor: rogue_mysql:33306
• Usuario: cualquiera
• Contraseña: cualquiera

6.3. Desarrollo automático

1. Adminer envía el handshake.
2. El Rogue MySQL devuelve LOAD DATA LOCAL INFILE '/etc/passwd'.
3. Adminer lee /etc/passwd.
4. Adminer envía su contenido al rogue.
5. El rogue almacena el texto en stolen_file.txt.

6.4. Resultado observado

Usa el siguiente comando para observar los logs del rogue:

Resultado esperado:

Consulta el contenido del archivo stolen_file.txt:

Una vez dentro del contenedor, podrás visualizar los contenidos de los archivos, incluyendo stolen_file.txt

Resultado:

Este resultado demuestra la vulnerabilidad sin ambigüedad.

7. Medidas de mitigación

A. Actualizar Adminer (eso solo es suficiente)

Solución más fiable: Pasar a Adminer ≥ 4.6.3

Las versiones posteriores corrigen el comportamiento de red.

Lo que se corrigió en las versiones siguientes

A partir de Adminer 4.7.x, se introdujeron varias protecciones:

Adminer prohíbe ahora por defecto LOAD DATA LOCAL INFILE

Ya sea:

• desactivado por completo
• o activado solo cuando el usuario lo autoriza explícitamente

→ Resultado: tu rogue MySQL ya no puede exfiltrar archivos.

Adminer filtra las acciones del cliente antes de enviarlas al servidor

Esto evita que las conexiones externas utilicen funciones peligrosas.

Mecanismos adicionales de validación de entrada

Las nuevas versiones verifican:

• si el servidor objetivo es el esperado
• si la acción no es peligrosa
• si la solicitud corresponde a una acción de usuario legítima

B. Desactivar las conexiones externas

Limitar Adminer solo a los hosts internos:

• mediante firewall (OUTPUT + DOCKER NETWORKS),
• mediante proxy inverso filtrado,
• mediante configuración de red estrictamente localizada.

El Adminer de producción debe siempre apuntar a un MySQL interno.

C. Desactivar LOCAL INFILE en el lado de MySQL

Evita el robo a través del cliente MySQL legítimo:

o:

D. Nunca exponer Adminer públicamente

Adminer no debe ser accesible en Internet.

En producción:

• acceso limitado a través de VPN,
• SSO o autenticación fuerte,
• caducidad automática.

E. Eliminar Adminer después de su uso

Adminer debe ser visto como una herramienta temporal:

• se despliega para una tarea puntual,
• se elimina después.

8. Recursos y referencias fiables

• Source du script python utilisé : https://github.com/Gifts/Rogue-MySql-Server/blob/master/rogue_mysql_server.py
• Site officiel Adminer https://www.adminer.org/en/
• Sansec (publication initiale) https://sansec.io/research/adminer-4.6.2-file-disclosure-vulnerability
• Podalirius (explications techniques + PoC) https://podalirius.net/en/cves/2021-43008/
• vulhub : https://github.com/vulhub/vulhub/blob/master/adminer/CVE-2021-43008/

9. Resumen final

CVE-2021-43008 es una vulnerabilidad crítica de Adminer ≤ 4.6.2 que permite:

• a un atacante que controla un servidor MySQL,
• obligar a Adminer a leer un archivo local,
• y luego exfiltrar el contenido hacia el atacante.

Es una demostración perfecta de la importancia:

• del control de red,
• de las restricciones del cliente MySQL,
• de la no exposición de herramientas de administración,
• de la gestión de versiones de software.