La description: Enregistrement d’administrateur non authentifié
Plugin concerné: Profile Builder (versions Free, Pro et Hobbyist affectées)
Versions concernées:
Score CVSS: 10.0 (Critique)
Vecteur CVSS:
CVSS: 3.0 / AV: N / AC: L / PR: N / UI: N / S: C / C: H / I: H / A: H
Version corrigée: 3.1.1

Plus tôt cette semaine, une vulnérabilité critique a été corrigée dans le Générateur de profils plugin pour WordPress. Cette vulnérabilité affectait la version gratuite disponible sur le référentiel WordPress.org, ainsi que les variantes commerciales Pro et Hobbyist. Selon le référentiel WordPress, plus de 50000 sites utilisent la version gratuite de Profile Builder, et nos estimations suggèrent qu’il y a environ 15000 installations des versions Pro et Hobbyist, pour un total estimé de 65000 sites affectés.

Les versions de Profile Builder jusqu’à 3.1.0 incluses sont affectées par cette vulnérabilité. Il est crucial que tout site exécutant une version vulnérable du plug-in soit immédiatement mis à jour vers la version 3.1.1 pour éviter tout compromis sur le site. Nous avons déployé une règle de pare-feu pour empêcher l’exploitation sur les sites exécutant Wordfence Premium. Les sites utilisant la version gratuite de Wordfence recevront la règle après trente jours.

Dans cet article, nous allons examiner la vulnérabilité et discuter de son impact. Nous détaillerons également certaines mesures qu’un propriétaire de site peut prendre pour atténuer le problème dans le cas où une mise à jour immédiate n’est pas possible.

Résumé de la vulnérabilité

Profile Builder est un plugin conçu pour créer des formulaires personnalisés qui permettent aux utilisateurs de s’inscrire, de modifier leurs profils, etc. Il comprend également un éditeur de rôles utilisateur personnalisé, permettant aux administrateurs d’attribuer des ensembles de privilèges personnalisés aux utilisateurs de leur site.

Pour implémenter ces rôles d’utilisateur personnalisés dans le processus d’enregistrement, le plugin propose des gestionnaires de formulaires pour attribuer un rôle sélectionné à un nouvel utilisateur. Ce champ de rôle d’utilisateur n’est pas présent par défaut, mais peut être ajouté par un administrateur pour fournir une liste des rôles approuvés dans un menu déroulant.

Un exemple de formulaire d'inscription Profile Builder avec un champ déroulant Rôle utilisateur.

Un exemple de formulaire d’inscription Profile Builder avec un champ déroulant Rôle utilisateur.

Malheureusement, un bogue dans le gestionnaire de formulaire a permis à un utilisateur malveillant de soumettre une entrée sur des champs de formulaire qui n’existaient pas dans le formulaire réel. Plus précisément, si l’administrateur du site n’a pas ajouté le champ Rôle utilisateur au formulaire, un attaquant pourrait toujours injecter une valeur de rôle utilisateur dans sa soumission de formulaire.

Lorsqu’un administrateur ajoute le sélecteur de rôle utilisateur à un formulaire, il doit sélectionner une liste de rôles approuvés pour les nouveaux utilisateurs. Si cette liste est créée, seuls les rôles approuvés seront acceptés par le gestionnaire de formulaire. Cependant, lorsque le champ Rôle utilisateur n’est pas présent et un attaquant soumet un rôle d’utilisateur de toute façon, il n’y a pas de liste de rôles approuvés et toute entrée est acceptée.

Ces deux problèmes se combinent pour permettre aux attaquants non authentifiés d’enregistrer des comptes d’administrateur sur des sites WordPress vulnérables. Avec les privilèges d’administrateur, un attaquant a effectivement pris le contrôle du site et peut déployer librement des malwares et autres backdoors.

Ces problèmes ont été corrigés à partir de la version 3.1.1 de Profile Builder.

Détails du patch

Comme nous l’avons mentionné dans le résumé ci-dessus, l’impact de cette vulnérabilité est provoqué par l’interaction de deux bugs plus petits.

