Le 14 août, notre équipe Threat Intelligence a découvert plusieurs vulnérabilités présentes dans Sauvegarde et restauration XCloner, un plugin WordPress installé sur plus de 30 000 sites. Cette faille donnait aux attaquants authentifiés, avec des capacités de niveau abonné ou supérieures, la possibilité de modifier des fichiers arbitraires, y compris des fichiers PHP. Cela permettrait à un attaquant de réaliser l’exécution de code à distance sur le serveur d’un site vulnérable. Alternativement, un attaquant pourrait créer une chaîne d’exploit pour obtenir un vidage de base de données en raison du même point de terminaison AJAX non protégé, entre autres. Le plugin contenait également plusieurs points de terminaison vulnérables à la falsification de requêtes intersites (CSRF).

Nous avons d’abord contacté l’équipe du plugin le 17 août 2020. Après avoir établi un canal de communication approprié, nous avons fourni les détails complets de la divulgation le 18 août 2020. L’équipe du plugin a rapidement publié un correctif initial le 19 août 2020 pour résoudre le plus problème grave, et ils ont publié un correctif supplémentaire le 8 septembre 2020 pour résoudre les problèmes restants.

Ceci est considéré comme un problème de sécurité critique pouvant conduire à l’exécution de code à distance sur le serveur d’un site vulnérable. Si vous n’avez pas encore mis à jour, nous vous recommandons fortement de mettre à jour immédiatement vers la version entièrement corrigée, 4.2.153.

Les utilisateurs de Wordfence Premium ont reçu une règle de pare-feu le 17 août 2020 pour se protéger contre tout exploit visant ces vulnérabilités. Les sites utilisant toujours la version gratuite de Wordfence ont reçu la même protection le 17 septembre 2020.

La description: Action AJAX non protégée contre l’écrasement arbitraire des fichiers et la divulgation d’informations sensibles
Produit concerné: Sauvegarde et restauration XCloner
Plugin slug: xcloner-sauvegarde-et-restauration
Versions concernées: 4.2.1 – 4.2.12
ID CVE: En attente.
Score CVSS: 9,9 (CRITIQUE)
Vecteur CVSS: CVSS: 3.1 / AV: N / AC: L / PR: L / UI: N / S: C / C: H / I: H / A: H
Version entièrement corrigée: 4.2.13

XCloner Backup and Restore est un plugin conçu pour fournir aux utilisateurs de WordPress des sauvegardes facilement personnalisables et une fonctionnalité de restauration simple à utiliser. La plupart des fonctionnalités du plugin sont alimentées par l’utilisation de diverses actions AJAX qui exécutent des fonctionnalités sans que la page ne soit actualisée à chaque fois.

            $this->loader->add_action('wp_ajax_get_database_tables_action', $xcloner_api, 'get_database_tables_action');
            $this->loader->add_action('wp_ajax_get_file_system_action', $xcloner_api, 'get_file_system_action');
            $this->loader->add_action('wp_ajax_scan_filesystem', $xcloner_api, 'scan_filesystem');
            $this->loader->add_action('wp_ajax_backup_database', $xcloner_api, 'backup_database');
            $this->loader->add_action('wp_ajax_backup_files', $xcloner_api, 'backup_files');
            $this->loader->add_action('wp_ajax_save_schedule', $xcloner_api, 'save_schedule');
            $this->loader->add_action('wp_ajax_get_schedule_by_id', $xcloner_api, 'get_schedule_by_id');
            $this->loader->add_action('wp_ajax_get_scheduler_list', $xcloner_api, 'get_scheduler_list');
            $this->loader->add_action('wp_ajax_delete_schedule_by_id', $xcloner_api, 'delete_schedule_by_id');
            $this->loader->add_action('wp_ajax_delete_backup_by_name', $xcloner_api, 'delete_backup_by_name');
            $this->loader->add_action('wp_ajax_download_backup_by_name', $xcloner_api, 'download_backup_by_name');
            $this->loader->add_action('wp_ajax_remote_storage_save_status', $xcloner_api, 'remote_storage_save_status');
            $this->loader->add_action('wp_ajax_upload_backup_to_remote', $xcloner_api, 'upload_backup_to_remote');
            $this->loader->add_action('wp_ajax_list_backup_files', $xcloner_api, 'list_backup_files');
            $this->loader->add_action('wp_ajax_restore_upload_backup', $xcloner_api, 'restore_upload_backup');
            $this->loader->add_action('wp_ajax_download_restore_script', $xcloner_api, 'download_restore_script');
            $this->loader->add_action('wp_ajax_copy_backup_remote_to_local', $xcloner_api, 'copy_backup_remote_to_local');
            $this->loader->add_action('wp_ajax_restore_backup', $this, 'restore_backup');
            $this->loader->add_action('wp_ajax_backup_encryption', $xcloner_api, 'backup_encryption');
            $this->loader->add_action('wp_ajax_backup_decryption', $xcloner_api, 'backup_decryption');
            $this->loader->add_action('wp_ajax_get_manage_backups_list', $xcloner_api, 'get_manage_backups_list');
    

Presque toutes ces actions AJAX étaient liées au /vendor/watchfulli/xcloner-core/src/Xcloner_Api.php fichier qui a agi comme un fichier source fonctionnel unique avec un contrôle de sécurité correspondant utilisé pour chaque fonction. Ces fonctions ont été protégées contre toute utilisation non autorisée par une fonction de contrôle de capacité check_access().

    /**
     * Checks API access
     */
    public function check_access()
    {
        if (function_exists('current_user_can') && !current_user_can('manage_options')) {
            $this->send_response(json_encode("Access not allowed!"));
        }
    }

