Overblog Suivre ce blog
Editer l'article Administration Créer mon blog
quoideneuf1.over-blog.com

Wordpress: Une vulnérabilité non corrigée pourrait permettre à des hackers de réinitialiser le mot de passe de l'administrateur

4 Mai 2017 , Rédigé par nicko Publié dans #informatique

WordPress, le CMS le plus populaire au monde, est touché par une vulnérabilité logique qui pourrait permettre à un attaquant distant de réinitialiser le mot de passe d'utilisateurs ciblés dans certaines circonstances.

 

Wordpress: Une vulnérabilité non corrigée pourrait permettre à des hackers de réinitialiser le mot de passe de l'administrateur

La vulnérabilité (CVE-2017-8295) parrait encore plus dangereuse après avoir appris qu'elle affecte toutes les versions de WordPress - y compris la dernière version 4.7.4.

La vulnérabilité sur WordPress a été découverte par le chercheur en sécurité Dawid Golunski de Légal Hackers en juillet l'année dernière. Malgré l'avoir signalé à l'équipe de sécurité de WordPress, celle-ci a décidé d'ignorer cette question, laissant des millions de sites Web vulnérables.

"Ce problème a été signalé à l'équipe de sécurité WordPress à plusieurs reprises avec le premier rapport envoyé en juillet 2016. Il a été signalé à la fois directement via le courrier électronique de sécurité, ainsi que via le site Web HackerOne", a déclaré Golunski dans un rapport publié aujourd'hui. "Comme il n'y a pas eu de progrès, dans ce cas, ce conseil est finalement publié au public sans correctif officiel".

Golunski est le même chercheur qui a découvert une vulnérabilité critique dans les bibliothèques open source populaires PHPMailer  qui a permis aux acteurs malveillants d'exécuter à distance un code arbitraire dans le contexte du serveur Web et ainsi de compromettre l'application Web cible.

La vulnérabilité réside dans la façon dont WordPress traite la demande de réinitialisation du mot de passe de l'utilisateur.

 En général, lorsqu'un utilisateur demande de réinitialiser son mot de passe par l'intermédiaire d'une option de mot de passe oublié, WordPress génère immédiatement un code secret unique et l'envoie à l'ID de courrier électronique de l'utilisateur déjà stocké dans la base de données.

 

 Quelle est la vulnérabilité?

Lors de l'envoi de ce courrier électronique, 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.

Wordpress: Une vulnérabilité non corrigée pourrait permettre à des hackers de réinitialiser le mot de passe de l'administrateur

Ici, "From" se réfère à l'adresse électronique de l'expéditeur et "Return-Path" se réfère à l'adresse e-mail où les e-mails "de renvois" devraient être livrés en cas d'échec dans la livraison pour une raison quelconque.

Selon Golunski, 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 lissant le processus de réinitialisation du mot de passe pour un utilisateur administrateur ciblé.

Étant donné que le nom d'hôte dans la requête HTTP malveillante est un domaine contrôlé par un attaquant, les champs de chemin de rebond dans l'email de réinitialisation de mot de passe seront modifiés pour inclure une adresse électronique associée au domaine de l'attaquant, c'est-à-dire wordpress@attacker-mxserver.com, au lieu de wordpress@victim-domain.com.

     "En raison de l'en-tête HOST modifié, le SERVER_NAME sera configuré sur le nom d'hôte du choix de l'attaquant. Par conséquent, Wordpress passera les en-têtes et le corps du courrier électronique suivants au fichier /usr/bin/sendmail", explique Golunski.

Ne vous y perdez pas ici: vous devez noter que le courrier électronique de réinitialisation du mot de passe sera livré uniquement à l'adresse électronique de la victime, mais comme les champs From et Return-Path indiquent maintenant l'ID de l'utilisateur et de l'attaquant, celui-ci peut également recevoir le code de réinitialisation dans les scénarios suivants :

1 Si, dans le cas où la victime répond à ce courrier électronique, elle sera envoyée à l'identifiant de l'utilisateur de l'attaquant (mentionné dans le champ «From») contenant un lien de réinitialisation du mot de passe dans l'historique des messages.
2 Si, pour une raison quelconque, le serveur de messagerie de la victime est en panne, le courrier électronique de réinitialisation du mot de passe renverra automatiquement à l'adresse électronique mentionnée dans le champ «Return-Path», qui indique la boîte de réception de l'attaquant.
3 Dans un autre scénario possible, pour récupérer avec force le courrier électronique de rebond, l'attaquant peut effectuer une attaque DDoS contre le serveur de messagerie de la victime ou envoyer un grand nombre d'emails afin que le compte de courrier électronique de la victime ne puisse plus recevoir de courrier électronique.

 

     "L'attaque CVE-2017-8295 pourrait être effectuée à la fois avec l'interaction de l'utilisateur (l'utilisateur frappant le scénario de bouton 'reply') ou sans interaction de l'utilisateur (envoyer sur la boîte aux lettres de la victime des spams afin de dépasser le quota de stockage)", a déclaré Golunski à TheHackerNews dans un courriel.

Pour une raison évidente, ce n'est pas une méthode de tir sûr, mais dans le cas d'attaques ciblées, les pirates informatiques sophistiqués peuvent exploiter cette lacune avec succès.

 Un autre fait notable sur lequel dépend l'exploitation réussie de ce défaut dépend du fait que même si le site Web de WordPress est faussé, tous les serveurs Web ne permettent pas à un attaquant de modifier le nom d'hôte via l'en-tête SERVER_NAME, y compris sur WordPress hébergé sur n'importe quel serveur partagé.

"L'en-tête du serveur SERVER_NAME peut être manipulé sur les configurations par défaut du serveur Web Apache (déploiement WordPress le plus courant) via l'en-tête HOST d'une requête HTTP", explique Golunski.

Étant donné que la vulnérabilité a été divulguée publiquement sans patch disponible auprès de la société de CMS populaire, les administrateurs de WordPress sont invités à mettre à jour leur configuration de serveur pour permettre à UseCanonicalName d'appliquer la valeur static/predefined SERVER_NAME.

 

Source: TheHackerNews

Partager cet article

Repost 0

Commenter cet article