Plus de 600000 sites concernés par le correctif WP Statistics

Le 13 mars 2021, l’équipe de Wordfence Threat Intelligence a lancé une divulgation responsable d’une vulnérabilité dans Statistiques WP, un plugin installé sur plus de 600 000 sites WordPress.

La vulnérabilité permettait à tout visiteur du site d’extraire des informations sensibles de la base de données d’un site via l’injection SQL aveugle basée sur le temps.

Nous avons reçu une réponse à notre divulgation initiale le même jour, le 13 mars 2021, et avons envoyé la divulgation complète aux développeurs du plugin chez VeronaLabs. Un correctif pour cette vulnérabilité a été publié le 25 mars 2021.

Alors que notre rapport d’origine indiquait qu’un attaquant devait être authentifié pour exploiter cette vulnérabilité, nous avons depuis découvert qu’elle pouvait également être exploitée par des attaquants non authentifiés.

Heureusement, tous les sites exécutant Wordfence, y compris ceux utilisant Wordfence Premium ainsi que la version gratuite, sont protégés contre cette vulnérabilité par la protection intégrée des injections SQL du pare-feu Wordfence. Cette protection intégrée bloque la plupart des tentatives d’injection SQL même si une vulnérabilité n’est pas encore connue.

WP Statistics est un plugin WordPress qui permet aux propriétaires de sites de voir des statistiques détaillées sur les visiteurs de leur site, y compris les pages du site qu’ils visitent. En tant qu’administrateur, l’accès à l’élément de menu WP Statistics «Pages» génère une requête SQL afin d’afficher des statistiques sur les pages qui ont reçu le plus de trafic.

Alors que la page « Pages » était destinée uniquement aux administrateurs et n’afficherait pas d’informations aux utilisateurs non-administrateurs, il était possible de commencer à charger le constructeur de cette page en envoyant une requête à wp-admin/admin.php avec le page paramètre défini sur wps_pages_page. Étant donné que la requête SQL s’exécutait dans le constructeur de la page «Pages», cela signifiait que tout visiteur du site, même ceux sans connexion, pouvait provoquer l’exécution de cette requête SQL. Un acteur malveillant pourrait alors fournir des valeurs malveillantes pour le ID ou alors type paramètres.

class pages_page
{

    public function __construct()
    {
        global $wpdb;

        if (Menus::in_page('pages')) {

            // Disable Screen Option
            add_filter('screen_options_show_screen', '__return_false');

            // Check Exist Statistics For Custom Page
            if (self::is_custom_page()) {
                $page_count = $wpdb->get_var("SELECT COUNT(*) FROM " . DB::table('pages') . " WHERE `id` = " . esc_sql($_GET['ID']) . " AND `type` = '" . esc_sql($_GET['type']) . "'");
                if ($page_count < 1) {
                    wp_die(__('Your request is not valid.', 'wp-statistics'));
                }
            }

            // Is Validate Date Request
            $DateRequest = Admin_Template::isValidDateRequest();
            if (!$DateRequest['status']) {
                wp_die($DateRequest['message']);
            }
        }
    }

    public static function is_custom_page()
    {
        return (isset($_GET['ID']) and isset($_GET['type']));
    }

Malheureusement, alors que cette requête SQL utilisait esc_sql pour tenter d’échapper au ID et type paramètres d’entrée, il n’a pas utilisé une instruction préparée. Depuis le ID paramètre d’entrée n’a pas été cité, il était trivial de contourner le esc_sql fonction et générer des requêtes qui pourraient être utilisées pour extraire des informations sensibles du site.

Comme il s’agissait d’une vulnérabilité d’injection SQL aveugle basée sur le temps, l’exfiltration d’informations serait un processus relativement lent et il ne serait pas pratique de les utiliser pour extraire des enregistrements en masse, mais des informations de grande valeur telles que les e-mails des utilisateurs, les hachages de mots de passe et les clés de chiffrement. et les sels pouvaient être extraits en quelques heures à l’aide d’outils automatisés tels que sqlmap. Lors d’une attaque ciblée, cette vulnérabilité pourrait être utilisée pour extraire des informations personnellement identifiables à partir de sites commerciaux contenant des informations sur les clients. Cela souligne l’importance d’avoir des protections de sécurité avec un pare-feu de point de terminaison en place partout où des données sensibles sont stockées.

Nous récemment signalé sur une autre vulnérabilité d’injection SQL dans laquelle nous avons pu contourner un certain nombre de protections, et ceci est encore un autre exemple de la raison pour laquelle le simple fait d’échapper à l’entrée est insuffisant pour empêcher l’injection SQL. La seule méthode fiable pour empêcher l’injection SQL est de préparer toutes les instructions SQL avant de les exécuter, ce qui peut être effectué à l’aide de $wpdb->prepare(). Bien qu’il soit toujours possible de construire une requête vulnérable qui utilise une instruction préparée, il est très difficile de le faire involontairement.

Chronologie

13 mars 2021 – L’équipe Wordfence Threat Intelligence termine la recherche d’une vulnérabilité dans le plugin WP Statistics et contacte VeronaLabs. VeronaLabs répond et nous fournissons une divulgation complète.
15 mars 2021 – VeronaLabs répond avec une version fixe à tester et nous vérifions qu’elle corrige le problème.
25 mars 2021 – Une version corrigée du plugin, 13.0.8, est publiée.

Conclusion

Dans l’article d’aujourd’hui, nous avons discuté d’une vulnérabilité d’injection SQL aveugle basée sur le temps dans le plugin WP Statistics qui pourrait être utilisée pour extraire des données sensibles de n’importe quel site Web avec le plugin installé. Nous avons également expliqué pourquoi la désinfection et l’échappement des entrées ne sont pas suffisants pour se protéger contre les attaques par injection SQL.

Tous les utilisateurs de Wordfence, y compris Wordfence Premium les clients ainsi que ceux qui utilisent encore la version gratuite sont protégés contre cette vulnérabilité par la protection intégrée d’injection SQL de notre pare-feu.

Si vous avez installé ce plugin sur votre site, nous vous conseillons vivement de mettre à jour la version corrigée, 13.0.8, dès que possible. Si vous avez un ami ou un collègue qui utilise ce plugin sur son site, nous vous recommandons de lui transmettre cet avis pour aider à garder ses sites protégés car cette vulnérabilité permet aux attaquants d’accéder aux données confidentielles stockées dans la base de données d’un site.