Le 4 mars 2021, l’équipe de Wordfence Threat Intelligence a lancé la divulgation responsable d’une vulnérabilité d’injection SQL aveugle basée sur le temps découverte dans Protection anti-spam, AntiSpam, FireWall par CleanTalk, un plugin WordPress installé sur plus de 100 000 sites. Cette vulnérabilité pourrait être utilisée pour extraire des informations sensibles de la base de données d’un site, y compris les e-mails des utilisateurs et les hachages de mots de passe, le tout sans se connecter au site.
Nous avons d’abord contacté le développeur du plugin le 4 mars 2021 et envoyé la divulgation complète le 5 mars 2021. Une version corrigée du plugin, 5.153.4, est sortie le 10 mars 2021.
Les utilisateurs de Wordfence Premium ont reçu des règles de pare-feu protégeant contre cette vulnérabilité le 4 mars 2021. Les sites exécutant toujours la version gratuite de Wordfence ont reçu la même protection le 3 avril 2021.
Le plugin CleanTalk WordPress a un certain nombre d’utilisations, mais l’un de ses principaux objectifs est de protéger les sites contre les commentaires de spam. Une partie de la façon dont il le fait consiste à maintenir une liste de blocage et à suivre le comportement des différentes adresses IP, y compris la chaîne utilisateur-agent que les navigateurs envoient pour s’identifier.
Malheureusement, le update_log fonction dans lib/Cleantalk/ApbctWP/Firewall/SFW.php qui a été utilisé pour insérer des enregistrements de ces demandes dans la base de données n’a pas pu utiliser une instruction SQL préparée.
public function update_log( $ip, $status ) {
$id = md5( $ip . $this->module_name );
$time = time();
$query = "INSERT INTO " . $this->db__table__logs . "
SET
id = '$id',
ip = '$ip',
status="$status",
all_entries = 1,
blocked_entries = " . ( strpos( $status, 'DENY' ) !== false ? 1 : 0 ) . ",
entries_timestamp = '" . $time . "',
ua_name="" . sanitize_text_field( Server::get("HTTP_USER_AGENT') ) . "'
ON DUPLICATE KEY
UPDATE
status="$status",
all_entries = all_entries + 1,
blocked_entries = blocked_entries" . ( strpos( $status, 'DENY' ) !== false ? ' + 1' : '' ) . ",
entries_timestamp = '" . intval( $time ) . "',
ua_name="" . sanitize_text_field( Server::get("HTTP_USER_AGENT') ) . "'";
$this->db->execute( $query );
}
Il y avait un certain nombre de fonctionnalités dans le code du plugin qui rendaient plus difficile la réussite d’une attaque par injection SQL.
De par sa conception, le update_log La fonction ne doit avoir été exécutée qu’une seule fois pour chaque adresse IP de visiteur. Cependant, il était possible de manipuler les cookies définis par le plugin, en envoyant une première requête pour obtenir un ct_sfw_pass_key cookie, puis définissant manuellement un autre ct_sfw_passed cookie et interdire sa réinitialisation.
De plus, la requête SQL vulnérable utilisée INSERT plutôt que SELECT. Étant donné que les données n’étaient pas insérées dans une table sensible, le INSERT query ne pouvait pas être utilisé par un attaquant pour exploiter le site en modifiant les valeurs de la base de données, ce qui rendait également difficile la récupération des données sensibles de la base de données.
Enfin, l’instruction SQL a utilisé le sanitize_text_field pour tenter d’empêcher l’injection SQL, et l’agent utilisateur a été inclus dans la requête entre guillemets simples.
Malgré ces obstacles, nous avons pu créer une preuve de concept capable d’extraire des données de n’importe où dans la base de données en envoyant des requêtes contenant des commandes SQL dans l’en-tête de requête User-Agent. Cet exploit pourrait être utilisé par des visiteurs non authentifiés pour voler les adresses e-mail des utilisateurs, les hachages de mots de passe et d’autres informations sensibles.
Les déclarations préparées sont cruciales
Nous avons pu exploiter avec succès la vulnérabilité de CleanTalk via le Injection SQL aveugle basée sur le temps technique, qui envoie des requêtes qui «supposent» le contenu d’une table de base de données et ordonne à la base de données de retarder la réponse ou de «dormir» si la supposition est correcte. Par exemple, une demande peut demander à la base de données si la première lettre de l’adresse e-mail de l’utilisateur administrateur commence par la lettre «c», et lui demander de retarder la réponse de 5 secondes si c’est vrai, puis essayer de deviner les lettres suivantes dans séquence. Il existe un certain nombre d’autres techniques d’injection SQL qui peuvent contourner de nombreuses formes de nettoyage des entrées traditionnelles en fonction de la construction exacte de la requête vulnérable.
C’est pourquoi il est essentiel de «préparer» toutes les requêtes de base de données avant de les envoyer réellement à la base de données. Les instructions préparées isolent chaque paramètre de requête et constituent de loin la défense la plus efficace contre l’injection SQL. Heureusement, WordPress offre un moyen incroyablement simple de le faire, en utilisant le $wpdb->prepare() une fonction. Si vous développez des plugins WordPress, des thèmes ou tout autre logiciel qui interagit avec une base de données, l’utilisation régulière de déclarations préparées garantira que votre logiciel sera beaucoup plus sécurisé.
Chronologie
4 mars 2021 – Wordfence Threat Intelligence termine la recherche d’une vulnérabilité dans le plugin CleanTalk. Nous publions des règles de pare-feu pour les clients Wordfence Premium et prenons contact avec les développeurs de plugins.
5 mars 2021 – Nous envoyons la divulgation complète aux développeurs de plugins.
10 mars 2021 – Une version corrigée du plugin est publiée.
3 avril 2021 – Les sites utilisant encore la version gratuite de Wordfence bénéficient d’une protection contre cette vulnérabilité.
Conclusion
Dans l’article d’aujourd’hui, nous avons couvert une vulnérabilité d’injection SQL dans le plugin Spam Protection, AntiSpam, FireWall by CleanTalk qui pourrait être utilisé pour extraire des informations sensibles de la base de données d’un site et expliqué pourquoi l’utilisation d’instructions préparées est une bonne pratique critique pour les développeurs de plugin.
Cette vulnérabilité a été corrigée dans la version 5.153.4, et nous vous recommandons fortement de mettre à jour immédiatement vers la dernière version du plugin, 5.156 au moment de la rédaction de cet article.
Wordfence Premium les utilisateurs ont reçu des règles de pare-feu protégeant contre ces vulnérabilités le 4 mars 2021, tandis que ceux qui utilisent encore la version gratuite de Wordfence ont reçu la même protection le 3 avril 2021.
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 cette vulnérabilité permet une violation de toute donnée confidentielle stockée dans la base de données d’un site.
Un merci spécial à l’analyste des menaces Chloe Chamberland pour son rôle déterminant dans le développement de l’exploit de preuve de concept pour cette vulnérabilité.
Source link