WordPress.org a publié une mise à jour de sécurité forcée pour le Loginizer plugin, qui est actif sur plus d’un million de sites Web. Le plugin offre une protection contre la force brute dans sa version gratuite, ainsi que d’autres fonctionnalités de sécurité telles que l’authentification à deux facteurs, reCAPTCHA et la connexion PasswordLess dans sa mise à niveau commerciale.
La semaine dernière, le chercheur en sécurité Slavco Mihajloski découvert une vulnérabilité d’injection SQL non authentifiée, et une vulnérabilité XSS, qu’il a révélée aux auteurs du plugin. La version 1.6.4 de Loginizer est sortie le 16 octobre 2020, avec des correctifs pour les deux problèmes, résumés sur le blog du plugin:
1) [Security Fix] : Un nom d’utilisateur correctement conçu utilisé pour se connecter peut conduire à une injection SQL. Cela a été corrigé en utilisant la fonction prepare en PHP qui prépare la requête SQL pour une exécution sûre.
2) [Security Fix] : Si l’en-tête HTTP IP a été modifié pour avoir un octet nul, cela pourrait conduire à un XSS stocké. Cela a été résolu en nettoyant correctement l’en-tête HTTP IP avant de l’utiliser.
Loginizer n’a divulgué la vulnérabilité qu’à ce jour afin de donner aux utilisateurs le temps de se mettre à niveau. Compte tenu de la gravité de la vulnérabilité, l’équipe des plugins de WordPress.org a diffusé la mise à jour de sécurité sur tous les sites exécutant Loginizer sur WordPress 3.7+.
En juillet 2020, Loginizer était acquis par Softaculous, la société a donc également pu mettre à niveau automatiquement toutes les installations WordPress avec Loginizer qui avait été créée à l’aide de Softaculous. Cet effort, combiné aux mises à jour de WordPress.org, a couvert une grande partie de la base d’utilisateurs de Loginizer.
La mise à jour automatique a surpris certains utilisateurs du plugin, car ils ne l’avaient pas initié eux-mêmes et n’avaient pas activé les mises à jour automatiques des plugins. Après plusieurs utilisateurs posté Sur le forum de support du plugin, Samuel Wood, membre de l’équipe des plugins, a déclaré que «WordPress.org a la capacité d’activer les mises à jour automatiques pour les problèmes de sécurité dans les plugins» et a utilisé cette capacité à plusieurs reprises.
Mihajloski publié une preuve de concept plus détaillée sur son blog plus tôt dans la journée. Il a également souligné certaines préoccupations concernant les systèmes mis en place par WordPress qui permettaient à ce type de vulnérabilité grave de passer entre les mailles du filet. Il affirme que le problème aurait pu facilement être évité par l’équipe de révision du plugin car le plugin n’utilisait pas la fonction prepare pour une exécution en toute sécurité des requêtes SQL. Mihajloski a également recommandé des audits de code récurrents pour les plugins dans le répertoire officiel.
« Lorsqu’un plugin entre dans le référentiel, il doit être revu, mais quand est-il revu? » Dit Mihajloski. «Tout le monde commence avec 0 installation active, mais que se passe-t-il sur 1 000, 10 000, 50 000, 100 000, 500 000, 1 mil + installations actives?»
Mihajloski était perplexe quant à savoir comment un problème de sécurité aussi flagrant pouvait rester si longtemps dans le code du plugin, étant donné qu’il s’agit d’un plugin de sécurité avec un nombre d’installations actives supérieur à celui de nombreux CMS bien connus. Le plugin a également récemment changé de mains lors de son acquisition par Softaculus et a été audité par plusieurs organisations de sécurité, y compris WPSec et Sécurité Dewhurst.
Mihajloski recommande également que WordPress améliore la transparence autour Sécurité, car certains propriétaires de sites et communautés fermées peuvent ne pas être à l’aise avec la gestion de leurs actifs par des inconnus sur WordPress.org.
« WordPress.org en général est transparent, mais il n’y a aucune déclaration ou document sur qui, comment et quand décide et effectue des mises à jour automatiques », a déclaré Mihajloski. «C’est en quelque sorte [like] tenant tous vos œufs dans le même panier.
«Je pense que ce sont les points cruciaux sur lesquels WP.org devrait se concentrer et que tout sera mis en place dans un court laps de temps: une documentation technique WordPress complète pour les avertissements de sécurité, un guide pour la divulgation des bogues (par des chercheurs, mais aussi par un fournisseur aspect) et des audits de code récurrents pour les plugins populaires. »
Source link