Cependant, l’action AJAX utilisée pour restaurer les sauvegardes, wp_ajax_restore_backup, n’a pas accroché au Xcloner_Api.php fichier, et par conséquent, n’a pas traité le même check_access() fonction de vérification des capacités même si elle était incluse dans la fonction.

           $this->loader->add_action('wp_ajax_restore_backup', $this, 'restore_backup');

   /**
     * Restore backup api call
     */
    public function restore_backup()
    {
        $this->check_access();

        define("XCLONER_PLUGIN_ACCESS", 1);
        include_once(dirname(__DIR__).DS."restore".DS."xcloner_restore.php");

        return;
    }
}

Cela signifiait que les utilisateurs de bas niveau, comme les abonnés, pouvaient déclencher cette action et utiliser l’une des fonctions correspondantes présentes dans le xcloner_restore.php fichier. Cela comprend les fonctions suivantes:

  • write_file_action
  • restore_mysql_backup_action
  • list_backup_files_action
  • restore_finish_action
  • list_mysqldump_backups_action
  • list_backup_archives_action
  • restore_backup_to_path_action
  • get_current_directory_action

La fonction la plus critique était la write_file_action fonction, ce qui permettrait à un utilisateur de niveau abonné de remplacer tous les fichiers. Cette fonctionnalité pourrait donner aux attaquants la possibilité d’écraser le wp-config.php fichier contenant les informations d’identification de la base de données WordPress et d’autres paramètres importants. L’exploitation de cette vulnérabilité signifie qu’un attaquant pourrait écraser le wp-config.php dans un fichier vide afin que WordPress soit amené à penser qu’il y a une nouvelle installation. Cela permettrait alors à un attaquant de connecter sa propre base de données à un site affecté et de modifier les fichiers une fois qu’il a reconfiguré l’installation de WordPress. Alternativement, un attaquant pourrait écraser tout autre fichier avec une porte dérobée et l’utiliser pour accéder à l’ensemble du système de fichiers du site Web.

La deuxième fonction la plus critique est la get_current_directory , qui renvoie les informations d’identification de la base de données SQL pour le site, ainsi que le chemin absolu de l’installation. Si un attaquant pouvait localiser l’accès public à la base de données, il pourrait alors se connecter et voler des informations sensibles, ajouter un compte d’utilisateur administratif, supprimer des publications ou même rediriger le site en modifiant l’URL du site, entre autres activités malveillantes.

Les autres actions de plug-in ont en elles-mêmes moins de risques de dommages individuellement, cependant, un attaquant pourrait enchaîner un exploit de ces actions pour obtenir un vidage de la base de données SQL. En raison de la complexité que nécessiterait ce type d’attaque, il est peu probable qu’il soit activement exploité dans la nature.

La description: Falsification de demandes intersites
Produit concerné: Sauvegarde et restauration XCloner
Plugin slug: xcloner-sauvegarde-et-restauration
Versions concernées:
ID CVE: En attente.
Score CVSS: 8,8 (élevé)
Vecteur CVSS: CVSS: 3.1 / AV: N / AC: L / PR: N / UI: N / S: U / C: H / I: H / A: H
Version entièrement corrigée: 4.2.153

En plus d’un point de terminaison AJAX presque complètement non protégé, presque tous les points de terminaison du plugin étaient vulnérables à la falsification de requêtes intersites en raison d’un échec de mise en œuvre des nonces et des vérifications correspondantes.

Un attaquant pourrait utiliser une attaque CSRF pour déclencher une sauvegarde ou mettre à jour les options du plugin, ainsi que toutes les activités malveillantes décrites ci-dessus.

Calendrier de divulgation

14 août 2020 – Découverte initiale de la fonction vulnérable et analyse approfondie du plugin. Le processus de création de règle de pare-feu commence.
17 août 2020 – Règle de pare-feu testée et déployée auprès des utilisateurs premium de Wordfence. Prise de contact initiale avec l’équipe du plugin.
18 août 2020 – Nous envoyons tous les détails de divulgation.
19 août 2020 – Un correctif initial est publié pour résoudre la vulnérabilité AJAX non protégée.
20 août 2020 – Nous faisons un suivi pour divulguer que plusieurs points de terminaison restent sans protection CSRF.
28 août 2020 – L’équipe du plugin confirme qu’elle travaille sur le problème et publiera un correctif sous peu.
8 septembre 2020 – Un correctif final et suffisant est publié en version 4.2.153.
17 septembre 2020 – Les utilisateurs gratuits de Wordfence reçoivent la règle de pare-feu.

Conclusion

Dans l’article d’aujourd’hui, nous avons détaillé une faille dans le plugin XCloner Backup and Restore qui permettait aux utilisateurs authentifiés de modifier des fichiers arbitraires et d’exécuter n’importe quel code sur le serveur, ainsi que plusieurs vulnérabilités CSRF. Ces failles ont été entièrement corrigées dans la version 4.2.153. Nous recommandons aux utilisateurs de mettre immédiatement à jour vers la dernière version disponible, qui est la version 4.2.153 au moment de cette publication.

Sites utilisant Wordfence Premium ont été protégés de tout exploit visant cette vulnérabilité depuis le 17 août 2020. Les sites exécutant toujours la version gratuite de Wordfence ont reçu la même protection le 17 septembre 2020.

Si vous connaissez un ami ou un collègue qui utilise ce plugin sur son site, nous vous recommandons vivement de lui transmettre cet avis pour aider à garder ses sites protégés car il s’agit d’une mise à jour de sécurité critique.


Source link