All In One WP Security & Firewall 4.0.9 Patch de securité

Le 10 mai 2016, le plugin All In One WP Security & Firewall a corrigé plusieurs vulnérabilités de type SQL Injection détectées par notre équipe. Ces failles permettaient à n’importe quel visiteur de modifier des requêtes de base de données. Ceci représente un haut risque de sécurité.

Quelques explications

WordPress dispose de nombreuses API dont celle de la base de données. Cette API contient plein de wrappers, comprenez des fonctions qui utilisent de façon transparente l’API.

L’objet $wpdb permet de jouer avec la base de données pour faire des sélections, des insertions ou des suppressions (crud).

Comme tout développement, il faut se poser la question de “ai-je ici besoin de sécuriser cette ligne de code“.

Il arrive que du code faisant appel à une fonction qui fait elle même appel à une autre fonction masque la source des données à traiter, c’est là que les failles se cachent le plus souvent.

Toute donnée provenant de l’utilisateur (le navigateur aussi donc) DOIT être traitée comme si elle était malicieuse.

Les vulnérabilités

Les vulnérabilités présentes dans les versions inférieures à la 4.0.9 proviennent justement d’un manque de traitement de données utilisateurs.

Le DREAD score est évalué à 5/5 HIGH RISK. La mise à jour est obligatoire.

Ces failles permettent notamment à de simples visiteurs de modifier certaines requêtes SQL grâce à un simple paramètre dans l’URL.

Lisez la suite si vous voulez en savoir plus sur où est la faille et comment l’exploiter.

Dans le fichier /classes/wp-security-general-init-tasks.php on retrouve sur le hook init ce code :

if(isset($_GET['aiowps_auth_key'])){

            //If URL contains unlock key in query param then process the request

            $unlock_key = strip_tags($_GET['aiowps_auth_key']);

            AIOWPSecurity_User_Login::process_unlock_request($unlock_key);

        }

On y trouve un appel à la méthode process_unlock_request() de la classe AIOWPSecurity_User_Login. Elle prends en paramètre ce qui vient de $_GET['aiowps_auth_key'] avec un simple strip_tags().

Voyons cette méthode, que fait-elle avec notre paramètre :

static function process_unlock_request($unlock_key)

    {

        global $wpdb, $aio_wp_security;

        $lockdown_table_name = AIOWPSEC_TBL_LOGIN_LOCKDOWN;

        

        $unlock_command = "UPDATE ".$lockdown_table_name." SET release_date = now() WHERE unlock_key = '".$unlock_key."'";

        $result = $wpdb->query($unlock_command);

...

Le paramètre $unlock_key est directement concaténé dans une requête sans aucun autre traitement que le précédent strip_tags().

Sauf que ce n’est pas un traitement suffisant pour empêcher les injections SQL. Pour le faire, il faut “préparer” les requête comme suit :

$unlock_command = $wpdb->prepare( "UPDATE ".$lockdown_table_name." SET release_date = now() WHERE unlock_key = %s", $unlock_key );

L’équipe de AIOWPS a corrigé le problème très rapidement, tenez vous à jour !

À propos de Julio Potier Tous les articles de Julio Potier

Créateur de SecuPress et de la Formation LearnWPSecurity, Julio est aussi organisateur du WordCamp Lille.
Orateur compulsif, formateur sénior et ingénieur WordPress, il s’est spécialisé dans la sécurité depuis 2002 et contribue à WordPress sous diverses formes.