Est-ce le pire piratage de l'histoire de WordPress ?

Françaisالعربية Deutsch English Español हिन्दी Bahasa Indonesia 日本語 한국어 Português Русский 中文

Internet TechnologyBusiness NewsComputing/Software

Transcript

00:00:00WordPress a connu une série de failles récemment, dont la dernière est si grave

00:00:04qu'elle permet aux hackers de prendre le contrôle total du panneau d'administration : injection SQL, exécution de

00:00:09commandes shell, du très lourd. Vous ne vous souciez peut-être pas de WordPress, mais il propulse plus de 44 %

00:00:14des sites web mondiaux. Beaucoup de sites avec lesquels vous interagissez et auxquels vous confiez vos données

00:00:19tournent probablement sous WordPress et cette version vulnérable. Concrètement, voilà comment ça fonctionne :

00:00:25J'ai installé en local une version standard de base de WordPress et je peux lancer ce

00:00:29premier script pour vérifier si la vulnérabilité existe. Et vous voyez qu'on obtient la réponse

00:00:34HTTP 207, ce qui signifie qu'il est bien vulnérable. On peut donc lancer la deuxième vérification,

00:00:41c'est-à-dire ouvrir le shell interactif. Cela injecte du SQL dans le site, crée un nouvel utilisateur admin,

00:00:47puis téléverse une extension malveillante qui me permet d'interagir avec n'importe quel fichier du site.

00:00:52Plongeons au cœur du problème pour voir exactement comment ça marche.

00:00:58Ce dépôt que je consulte montre exactement comment injecter du SQL sur les sites WordPress vulnérables,

00:01:06soit n'importe quel site entre la 6.90 et 6.94 ou la 7.00 et 7.01. L'attaque débute en appelant un point de terminaison non authentifié,

00:01:14batch v1, qui permet de grouper d'autres requêtes qui sont elles-mêmes validées et soumises au contrôle des permissions.

00:01:20Le gestionnaire de batch possède deux tableaux parallèles censés rester synchronisés : validation et matches.

00:01:26Mais un bug faisait que lorsque la fonction wp pass URL échouait à cause d'un chemin invalide, seul validation était mis à jour.

00:01:33Ainsi, le même index utilisé pour parcourir les deux tableaux renvoyait des résultats désynchronisés. La PoC en profite :

00:01:41elle envoie un batch contenant une seule requête, un POST vers le point de terminaison v2 posts, qui contient lui-même un corps de requête.

00:01:48Comme la requête parente a été correctement validée comme une requête POST, toute requête dans le corps de la requête contourne la liste blanche des méthodes,

00:01:56vous permettant d'envoyer des requêtes GET. À l'intérieur de ce batch interne se trouve une requête GET vers un article inexistant, ce qui déclenche

00:02:02la désynchronisation précédente, poussant WordPress à exécuter la même requête via une fonction appelée get items où le champ author

00:02:10exclude correspond à author not in, que la version vulnérable interpôle en SQL sous forme de chaîne. En gros, puisque tout cela est exécuté,

00:02:18le SQL n'est pas échappé. La PoC utilise une série de requêtes qui permettent au final à une requête POST vers v2 users de créer

00:02:25un nouveau compte admin. Le dépôt détaille d'ailleurs toutes ces étapes : les cinq premières sont pré-authentification et exploitent le bug, mais la sixième est le comportement standard de WordPress

00:02:35pour les utilisateurs authentifiés, à savoir téléverser un paquet malveillant. Bon, comme mentionné plus tôt, il s'agit juste d'une version de base standard de WordPress. La vulnérabilité ne provient pas d'une extension malveillante,

00:02:46il suffit d'installer WordPress normalement. On lance d'abord ce script de vérification qui valide si la

00:02:52vulnérabilité peut être exploitée. Ensuite, on peut exécuter cette commande de lecture, par exemple, qui nous indique

00:02:57l'utilisateur et le nom de la base de données. On peut aussi exécuter du SQL sur le site pour découvrir,

00:03:03par exemple, quelle version de la base de données tourne actuellement. Et ce n'est même pas le pire !

00:03:07Le problème vraiment grave, c'est quand on crée un compte admin qui a les droits pour téléverser une extension malveillante,

00:03:15dans ce cas appelée web shell. Cela nous donne accès au shell du site web, ce qui signifie qu'on a maintenant accès à

00:03:22n'importe quel fichier sur ce site. Et cette attaque se déroule de la façon expliquée plus tôt dans la vidéo :

00:03:27après la création de l'admin, l'extension est téléversée, puis cet utilisateur est supprimé pour que la présence

00:03:34de l'extension et les actions effectuées soient plus compliquées à détecter. Pour montrer à quel point c'est grave, j'ai créé un autre script

00:03:38qui va créer un admin et le maintenir sur le système.

00:03:40J'ai donc ici un identifiant et un mot de passe. De retour sur le site, si je vais sur la route wp-login, je peux saisir cet

00:03:47identifiant et ce mot de passe, cliquer sur Connexion, et j'ai un accès total au panneau d'administration. Si tout cela vous paraît confus, ne vous inquiétez pas,

00:03:54j'ai aussi mis beaucoup de temps à le comprendre. Il est dit que la chaîne d'exploitation résultante était tellement

00:04:00complexe qu'il aurait fallu à un chercheur en sécurité humain des semaines, voire des mois, pour la découvrir et

