WordPress 7.1.4 corrige une race condition du programme de mise à jour : comment Hive la bloque
WordPress 7.1.4 corrige une race condition dans le programme de mise à jour du cœur, qui permettait à un attaquant sans compte de prendre le contrôle d’un site pendant les quelques secondes que dure une mise à jour. Des attaquants la recherchent déjà, et ReportedIP Hive bloque ces requêtes sur chaque installation.
Mettez d’abord WordPress à jour. La suite de cet article explique la faille, pourquoi la plupart des pare-feu sous forme d’extension ne voient pas l’attaque et ce que fait Hive.
Qu’est-ce que la race condition corrigée par WordPress 7.1.4 ?
Lors d’une mise à jour complète du cœur, WordPress décompresse tout le paquet dans un dossier sous wp-content/upgrade/. Avant la 7.1.4, ce dossier portait un nom prévisible : le nom du paquet suivi d’un court suffixe aléatoire. L’étape de nettoyage supprimait en plus le fichier index.php qui protège normalement le dossier.
Pendant quelques secondes, ce dossier contient une copie complète et exécutable de WordPress. Un attaquant qui appelle à ce moment le fichier wp-admin/setup-config.php ou install.php de cette copie peut la relier à une base de données qu’il contrôle et finir par exécuter son propre code sur le serveur. Il n’a besoin ni de connexion ni d’une action d’un utilisateur.
La faille a été signalée par Umut Bayram. L’annonce officielle de WordPress 7.1.4 la décrit comme une faiblesse du processus de mise à jour pouvant mener à l’exécution de code à distance pendant la mise à jour. Au moment de la rédaction, aucun identifiant CVE ne lui a été attribué.
Quelles versions de WordPress sont concernées et lesquelles corrigent la faille ?
| Élément | Détail |
|---|---|
| Versions concernées | WordPress 4.7 à 7.1.3 |
| Quand un site est exposé | Uniquement pendant qu’un paquet complet du cœur est décompressé lors d’une mise à jour |
| Corrigé dans | 7.1.4, 7.0.8, 6.9.11, 6.8.12 |
| Branches plus anciennes | Correctifs rétroportés jusqu’à la 4.7.39 |
| Signalé par | Umut Bayram |
| CVE | Aucun attribué au moment de la rédaction |
Le correctif change trois choses. Le nom du dossier de décompression se termine désormais par 16 caractères aléatoires. Le fichier index.php de protection reste en place. Et wp-config.php n’est plus copié depuis le dossier de travail. Patchstack et HOL détaillent le correctif.
Les attaquants recherchent-ils déjà la faille de mise à jour ?
Les scans ont commencé juste après la publication. Wordfence a compté plus de 18 500 requêtes visant des chemins d’installation décompressés au cours des 21 premières heures, selon GBHackers. Les scanners interrogent sans cesse les noms de dossier probables et attendent qu’un site lance une mise à jour.
Pourquoi les pare-feu WordPress classiques ne voient-ils pas cette attaque ?
La copie décompressée démarre à partir de ses propres fichiers. Une requête vers wp-content/upgrade/…/wp-admin/setup-config.php ne charge jamais le vrai WordPress du site, donc aucune de ses extensions ne s’exécute. Un pare-feu intégré à une extension ne peut pas bloquer une requête qu’il ne voit jamais. Patchstack et Wordfence disent la même chose des pare-feu au niveau PHP.
Comment ReportedIP Hive protège-t-il contre cette race condition ?
Nous protégeons nos clients. Le WAF de Hive bloque ces requêtes, et la mise à jour Hive 3.0.6 a été déployée pour fermer la fenêtre de mise à jour sous Apache.
Une nouvelle signature WAF dans le flux de règles
Le flux de règles que reçoit chaque installation de Hive contient une signature pour cette attaque. Elle s’applique à toute requête vers un fichier PHP sous wp-content/upgrade/ ou wp-content/upgrade-temp-backup/. Aucune requête légitime ne charge du PHP depuis ces dossiers, la règle ne gêne donc pas les mises à jour normales.
- Elle est active dans toutes les formules, y compris Free.
- Les sites en mode Community Network la reçoivent automatiquement. Aucun réglage à modifier.
- En cas de correspondance, Hive répond par un code 403 et bannit l’IP dès la première requête.
- L’IP est partagée avec le Community Network, ainsi les IP qui scannent arrivent sur la liste de blocage partagée pour chaque site connecté.
Quand la requête atteint WordPress, Hive la bloque
Un WAF intégré à WordPress ne peut agir que sur les requêtes qui atteignent WordPress. Sous Apache, les requêtes vers des chemins de décompression qui n’existent pas aboutissent à WordPress, donc les scanners qui devinent de mauvais noms de dossier y sont repérés et bannis. Les sites où la protection étendue est activée lancent le pare-feu avant WordPress et restent protégés même pendant la décompression d’une mise à jour.
Hive 3.0.6 ferme la fenêtre de mise à jour sous Apache
Reste le dossier qui existe réellement pendant une mise à jour. Hive 3.0.6 le traite selon le serveur web :
- Apache : Hive écrit automatiquement une règle de réécriture dans le fichier
.htaccessà la racine du site. Elle envoie chaque requête PHP souswp-content/upgrade/vers WordPress, où le WAF la bloque, même en pleine mise à jour. - nginx : nginx ne lit pas les fichiers
.htaccess. Les réglages du pare-feu de Hive affichent un extrait prêt à ajouter au bloc server :location ^~ /wp-content/upgrade/ { rewrite ^ /index.php last; } - Local Shield : la règle fait aussi partie du jeu de règles de base fourni avec l’extension, les sites sans connexion au flux la reçoivent donc avec la mise à jour.
La mise à jour arrive par l’écran de mise à jour habituel de WordPress, comme la version Hive 3.0.5 avant elle.
Que doivent faire les propriétaires de sites WordPress maintenant ?
- Mettez WordPress à jour vers la version corrigée de votre branche : 7.1.4, 7.0.8, 6.9.11, 6.8.12 ou le rétroportage d’une branche plus ancienne.
- Cherchez dans les journaux d’accès des requêtes vers
setup-config.phpouinstall.phpsous/wp-content/upgrade/. - Vérifiez que
wp-content/upgrade/ne contient rien d’autre queindex.php. - Cherchez des comptes administrateur inconnus et des fichiers PHP dans
wp-content/uploads/.
Sans Hive, vous pouvez bloquer le dossier au niveau du serveur. Les règles ci-dessous refusent toute requête vers ce dossier :
# nginx, dans le bloc server
location ^~ /wp-content/upgrade/ { deny all; }
# Apache, dans le .htaccess à la racine
RedirectMatch 403 ^/wp-content/upgrade/Ces deux règles ont leur place dans la checklist de durcissement WordPress, avec ou sans Hive.
FAQ sur la version de sécurité WordPress 7.1.4
Les utilisateurs de Hive doivent-ils faire quelque chose ?
Les utilisateurs de Hive doivent seulement mettre WordPress à jour. La signature WAF arrive d’elle-même sur les sites connectés par le flux de règles, et la mise à jour Hive 3.0.6 écrit la règle Apache automatiquement. Sous nginx, ajoutez l’extrait affiché dans les réglages du pare-feu de Hive pour fermer aussi la fenêtre de mise à jour.
Un site est-il exposé quand aucune mise à jour n’est en cours ?
Un site n’est exposé que tant qu’un paquet complet du cœur se trouve décompressé dans wp-content/upgrade/, soit quelques secondes par mise à jour. En dehors de cette fenêtre, l’installateur décompressé n’existe pas. Les sites avec mises à jour automatiques du cœur passent par cette fenêtre d’eux-mêmes, la mise à jour vers 7.1.4 reste donc importante.
La règle de Hive bloque-t-elle les mises à jour normales de WordPress ?
La règle de Hive ne bloque pas les mises à jour. WordPress décompresse et copie les fichiers directement sur le serveur et ne charge jamais de PHP depuis le dossier de décompression via HTTP. Seules les requêtes externes vers ces fichiers PHP déclenchent la règle, et aucun visiteur ou service légitime ne les envoie.
ReportedIP Hive bloque les attaques de ce type sur chaque site connecté et partage les IP des attaquants avec le Community Network. La formule Free inclut le flux de règles WAF.