Divulgation publique dans la matinée, exploitation dans la foulée. Le plugin OttoKit (ex-SureTriggers) souffre d’une vulnérabilité critique permettant à des attaquants de s’octroyer les droits admin d’un site sans avoir à s’identifier.
Si vous utilisez OttoKit, vous savez qu’il permet d’automatiser des actions entre WordPress et des services tiers comme WooCommerce, Google Sheets ou Mailchimp. Actif sur plus de 100 000 sites, le plugin fait aujourd’hui l’objet d’une alerte de sécurité particulièrement sensible. Le 10 avril, les équipes de Wordfence et Patchstack ont publié les détails d’une faille critique permettant à des tiers malveillants de contourner le mécanisme d’authentification de son API et de créer un compte administrateur sur les sites où il est installé. Moins de quatre heures après sa divulgation, les premières tentatives d’exploitation étaient déjà observées.
Une configuration incomplète à l’origine d’accès non sécurisés
Signalée dès le 13 mars par mikemyers dans le cadre du programme de bug bounty de Wordfence, cette vulnérabilité touche toutes les versions du plugin jusqu’à la 1.0.78. Sans trop jargonner, elle repose sur un défaut dans le mécanisme de vérification des requêtes envoyées à l’API d’OttoKit. Lorsque aucune clé API n’a été définie – ce qui est souvent le cas juste après l’installation –, le plugin traite certaines demandes comme légitimes, faute de pouvoir effectuer une vérification correcte.
Dans les faits, ce comportement hautement problématique permet à un attaquant d’envoyer directement une commande à l’API pour créer un nouveau compte administrateur sur le site, sans nom d'utilisateur ni mot de passe existants requis. Il ne s’agit pas d’un détournement de compte, mais bien de la création d’un accès complet par quelqu’un qui n’a rien à y faire, et qui peut alors s’en donner à cœur joie pour y injecter du code malveillant, modifier des contenus ou exfiltrer des données.
Alerté en amont de sa divulgation publique, OttoKit a déployé son correctif dès le 3 avril, avec la version 1.0.79 du plugin. Une semaine plus tard, le 10 avril, Wordfence a diffusé un billet détaillant les conditions d’exploitation de la faille… et déclenché une vague de tentatives d’intrusion quasi instantanée. Selon les analystes de Patchstack, les premières tentatives d’attaque ont été enregistrées moins de quatre heures après la publication de l’avis.
Les requêtes observées ciblaient un point d’entrée bien précis de l’API (/wp-json/sure-triggers/v1/automation/action), et contenaient des identifiants aléatoires générés automatiquement. Une mécanique caractéristique des attaques opportunistes, souvent menées en masse dès qu’une faille documentée est rendue publique.
Corriger, vérifier, prévenir : les bons réflexes à adopter
Dans son billet de blog, Wordfence a tenu à préciser que l’exploitation de la faille n’était possible que si le plugin était actif sans avoir été initialisé avec une clé API. Tous les sites ne sont donc pas exposés de la même manière. Pour autant, le scénario d’attaque reste suffisamment simple et automatisable pour justifier une réaction rapide.
Si vous utilisez OttoKit, mettez-le à jour vers la version 1.0.79 sans attendre. Pensez aussi à passer au crible les logs récents de votre site WordPress, à la recherche d’éventuels signes de compromission : création de comptes inattendus, installation de plugins inconnus, modifications des droits administrateur ou changements non sollicités dans les paramètres du site.
Et si ce n’est pas encore fait, pensez à activer les mises à jour automatiques pour vos extensions WordPress. Une simple case à cocher qui, à l’avenir, peut vous éviter bien des déconvenues.
Sources : Wordfence, Patchstack
