WordPress, l’outil de création CMS le plus populaire dans le monde, est aujourd’hui vulnérable via une “faille logique” qui pourrait permettre à un attaquant (hacker) distant de réinitialiser le mot de passe des administrateurs ou utilisateurs ciblés dans certaines circonstances.

La vulnérabilité (CVE-2017-8295) devient encore plus dangereuse, compte tenu du fait qu’elle affecte toutes les versions de WordPress, y compris la dernière version 4.7.4.

La faille de sécurité actuelle de WordPress a été découverte par Dawid Golunski , un chercheur polonais en sécurité informatique de Legal Hackers, en Juillet 2016.

Mais, tenez-vous bien, elle a été signalée à l’équipe de sécurité de WordPress qui aurait décidé d’ignorer cette question, laissant ainsi des millions de sites Web vulnérables à tout piratage, d’après Thehackernews.

La vulnérabilité réside dans la façon dont WordPress traite la demande de réinitialisation des mots de passe, pour l’utilisateur qu’il l’a initiée.

En général, lorsqu’un utilisateur demande de réinitialiser son mot de passe via le lien “Mot de passe oublié ?”, WordPress génère immédiatement un code secret unique et l’envoie à l’adresse email d’identification de l’utilisateur déjà stockée dans la base de données.

Détails de la vulnérabilité de WordPress

Lors de l’envoi de cet email de réinitialisation du mot de passe, WordPress utilise une variable appelée SERVER_NAME pour obtenir le nom d’hôte d’un serveur pour définir les valeurs des champs From/Return-Path.

Image via Thehackernews.com

“From” détermine ici l’adresse email de l’expéditeur et “Return-Path” se réfère à l’adresse email où finiront les courriels de renvoi du code en cas d’échec d’expédition.

Selon Golunski, notre chercheur polonais, un attaquant peut envoyer une requête HTTP falsifiée avec une valeur de nom d’hôte personnalisée prédéfinie (par exemple “attacker-mxserver.com”), tout en initiant le processus de réinitialisation de mot de passe d’un utilisateur “Admin” ciblé.

Étant donné que le nom d’hôte dans la requête HTTP malveillante est un domaine contrôlé par le pirate, les champs “From” et “Return-Path” dans le courriel de réinitialisation de mot de passe seront modifiés pour inclure une identification d’email associée avec le nom de domaine de celui de l’attaquant, c’est-à-dire wordpress@attacker-mxserver.com, au lieu de wordpress@nomdomaine-de-la-victime.com.

Et notre chercheur d’expliquer :

En raison de l’en-tête (header) d’hôte modifiée, le SERVER_NAME (nom_du_serveur) aura la valeur du nom d’hôte choisi par le hacker. Ainsi, WordPress va passer les Headers suivants et le corps du message dans le wrapper de “/usr/bin/sendmail”.

Pour info, le Wrapper permet d’insérer une page html ou php externe (sur le même domaine ou sur un autre domaine) dans la zone contenu du votre site. En d’autres termes, une fonction wrapper est un programme dont la fonction principale est d’appeler une autre fonction.

Ainsi, vous devez noter que le courriel de réinitialisation du mot de passe sera envoyé à l’adresse email de la victime (l’Admin) seulement, mais vu que les champs “From” et “Return-Path” pointent maintenant vers l’identification d’email de l’attaquant, le pirate pourra également recevoir le code de réinitialisation selon les scénarii suivants :

• Si la victime répond à ce courriel, sa réponse sera envoyée à l’adresse email de l’attaquant (mentionné dans le champ “From”), contenant un lien de réinitialisation du mot de passe dans l’historique des messages.

• Si, pour une raison quelconque, le serveur de messagerie de la victime est en panne (interrompu), le courriel de réinitialisation du mot de passe sera automatiquement renvoyé à l’adresse email mentionnée dans le champ “Return-Path” qui pointe vers la boîte de réception du hacker.

• Dans un autre scénario possible, pour récupérer avec force le courriel non distribué, l’attaquant peut effectuer une attaque DDoS contre le serveur de messagerie de la victime (l’Admin) ou envoyer un grand nombre de courriels, afin que le compte email de la victime ne puisse plus recevoir de courriels.

Bref, étant donné que la vulnérabilité est maintenant publiquement révélée sans qu’il y ait de correctif encore disponible fourni par WordPress à ce jour, les administrateurs de sites et blogs WordPress sont invités (par Thehackernews)  à mettre à jour leur configuration serveur pour activer “UseCanonicalName” afin de bloquer et maintenir la valeur “static/predefined SERVER_NAME”.

Si ça peut limiter les dégâts…