**CVE-2021-43008 — Vulnérabilité Adminer **

Lecture arbitraire de fichiers via un serveur MySQL malveillant

1. Qu’est-ce qu’Adminer ?

Adminer est un outil web (PHP) permettant d’administrer facilement des bases de données MySQL, PostgreSQL, SQLite ou SQL Server. Il est couramment déployé comme alternative légère à phpMyAdmin.

Versions concernées : Adminer ≤ 4.6.2

---

2. Quelle est la nature de la vulnérabilité ?

2.1. Défaillance d’Access Control

Adminer autorise la connexion à n’importe quel serveur MySQL distant. Or, lors de la connexion à un serveur MySQL, le client (ici Adminer) accepte :

• un ensemble d’instructions initiales du serveur,
• dont la commande LOAD DATA LOCAL INFILE, qui permet au serveur de demander au client de lui envoyer un fichier local.

2.2. Problème

Adminer ne valide pas correctement les réponses du serveur MySQL dans les versions vulnérables.

Résultat : Un serveur MySQL contrôlé par un attaquant peut demander :

“Lis ce fichier local sur la machine ou conteneur qui héberge Adminer et envoie-le moi.”

Ce mécanisme est lié au paquet MySQL : 0xFB | filename → déclenche la lecture locale du fichier.

Pourquoi la version 4.6.2 est vulnérable

Adminer 4.6.2 permettait à un utilisateur de spécifier un serveur MySQL externe et de s’y connecter librement. Or, MySQL permettait en plus — par défaut — l’utilisation de :

• LOAD DATA LOCAL INFILE
• en mode automatique lorsque certains serveurs demandaient un fichier.

Donc : Adminer → connecte au serveur malveillant → le serveur malveillant demande un fichier → Adminer l’envoie.

C’est l’essence de la vulnérabilité.

---

3. Conditions d’exploitation

L’attaquant doit :

1. Héberger un serveur MySQL malveillant (Rogue MySQL Server).
2. Amener Adminer à se connecter à son serveur :
   • via une erreur de configuration,
   • via une interface exposée publiquement,
   • via une action d’un utilisateur (attaque de type “supply host”).
3. Le serveur MySQL rogue renvoie un paquet LOAD DATA LOCAL INFILE.
4. Adminer lit un fichier local.
5. Le fichier est renvoyé à l’attaquant.

Aucun mot de passe root n’est nécessaire pour exfiltrer un fichier local : c’est Adminer qui exécute l’action en tant qu'application PHP sur le serveur cible.

---

4. Conséquences de la vulnérabilité

4.1. Compromission de la confidentialité

L’attaquant peut :

• lire /etc/passwd (de l'entité qui héberge adminer : machine hôte ou conteneur),
• lire /etc/shadow (selon les permissions de l’utilisateur PHP),
• récupérer les fichiers de configuration,
• voler les identifiants de connexions MySQL,
• extraire toutes les informations accessibles par l’utilisateur web.

4.2. Escalade d’impact

Avec les identifiants MySQL volés (étape secondaire), il peut ensuite :

• se connecter à la vraie base interne,
• lire les données,
• écrire dans les tables,
• injecter des charges malveillantes.

---

5. Démonstration pratique (PoC) — Architecture du lab

Le PoC se fait dans un environnement isolé et conteneurisé pour éviter tout risque.

5.1. Composants du lab

1. Adminer vulnérable (version 4.6.2) Rôle : victime Exposé en local via localhost:8080
2. MySQL légitime (optionnel) Rôle : simuler une base réelle
3. Rogue MySQL Server (Python) Rôle : attaquant Il envoie les paquets 0xFB filename pour forcer Adminer à lire un fichier local.

5.2. Structure du dossier

adminer_CVE-2021-43008/
│
├── README.md
├── docker-compose.yml
│
└──rogue_mysql_server/
	├── rogue_mysql_server.py
	├── requirements.txt
	└── Dockerfile

---

6. Déroulement du PoC : comment la vulnérabilité se manifeste ?

6.1. Démarrer le lab

docker compose build && docker compose up -d

6.2. Connexion depuis Adminer au Rogue Server

Dans http://localhost:8080 :

• Système : MySQL
• Serveur : rogue_mysql:33306
• User : n’importe
• Mot-de-passe : n’importe

6.3. Déroulement automatique

1. Adminer envoie le handshake.
2. Le Rogue MySQL renvoie LOAD DATA LOCAL INFILE '/etc/passwd'.
3. Adminer lit /etc/passwd.
4. Adminer envoie son contenu au rogue.
5. Le rogue stocke le texte dans stolen_file.txt.

6.4. Résultat observé

Utiliser la commande suivante pour observer les logs du rogue :

docker logs -f rogue_mysql

Résultat attendu :

2025-11-27 16:59:54,248:INFO:Serving on ('0.0.0.0', 33306)
2025-11-27 17:02:55,213:INFO:Conn from: ('172.18.0.3', 37200)
2025-11-27 17:02:55,214:INFO:Last packet
2025-11-27 17:02:55,214:INFO:Query
2025-11-27 17:02:55,214:INFO:Requesting file: /etc/shadow
2025-11-27 17:02:55,215:INFO:-- Received file data
2025-11-27 17:02:55,215:INFO:Result length: 1 bytes
2025-11-27 17:02:55,215:INFO:Last packet
2025-11-27 17:02:55,216:INFO:Query
2025-11-27 17:02:55,216:INFO:Requesting file: /etc/passwd
2025-11-27 17:02:55,216:INFO:-- Received file data
2025-11-27 17:02:55,217:INFO:Result length: 920 bytes
2025-11-27 17:02:55,217:INFO:File content received: 919 bytes
2025-11-27 17:02:55,217:INFO:File saved to stolen_file.txt

Consulter le contenu du fichier stolen_file.txt :

docker exec -it rogue_mysql sh

Une fois à l'intérieur du conteneur, tu pourra visualiser les contenus des fichiers dont stolen_file.txt

# ls
mysql.log  requirements.txt  rogue_mysql_server.py  stolen_file.txt

# cat stolen_file.txt

Résultat :

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
_apt:x:100:65534::/nonexistent:/bin/false

Ce résultat démontre la vulnérabilité sans ambiguïté.

7. Mesures de mitigation

A. Mettre à jour Adminer (ça seule suffit)

Solution la plus fiable : Passer à Adminer ≥ 4.6.3

Les versions postérieures corrigent le comportement réseau.

Ce qui a été corrigé dans les versions suivantes

À partir d’Adminer 4.7.x, plusieurs protections ont été introduites :

Adminer interdit désormais par défaut LOAD DATA LOCAL INFILE

Soit :

• désactivé complètement
• ou activé uniquement lorsque explicitement autorisé par l’utilisateur

→ Résultat : ton rogue MySQL ne peut plus exfiltrer de fichiers.

Adminer filtre les actions du client avant envoi au serveur

Cela empêche les connexions externes d’utiliser des fonctions dangereuses.

Mécanismes supplémentaires de validation d’entrée

Les nouvelles versions vérifient :

• si le serveur cible est celui attendu
• si l’action n’est pas dangereuse
• si la requête correspond bien à une action utilisateur légitime

---

B. Désactiver les connexions externes

Limiter Adminer aux seuls hôtes internes :

• via firewall (OUTPUT + DOCKER NETWORKS),
• via reverse proxy filtré,
• via configuration réseau strictement localisée.

L’Adminer de production doit toujours pointer vers un MySQL interne.

---

C. Désactiver LOCAL INFILE côté MySQL

Empêche le vol via client MySQL légitime :

[mysqld]
local_infile=0

ou :