Pour le premier bogue, le gestionnaire de formulaire du plug-in Profile Builder traiterait la saisie sur l’un des champs de formulaire possibles du plug-in, que ce champ soit présent ou non dans le formulaire. Pour corriger ce bogue, les développeurs ont créé la fonction de validation wppb_field_exists_in_form(). Cette validation est maintenant utilisée dans la fonction de gestionnaire de chaque champ de formulaire possible, empêchant l’injection de valeurs involontaires.

/**
 * Function that checks if a field type exists in a form
 * @return bool
 */
function wppb_field_exists_in_form( $field_type, $form_args ){
    if( !empty( $form_args ) && !empty( $form_args['form_fields'] ) ){
        foreach( $form_args['form_fields'] as $field ){
            if( $field['field'] === $field_type ){
                return true;
            }
        }
    }

    return false;
}

Corriger ce bogue empêche efficacement l’exploitation du second, mais les développeurs l’ont également judicieusement corrigé. En plus de confirmer la custom_field_user_role est présent sur le formulaire, le gestionnaire de champs refuse désormais explicitement les tentatives de création d’utilisateurs Administrateur.

/* handle field save */
function wppb_userdata_add_user_role( $userdata, $global_request, $form_args ){

    if( wppb_field_exists_in_form( 'Select (User Role)', $form_args ) ) {

        $roles_editor_active = false;
        $wppb_generalSettings = get_option('wppb_general_settings', 'not_found');
        if ($wppb_generalSettings != 'not_found') {
            if (!empty($wppb_generalSettings['rolesEditor']) && ($wppb_generalSettings['rolesEditor'] == 'yes')) {
                $roles_editor_active = true;
            }
        }

        if (isset($global_request['custom_field_user_role'])) {
            if ($roles_editor_active && is_array($global_request['custom_field_user_role'])) {
                $user_roles = array_map('trim', $global_request['custom_field_user_role']);
                $user_roles = array_map('sanitize_text_field', $user_roles);

                //don't allow administrator value. it should never be here but just in case make a hard check
                if (($key = array_search("administrator", $user_roles)) !== false) {
                    unset($user_roles[$key]);
                }

                $userdata['role'] = $user_roles;
            } else {
                $role = sanitize_text_field(trim($global_request['custom_field_user_role']));
                if( $role !== 'administrator' ) {//don't allow administrator value. it should never be here but just in case make a hard check
                    $userdata['role'] = $role;
                }
            }
        }
    }

    return $userdata;
}

Comme vous pouvez le voir dans le if() à la ligne 181, le code d’attribution de rôle d’utilisateur ne s’exécutera pas si wppb_field_exists_in_form() Retour False. De plus, les vérifications aux lignes 197 et 204 empêcheront l’attribution si le rôle prévu est administrator.

Évaluation de l’impact

Compte tenu de tous les facteurs de cette vulnérabilité, nous avons calculé son score de gravité CVSS à 10,0 (Critique). Voir le calcul CVSS ici.

Ce score a été déterminé en fonction des paramètres suivants:

  • Vecteur d’attaque: réseau
    • La vulnérabilité peut être exploitée via un accès HTTP (S) à un site affecté.
  • Complexité d’attaque: faible
    • Aucun effort excessif n’est requis d’un attaquant, juste la découverte d’une forme vulnérable.
  • Privilèges requis: aucun
    • La vulnérabilité est exploitée dans le processus d’enregistrement des utilisateurs, aucune authentification préalable n’est nécessaire.
  • Interaction avec l’utilisateur: aucune
    • Aucune interaction de l’administrateur du site n’est requise pour exploiter un formulaire vulnérable.
  • Portée: modifié
    • La vulnérabilité est présente dans un plugin ajouté à une application WordPress, mais une exploitation réussie permet un accès bien au-delà du plugin affecté lui-même.
  • Confidentialité: élevée
  • Intégrité: élevée
  • Disponibilité: élevée
    • Les trois scores d’impact de la CIA sont élevés dans les cas où une prise de contrôle complète du site est possible. Un attaquant disposant des privilèges Administrateur peut perturber le comportement du site, récolter des données et injecter du contenu malveillant à volonté.

Atténuation à court terme

Nous vous recommandons fortement de mettre à jour Profile Builder vers la version 3.1.1 dès que possible pour éviter un événement de sécurité critique sur votre site. Cependant, nous comprenons que certains utilisateurs peuvent être limités par des flux de travail de mise à jour et d’autres politiques qui peuvent ralentir une réponse appropriée.

