Type de vulnérabilité

• Catégorie : Injection SQL
• CWE-89 : Neutralisation incorrecte des éléments spéciaux utilisés dans une commande SQL (« SQL Injection »)

Cause racine

Le plugin accroche le filtre posts_request de WordPress via wp_ticket_com_posts_request(). Lors d'une recherche front-end non authentifiée, il finit par appeler emd_author_search_results(), qui lit le paramètre de recherche :

À ce stade, WordPress a déjà supprimé les magic quotes en utilisant wp_unslash(). Au lieu de paramétrer correctement la requête SQL, le plugin concatène l'entrée utilisateur brute dans une clause SQL LIKE au sein d'une sous-requête UNION.

Conceptuellement :

La vulnérabilité existe parce que l'entrée non fiable est incorporée dans SQL par concaténation de chaînes plutôt que par des requêtes paramétrées.

Le cœur de la vulnérabilité réside dans la manière dont le plugin construit sa requête SQL principale :

Analyse de la requête SQL vulnérable

• Le point de départ : Le plugin commence par une requête WordPress standard pour rechercher des publications, comme SELECT * FROM wp_posts WHERE post_title LIKE '%...%'.
• La concaténation non sécurisée : Le plugin prend la valeur du paramètre de recherche (s) et la colle directement dans la requête SQL. Il le fait sans utiliser la fonction sécurisée $wpdb->prepare() de WordPress ni aucune autre forme d'échappement.
• La sous-requête UNION : Le plugin ajoute une sous-requête UNION à la requête principale. Dans SQL, une UNION permet à un attaquant de combiner les résultats de la requête principale avec ceux de sa propre requête malveillante.
• La requête finale : La requête finale envoyée à la base de données devient une combinaison de la recherche prévue et du code SQL injecté par l'attaquant

Déroulement de l'attaque

Scénario d'attaque

Un visiteur normal effectue une recherche sur le site :

Le plugin intègre la valeur du paramètre s dans une requête SQL qui recherche des informations liées aux tickets.

Parce que le plugin concatène directement la valeur de recherche dans l'instruction SQL au lieu d'utiliser des requêtes paramétrées, une requête de recherche spécialement conçue peut modifier la logique SQL prévue. Un attaquant non authentifié peut exploiter ce comportement pour récupérer des informations sensibles de la base de données WordPress, telles que les noms d'utilisateur ou d'autres données stockées. Le résultat exact dépend de la configuration de l'application et des permissions de la base de données. À présent, un attaquant peut manipuler le paramètre s pour injecter son propre SQL. Par exemple, il pourrait saisir :

Cela rendrait la requête finale semblable à ceci :

Impact

L'exploitation réussie peut permettre à un attaquant de :

• Extraire des informations sensibles de la base de données.
• Énumérer les utilisateurs de WordPress.
• Lire les données de configuration de l'application.
• Accéder aux informations des tables de base de données spécifiques au plugin.
• Recueillir des informations utiles pour d'autres attaques.

Gravité

La NVD n'a pas encore publié sa propre évaluation CVSS.

Code vulnérable conceptuel

Remarque : L'éditeur n'a pas publié l'implémentation vulnérable complète. Ce qui suit illustre le modèle de codage vulnérable.

Pourquoi c'est vulnérable

L'instruction SQL est construite en concaténant directement l'entrée contrôlée par l'utilisateur dans la chaîne de requête. Puisque l'entrée n'est ni paramétrée ni échappée, elle peut modifier la structure de l'instruction SQL.

Code corrigé (conceptuel)

Pourquoi ce correctif fonctionne

L'utilisation de $wpdb->prepare() sépare la syntaxe SQL de l'entrée utilisateur. La base de données traite la valeur de recherche comme des données plutôt que comme du SQL exécutable, empêchant ainsi les attaquants de modifier la structure de la requête. Le correctif officiel de WP Ticket 6.0.5 remplace la construction de requête vulnérable par une implémentation correctement paramétrée.