00:04:05l'assembler tout seul. Aucun chercheur en sécurité n'aurait pu trouver et construire cette chaîne d'exploit

00:04:10en 10 heures sans l'IA. C'est assez effrayant, car des acteurs malveillants pourraient avoir des bots qui analysent

00:04:17les dépôts, vérifient les URL, attendant juste que des failles apparaissent pour les exploiter en un temps record grâce à l'IA.

00:04:23Un utilisateur sur Reddit a raconté que son site a été compromis à peine deux jours après la découverte de la faille.

00:04:27Comme il ne fait les mises à jour que le week-end, un attaquant a pu créer un nouvel admin et se connecter. Pour ceux qui sont

00:04:33vulnérables, le correctif a été publié dans la version 7.0.2, vous pouvez donc faire la mise à jour. C'est une histoire assez folle !

00:04:40Vous trouverez le dépôt et l'article que j'ai utilisés pour la PoC dans les commentaires. Et pourquoi pas

00:04:46vous abonner à Better Stack pour rester au courant de toute l'actualité tech ? J'espère que vous avez apprécié la vidéo,

00:04:50et comme toujours, on se retrouve dans la prochaine !

Key Takeaway

Une faille de désynchronisation dans l'API de base de WordPress (versions 6.90 à 7.01) permet d'obtenir un accès administrateur et un contrôle total sur le serveur, une chaîne d'attaque complexe développée en seulement 10 heures grâce à l'intelligence artificielle et désormais corrigée dans la version 7.0.2.

Highlights

Une vulnérabilité critique affecte les versions de WordPress allant de 6.90 à 6.94 ainsi que de 7.00 à 7.01.
Un dysfonctionnement de synchronisation dans le gestionnaire de requêtes par lots (batch v1) permet d'injecter du code SQL non échappé via le paramètre author_exclude.
L'exploitation de cette faille permet la création non authentifiée d'un compte d'administrateur, suivi de l'installation d'un web shell pour exécuter n'importe quelle commande système.
Les attaquants effacent le compte d'administrateur temporaire immédiatement après le téléversement du web shell afin d'échapper aux mécanismes de détection.
L'intelligence artificielle a réduit à 10 heures la création de cette chaîne d'exploitation d'une complexité extrême, un travail qui exigeait auparavant plusieurs mois à des chercheurs humains.
La version 7.0.2 de WordPress corrige la vulnérabilité et élimine le risque de prise de contrôle à distance.

Timeline

Portée et gravité de la vulnérabilité cœur de WordPress

Une faille critique du cœur de WordPress permet la prise de contrôle totale des serveurs sans passer par des extensions tierces.
Plus de 44 % des sites web mondiaux fonctionnent sous ce système de gestion de contenu et restent exposés tant qu'ils ne sont pas mis à jour.
Un script de vérification renvoie un code HTTP 207 qui confirme la présence de la vulnérabilité sur une installation standard.

Les failles récentes ouvrent la porte à des injections SQL et à l'exécution de commandes shell directement sur le système d'exploitation hôte. L'attaque ne nécessite aucun droit préalable ni aucune extension vulnérable installée. L'impact concerne une part majeure de l'infrastructure du Web.

Manière d'exploiter la désynchronisation dans le gestionnaire de requêtes par lots

L'attaque cible le point de terminaison non authentifié batch v1 sur les versions 6.90 à 6.94 et 7.00 à 7.01.
Un échec de la fonction wp_parse_url désynchronise les tableaux de validation et de correspondance du gestionnaire de batch.
Une requête GET imbriquée dans un POST passe outre la liste blanche des méthodes HTTP et exécute du SQL non échappé via le champ author_exclude.

Le gestionnaire de requêtes groupées conserve deux tableaux internes pour contrôler les permissions. Lorsqu'une URL est invalide, un seul tableau se met à jour, provoquant un décalage d'index. L'attaquant en profite pour contourner la validation des méthodes POST, déclencher la fonction get_items et exécuter une commande SQL permettant la création directe d'un compte administrateur.

Prise de contrôle du serveur et persistance de l'accès

L'injection d'un compte d'administrateur autorise le téléversement d'un paquet d'extension contenant un web shell.
La suppression immédiate du compte d'administrateur créé permet de masquer l'intrusion tout en conservant l'accès shell aux fichiers.
L'accès direct au panneau d'administration wp-login reste possible avec les identifiants générés par l'exploit.

L'exploit se déroule en six étapes, dont cinq s'exécutent avant toute authentification. Une fois le rôle administrateur obtenu, l'attaquant envoie une extension malveillante qui lui donne un contrôle complet sur les fichiers du serveur. L'effacement du compte de départ efface les traces dans le journal des utilisateurs tout en maintenant le shell actif.

Accélération du développement d'exploits par l'IA et correctif de sécurité

L'intelligence artificielle permet d'assembler des chaînes d'exploitation complexes en 10 heures au lieu de plusieurs mois de travail humain.
Des attaques automatisées compromises des sites non mis à jour seulement deux jours après la divulgation publique de la faille.
Le passage à la version 7.0.2 de WordPress colmate la vulnérabilité.

La complexité de cette chaîne d'attaque nécessitait auparavant des recherches approfondies de plusieurs semaines. Les cybercriminels déploient désormais des robots automatisés par l'IA capables d'analyser les dépôts de code et de concevoir des exploits en un temps record. Une mise à jour vers la version 7.0.2 interrompt le vecteur d'attaque.

Community Posts

Write about this video