Dans le cas où votre site utilise une version vulnérable de Profile Builder et ne peut pas être mis à jour immédiatement, il est possible d’atténuer la gravité de la vulnérabilité en modifiant vos champs de formulaire Profile Builder existants. Étant donné qu’un attaquant ne peut créer un compte administrateur que si le champ Rôle utilisateur n’existe pas dans le formulaire, vous pouvez ajouter ce champ et le limiter correctement à un ou plusieurs rôles autorisés.

Une capture d'écran de l'interface de Profile Builder, montrant la création d'un champ Select (User Role).

Une capture d’écran de l’interface de Profile Builder, montrant la création d’un champ Select (User Role).

Pour ajouter ce champ, accédez à la page “Champs de formulaire” dans le menu de la barre latérale de Profile Builder. En haut de cette page, une liste déroulante vous demandera de sélectionner une option. Choisissez l’option «Sélectionner (rôle utilisateur)» sous Avancé. Remplissez le formulaire qui apparaît en donnant au champ un nom et une description, puis sélectionnez le ou les rôles auxquels les nouveaux utilisateurs doivent être autorisés à accéder. Pour la plupart des sites, sélectionner Abonné et rien d’autre ne suffira.

Pour le répéter, il est toujours d’une importance cruciale que les utilisateurs concernés mettent à jour leurs plug-ins le plus rapidement possible, même lorsqu’une atténuation comme celle-ci est disponible. Cela ne doit être considéré que comme une mesure temporaire pour empêcher l’exploitation jusqu’à ce que vous puissiez patcher votre site.

Chronologie

  • 10 février 2020 – La version 3.1.1 de Profile Builder est publiée. «Mise à jour de sécurité» mentionnée dans le journal des modifications. Entrée WPVulnDB créé par le découvreur de la vulnérabilité.
  • 12 février 2020 – Nous avons déployé une règle de pare-feu pour protéger les utilisateurs de Wordfence Premium contre la vulnérabilité.
  • 24 février 2020 – Proof-of-concept (PoC) sera publié, selon l’article de WPVulnDB.
  • 13 mars 2020 – Règle de pare-feu à déployer sur les sites exécutant la version gratuite de Wordfence.

Conclusion

Les versions de Profile Builder jusque et y compris 3.1.0 ont été affectées par une vulnérabilité critique qui pourrait permettre aux pirates de prendre le contrôle d’un site à l’aide du plugin. Toutes les variantes du plugin, y compris Free, Pro et Hobbyist, contenaient les bogues responsables de ce problème. Ces bogues ont été corrigés dans la version 3.1.1 de toutes les variantes, publiée le 10 février.

Wordfence Premium les utilisateurs sont déjà protégés par une nouvelle règle de pare-feu, et les sites utilisant toujours la version gratuite de Wordfence recevront cette règle le 13 mars. Même avec une règle de pare-feu en place, nous vous recommandons vivement d’effectuer des mises à jour de sécurité pour atténuer complètement le risque pour votre site.

Pour l’instant, nous n’avons vu aucune indication d’activité malveillante cherchant à exploiter cette vulnérabilité. Nous continuerons de surveiller les nouvelles campagnes d’exploitation qui pourraient émerger au fil du temps et ferons rapport de nos constatations au fur et à mesure. Si vous pensez que votre site a pu être compromis en raison de cette vulnérabilité ou de toute autre, n’hésitez pas à contacter notre Équipe de nettoyage du site.

Selon l’entrée de la vulnérabilité dans WPVulnDB, le chercheur découvreur a l’intention de publier une preuve de concept détaillée (PoC) le 24 février. Alors qu’un mauvais acteur pourrait développer un script d’attaque en examinant les modifications apportées à la version corrigée avec peu de difficulté, la publication publique d’un PoC entraîne généralement une large exploitation par les pirates. Il est extrêmement important que tous les utilisateurs concernés mettent à jour vers la version 3.1.1 dès que possible. Pour aider à faire connaître ces préoccupations, veuillez envisager de partager ce rapport avec d’autres membres de la communauté WordPress.


Source link

%d blogueurs aiment cette page :