Les exploits de vulnérabilité de l'API REST de WordPress se poursuivent

Cela fait près de deux semaines que l'équipe de sécurité de WordPress a révélé une vulnérabilité d'escalade de privilèges non authentifiée dans un point de terminaison de l'API REST en 4.7 et 4.7.1. La vulnérabilité a été corrigée silencieusement et la divulgation a été retardée d'une semaine pour donner aux propriétaires de sites WordPress une longueur d'avance sur la mise à jour vers 4.7.2. La semaine dernière, des centaines de milliers de sites vulnérables avaient déjà été dégradés et les rapports de dommages continuent d'affluer.

Au cours du week-end, les attaques ont augmenté et les entreprises de sécurité WordPress ont vu davantage de tentatives bloquées par leurs pare-feu. Sucuri, la société de sécurité de sites Web qui a signalé la vulnérabilité de WordPress, suivait la campagne "Hacked by w4l3XzY3" la semaine dernière et a estimé 66 000 dégradations. Cette campagne particulière a maintenant dépassé 260 000 pages indexées par Google. Il s'agit de l'une des près de deux douzaines de campagnes de défiguration ciblant la vulnérabilité.

"Au cours des dernières 24 heures, nous avons constaté une croissance moyenne des pages dégradées par campagne de 44%", a déclaré vendredi le PDG de Wordfence, Mark Maunder. « Le nombre total de pages dégradées pour toutes ces campagnes, tel qu'indexé par Google, est passé de 1 496 020 à 1 893 690. Cela représente une augmentation de 26 % du nombre total de pages dégradées en seulement 24 heures. »

Maunder a fait référence à un graphique Google Trends qui, selon lui, démontre le succès des campagnes de défiguration au cours de la semaine dernière. Le pic a commencé le jour où WordPress a révélé la vulnérabilité.

Cependant, White Fir Design, une autre société qui propose des services de sécurité, conteste les affirmations de Wordfence selon lesquelles 1,8 million de pages ont été piratées. Le chiffre d'environ 2 millions de pages est cité dans des rapports de la BBC, The Enquirer, Ars Technica, CIO.com et d'autres publications. White Fir Design soutient que les pages piratées qui ont été indexées par Google ne sont pas une représentation exacte.

Sucuri CTO Daniel Cid n'est pas non plus entièrement d'accord avec l'évaluation de la situation par Wordfence. Après avoir fait quelques recherches au cours du week-end, Sucuri estime que plus de 50 000 sites ont été piratés avec 20 à 30 pages par site dégradées. Cela représenterait environ un million dans la partie inférieure de l'estimation et pourrait atteindre 1,5 million.

Sucuri commence également à voir des tentatives plus sérieuses sur la vulnérabilité de l'API REST sous la forme d'attaques d'exécution de code à distance (RCE) sur des sites utilisant des plugins qui permettent l'exécution de PHP à partir de publications et de pages. Une de ces campagnes tente d'injecter un include PHP pour ajouter du contenu à partir d'un site compromis, puis d'injecter une porte dérobée cachée dans /wp-content/uploads.

"Les dégradations n'offrent pas de retours économiques, donc cela mourra probablement bientôt", a déclaré Cid. "Ce qui restera, ce sont les tentatives d'exécution de commandes (RCE) car cela donne aux attaquants le contrôle total d'un site - et offre de multiples façons de monétiser - et le SPAM SEO / lien d'affiliation / injections publicitaires. Nous commençons à les voir tentés sur quelques sites, et ce sera probablement la direction dans laquelle cette vulnérabilité sera utilisée à mauvais escient dans les jours, les semaines et peut-être les mois à venir.

Les pirates ciblent tous les sites qui n'ont pas été mis à jour vers la version 4.7.2 - il ne semble pas y avoir de modèle parmi eux. Un rapide coup d'œil aux résultats de Google pour les campagnes les plus actives montre que les sites compromis incluent des blogs, des médias, des sites Web gouvernementaux, éducatifs, sportifs, médicaux et technologiques.

Pourquoi l'API REST est activée par défaut

L'API REST WordPress est activée par défaut, car il est prévu que davantage de fonctionnalités d'administration et de plugin s'appuient sur l'API REST à l'avenir. Après les récentes attaques, plusieurs utilisateurs ont commenté la divulgation de la vulnérabilité pour demander pourquoi elle est activée par défaut.

