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

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

6.1. Démarrer le lab

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 :

Résultat attendu :

Consulter le contenu du fichier stolen_file.txt :

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

Résultat :

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 :

ou :

D. Ne jamais exposer Adminer publiquement

Adminer ne doit pas être accessible sur Internet.

En production :

• accès limité via VPN,
• SSO ou authentification forte,
• expiration automatique.

E. Supprimer Adminer après usage

Adminer doit être vu comme un outil temporaire :

• on le déploie pour une tâche ponctuelle,
• on le supprime ensuite.

8. Ressources et références 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. Résumé final

CVE-2021-43008 est une vulnérabilité critique d’Adminer ≤ 4.6.2 qui permet :

• à un attaquant contrôlant un serveur MySQL,
• d'obliger Adminer à lire un fichier local,
• puis à en exfiltrer le contenu vers l’attaquant.

C’est une démonstration parfaite de l’importance :

• du contrôle réseau,
• des restrictions client MySQL,
• de la non-exposition d’outils d’administration,
• de la gestion des versions logicielles.