CMS : fichiers d'installation oubliés et reconnaissance par les URL

L’installation d’un CMS génère des répertoires et des scripts dédiés à la configuration initiale. Une fois l’installation terminée, ces fichiers doivent être supprimés. Quand ce n’est pas le cas, ils exposent une interface permettant de relancer la procédure, d’écraser la configuration en place ou de lire les credentials de la base de données.

Ce que les fichiers d’installation exposent

Réinstallation complète

Les assistants d’installation créent la base de données, définissent les credentials administrateur et écrivent les fichiers de configuration. Si l’assistant est de nouveau accessible, un attaquant peut lancer une nouvelle installation en pointant sur sa propre base de données, en choisissant ses propres credentials et en écrasant le fichier de configuration existant.

Lecture de la configuration en cours

Certains scripts d’installation affichent les paramètres de connexion détectés (hôte, base, utilisateur) pour guider l’utilisateur, ces informations sont visibles sans authentification si le script est accessible.

Vecteur d’accès à l’administration

Une réinstallation réussie crée un compte administrateur contrôlé par l’attaquant sur un CMS existant et possiblement déjà en production.

Fichiers et répertoires par CMS

WordPress

/wp-admin/install.php
/wp-admin/setup-config.php
/readme.html          → version WordPress en clair
/license.txt
/wp-config-sample.php

install.php redirige si la base est déjà configurée, mais setup-config.php peut permettre d’écraser wp-config.php sur certaines versions.

curl -s http://cible/wp-admin/install.php
curl -s http://cible/wp-admin/setup-config.php
curl -s http://cible/readme.html | grep -i "version"

phpBB

/install/
/install/index.php
/install/app.php

Le répertoire install/ donne accès à l’assistant complet de (ré)installation et de mise à jour. Sa présence seule suffit à déclencher une alerte.

curl -s http://cible/install/index.php

Joomla

/installation/
/installation/index.php
/CHANGELOG.txt        → version Joomla
/README.txt
/administrator/       → interface d'administration

Le répertoire installation/ contient l’assistant complet. Joomla affiche d’ailleurs un avertissement dans l’interface d’administration tant que ce répertoire est présent.

curl -s http://cible/installation/index.php
curl -s http://cible/CHANGELOG.txt | head -5

Drupal

/install.php
/update.php
/INSTALL.txt
/UPGRADE.txt
/CHANGELOG.txt        → version Drupal
/README.txt

update.php est particulièrement sensible : il applique les mises à jour de schéma de base de données et peut être exécuté sans authentification si la clé de maintenance n’est pas configurée.

curl -s http://cible/install.php
curl -s http://cible/update.php
curl -s http://cible/CHANGELOG.txt | head -3

PrestaShop

/install/
/install/index.php
/install-dev/
/CHANGELOG.txt
/docs/

Le répertoire install/ donne accès à l’assistant d’installation complet. PrestaShop lui-même bloque l’accès à la boutique tant que ce répertoire est présent, mais certains hébergements contournent cette vérification.

Magento

/setup/
/setup/index.php
/install.php
/RELEASE_NOTES.txt
/phpinfo.php          → parfois laissé par l'installateur

Autres fichiers révélateurs communs

/readme.html
/readme.txt
/README.md
/CHANGELOG.txt
/CHANGELOG.md
/VERSION
/version.txt
/phpinfo.php
/info.php
/test.php
/adminer.php          → interface d'administration MySQL
/phpmyadmin/

Ces fichiers révèlent au minimum la version du logiciel, ce qui oriente la recherche de CVE.

Énumérer les URL exposées

L’approche manuelle, taper des chemins connus, trouve les cas évidents. Un scanner automatise la découverte sur la totalité de la surface.

gobuster avec une wordlist CMS

# WordPress
gobuster dir \
  -u http://cible \
  -w /opt/SecLists/Discovery/Web-Content/CMS/wordpress.fuzz.txt \
  -s 200,301,302 \
  -t 30

# Joomla
gobuster dir \
  -u http://cible \
  -w /opt/SecLists/Discovery/Web-Content/CMS/joomla.txt \
  -s 200,301,302

# Wordlist générale CMS
gobuster dir \
  -u http://cible \
  -w /opt/SecLists/Discovery/Web-Content/CMS/cms-common.txt

ffuf

ffuf -u http://cible/FUZZ \
  -w /opt/SecLists/Discovery/Web-Content/CMS/wordpress.fuzz.txt \
  -mc 200,301,302 \
  -t 40

wpscan (WordPress uniquement)

# Scan non authentifié
wpscan --url http://cible --enumerate vp,vt,u

# Avec clé API pour les CVE récentes
wpscan --url http://cible --api-token VOTRE_CLE --enumerate vp,vt,u

wpscan détecte la version, les plugins et thèmes installés, et les comptes utilisateurs exposés via ?author=1.

Identifier la version pour cibler les CVE

La version du CMS oriente directement la recherche de vulnérabilités connues.

# WordPress, version dans readme.html
curl -s http://cible/readme.html | grep -i "version"

# Joomla, version dans le XML des manifestes
curl -s http://cible/administrator/manifests/files/joomla.xml | grep "<version>"

# Drupal, version dans CHANGELOG.txt
curl -s http://cible/CHANGELOG.txt | head -3

# PrestaShop
curl -s http://cible/CHANGELOG.txt | head -3

Rechercher ensuite sur https://www.cvedetails.com ou https://nvd.nist.gov en filtrant sur le produit et la version trouvée.

Workflow en pratique

1. Identifier le CMS
   curl -sI http://cible/ | grep -i "x-powered-by"
   → headers, générateur HTML (<meta name="generator">), structure des URL

2. Chercher les fichiers de version
   /readme.html  /CHANGELOG.txt  /VERSION
   → noter la version précise

3. Chercher les fichiers d'installation
   → chemins connus selon le CMS identifié
   → gobuster ou ffuf avec la wordlist CMS correspondante

4. Tester l'accessibilité des scripts sensibles
   curl -s http://cible/install.php
   curl -s http://cible/install/index.php
   → code 200 avec un formulaire → vulnérabilité confirmée

5. Rechercher des CVE sur la version identifiée
   → cvedetails.com, exploit-db.com, wpscan.com/vulnerability-list

À retenir

Les fichiers d’installation ne disparaissent pas seuls. Leur suppression fait partie de la procédure post-installation et doit être vérifiée. Les scripts qui restent accessibles sont souvent fonctionnels : un assistant d’installation affichant un formulaire est exploitable. La version révélée par les fichiers texte (readme.html, CHANGELOG.txt) suffit à identifier des CVE publiques sans authentification.