"Le problème de sécurité est dans une fonctionnalité que je n'utilise sur aucun de mes sites (API REST) ​​et pourtant, cette fonctionnalité est d'abord activée par défaut et ensuite depuis WordPress 4.7, vous avez même besoin d'un plugin - ce qui pourrait introduire d'autres problèmes de sécurité - pour désactiver la fonctionnalité ? » un utilisateur (@ helios2121) a commenté le message. « Veuillez repenser votre approche de la sécurité. Créez des fonctionnalités que tout le monde n'a pas besoin d'accepter. Ou au moins donner un moyen de se retirer sans nécessiter de plugins supplémentaires.

Morten Rand-Hendriksen a ouvert un ticket de suivi pour discuter de la désactivation de l'API REST par défaut et de son activation uniquement lorsque l'administrateur du site le demande, ou qu'un thème ou un plugin en dépend.

Le core Committer Sergey Biryukov a confirmé que le plan est d'introduire plus de fonctionnalités de base qui s'appuient sur l'API REST. "Désactiver l'API REST, c'est comme désactiver admin-ajax.php - les deux casseront votre site", a déclaré Biryukov.

Rand-Hendriksen a demandé pourquoi les points de terminaison de contenu ne peuvent pas être protégés par défaut tout en permettant à l'API REST d'être activée par défaut à des fins d'administration. Un autre utilisateur a demandé pourquoi le point de terminaison Users n'est pas protégé par défaut (c'est-à-dire https://news.microsoft.com/wp-json/wp/v2/users ou https://www.obama.org/wp-json/wp /v2/users), ce qui "facilite plus que jamais l'obtention de tous les noms d'utilisateur" sur n'importe quel site utilisant 4.7+.

"Si vous voulez vraiment désactiver l'API REST sur votre ou vos sites, voici notre recommandation actuelle : limitez-la aux utilisateurs authentifiés", a déclaré le Core Committer James Nylen. "Cependant, nous voulons continuer à augmenter l'adoption et l'utilisation de l'API REST, et je m'attends à ce que même cette modification casse de plus en plus de fonctionnalités WP au fil du temps, telles que les thèmes et les intégrations pilotés par l'API."

Nylen recommande le plugin Disable JSON API pour ceux qui souhaitent suivre cette recommandation sur les sites utilisant WordPress 4.7+. Le plugin compte actuellement plus de 10 000 installations actives.

L'équipe de sécurité de WordPress a travaillé avec diligence pour atténuer les attaques en aidant les hébergeurs et les sociétés de sécurité à mettre en place des protections avant que le problème ne soit rendu public. Cependant, la divulgation complète de la vulnérabilité a été enterrée sur le blog Make/Core, un site qui n'est pas largement lu parmi les propriétaires de sites WordPress réguliers. Le lien vers la divulgation a été publié sous forme d'addendum au post précédent sur le blog d'actualités WordPress une semaine plus tard.

"Bien que j'apprécie la divulgation responsable de ce problème et les efforts pour le résoudre, j'espère que vous envisagez de faire de futures annonces via un nouveau message sur le site WordPress News, plutôt que de simplement ajouter une mise à jour à un message précédent", a commenté l'utilisateur @johnrork. sur la divulgation officielle. "Je ne suis probablement pas le seul qui aurait pu éviter d'être compromis si cela s'était affiché comme un nouvel élément dans mon lecteur RSS mercredi."

Ceux qui lisaient les blogs Make avaient une longueur d'avance sur la réparation de leurs propres sites et/ou des sites de leurs clients. Ceux qui dépendent du blog d'actualités WordPress pour obtenir des informations sur les mises à jour de sécurité ont probablement lu le message lors de sa publication initiale et ne sont jamais revenus voir la mise à jour une semaine plus tard. Un problème aussi grave justifiait la transparence de WordPress dans un nouveau message sur son blog d'actualités. Cela aurait également envoyé automatiquement un tweet à plus d'un demi-million de followers sur le compte WordPress officiel et le compte Facebook qui compte plus d'un million de likes.

Heureusement, le nombre de sites vulnérables qui ont également des plugins qui pourraient permettre aux attaquants de se greffer sur cette vulnérabilité est beaucoup plus petit. Les sites dégradés sont embarrassants mais faciles à réparer. Dans la plupart des cas, les administrateurs n'ont qu'à mettre à jour vers la version 4.7.2 et à restaurer les messages dégradés à la révision la plus récente. La plupart des propriétaires de sites n'ont aucune idée de la rapidité avec laquelle les exploits commencent à apparaître après la divulgation publique, mais cette situation a rappelé en douceur l'importance de la mise à jour de WordPress et l'avantage de laisser les mises à jour automatiques activées.