Wikipedia dans une alerte de vers qui répond lors de la modification des scripts de l'utilisateur

Ce matin, la communauté Wikimedia et des milliers d'utilisateurs du monde entier se sont réveillés avec une nouvelle inquiétante : un script malveillant qui était auto-réplicable est venu à courir dans l'infrastructure du projet et a commencé à insérer du code caché et modifier des scripts utilisateurs dans plusieurs wikis. Les premiers avertissements viennent de Pompe de village (technique) de Wikipedia, où les éditeurs ont détecté une vague d'éditions automatiques qui ont ajouté des fragments de JavaScript invisibles et le vandalisme sur des pages aléatoires.

Ce qui s'est passé, expliqué en termes simples: MediaWiki - le logiciel qui déplace Wikipedia et des centaines de wikis connexes - permet aux administrateurs et aux éditeurs enregistrés de charger de petits fichiers JavaScript pour personnaliser l'expérience du site. Ces fichiers peuvent être globaux (par exemple,MediaWiki: Comun.js) ou spécifique à l'utilisateur (par exemple,Utilisateur: Votre nom / common.js). Le problème est, si un acteur malveillant obtient un code avec des privilèges d'édition à exécuter, il peut modifier ces fichiers et faire tourner le code sur les navigateurs d'autres utilisateurs, répandant ainsi l'infection.

Selon le dossier public de l'incident dans le système d'incident de la Fondation Wikimedia ( Phabicateur), la chaîne d'événements semble avoir commencé quand un script hébergé dans la Wikipédia russe a été invoqué et, à partir de là, un script global avec code nuisible a été modifié. Une copie archivée du script de problème est disponible dans la mémoire web: fichier test.js.

Mécanisme de propagation: le script malveillant a fonctionné sur trois fronts simultanés. D'abord il a essayé d'ajouter un "chargeur" au fichier JavaScript personnel de l'utilisateur qui l'avait exécuté, afin que la prochaine fois que l'utilisateur a navigué connecté, il charge le code nuisible de son espace personnel. Deuxièmement, si cet utilisateur avait les bonnes permissions, le script a essayé de modifier leMediaWiki: Comun.jspour le code à exécuter pour quiconque utilise ce script partagé. Et troisièmement, le Worm a inclus une routine de vandalisme qui a choisi des pages au hasard (par Spécial: Aléatoire) pour insérer une image et un bloc caché qui ont chargé le code externe depuis une URL malveillante.

La combinaison de ces trois vecteurs rend l'incident particulièrement dangereux : un seul navigateur touché peut devenir une graine pour une infection reproduite chez d'autres utilisateurs et, s'il atteint le script global, tout au long du projet.

Les premières analyses publiques reproduites par des moyens de sécurité indiquent que le ver a changé des milliers de pages et des dizaines de scripts utilisateurs. Le compte provisoire qui a circulé place les éditions environ 3 996 pages touchées et environ 85 utilisateurs qui ont vu lecommune.jC'est écrit. Lors de la réponse immédiate, l'équipe technique de la Fondation a temporairement limité la possibilité d'éditer dans divers projets pour arrêter la propagation tout en inversant les changements et en nettoyant les références au code injecté.

Pendant la phase de confinement, le personnel de la Fondation a également effectué des restaurations massives de lacommune.jde plusieurs utilisateurs et "supprimé" les pages modifiées afin que les changements malveillants ne soient pas visibles dans les documents publics. Au moment de la rédaction du présent document, le code injecté a été supprimé et l'édition a été rétablie, mais les principaux doutes subsistent : la Fondation n'a pas encore publié de rapport détaillé après incident précisant comment exactement le script a été exécuté et si l'exécution a été accidentelle, le résultat d'un test ou le résultat d'un compte compromis.

Pourquoi cet incident devrait nous concerner: au-delà du vandalisme, un tel ver a de graves implications pour la sécurité. Il peut servir de vecteur pour voler des jetons de session, effectuer des actions au nom des utilisateurs touchés, entrer des liens ou des scripts qui redirigent vers des serveurs externes pour suivre ou charger des logiciels malveillants, et saper la confiance dans le contenu du projet. En outre, la nature distribuée et ouverte de Wikipédia complique les mesures de défense automatique : de nombreuses protections sont construites sur la confiance entre éditeurs et dans les contrôles manuels qui nécessitent des heures de travail humain.

Le fait que le script ait hébergé le code qui le liait aux campagnes précédentes, suggérant qu'il ne s'agissait pas d'une expérience inoffensive mais d'un modèle qui a été vu auparavant dans l'écosystème wiki, selon des rapports qui ont tracé des scripts similaires dans d'autres incidents.

Ce que les utilisateurs peuvent faire maintenant: si vous avez récemment édité des wikis Wikimedia et risquez de télécharger le script, consultez votre page utilisateur (surtoutUtilisateur: Votre nom / common.js), supprime tout code suspect et restaure les scripts officiels des copies de confiance. Envisager de modifier les mots de passe et de permettre l'authentification de deux facteurs lorsque disponible. Documentation technique de MediaWiki sur l'utilisateur JavaScript est un bon point de départ pour comprendre quels fichiers peuvent être exécutés sur votre navigateur: Manuel : JavaScript (MediaWiki).

Pour la communauté et les responsables de logiciels, l'épisode devrait favoriser une réflexion profonde sur la nécessité de contrôles supplémentaires autour des pages qui lancent le code sur les navigateurs des éditeurs: examen obligatoire des changements dans les scripts globaux, meilleure télémétrie pour détecter les charges inhabituelles, et des processus plus stricts pour exécuter et tester des scripts dans des environnements isolés avant de les activer en direct.

Transparence et enseignements exceptionnels: la réponse technique immédiate a stoppé la propagation, mais l'absence de rapport technique complet rend difficile de savoir s'il y avait un accès non autorisé aux comptes du personnel, s'il y a un manque d'amélioration des autorisations internes et des processus d'essai, ou s'il y a des vulnérabilités dans les outils d'édition qui doivent être corrigés. La collectivité mérite une enquête publique et documentée qui explique les causes profondes et les mesures correctives proposées. Entre-temps, des outils provenant de tiers et de médias spécialisés tels que Calculateur ont publié des analyses préliminaires qui aident à contextualiser l'attaque, et le dossier d'incident à Phabicator sert de source principale pour le suivi par les techniciens et les bénévoles.

Cet incident rappelle que, dans les projets ouverts et collaboratifs à grande échelle, la sécurité n'est pas seulement la responsabilité des gestionnaires, mais un effort collectif : des protocoles clairs pour les tests internes, des audits de codes, des procédures d'intervention et une communication transparente sont des éléments essentiels. La communauté, les promoteurs et la Fondation doivent travailler ensemble pour combler les lacunes et rétablir la confiance.

Si vous participez en tant qu'éditeur à un wiki Wikimedia et détectez des comportements étranges - des retouches inattendues, des scripts cachés sur vos pages utilisateur, des éditions de masse non autorisées -, signalez-le immédiatement sur les canaux de support technique de la communauté (par exemple, Pompe de village (technique)) et suit les directives officielles publiées par la Fondation. Pour suivre l'enquête et les annonces officielles, vérifiez le suivi Phabicateur et la page d'état de Wikimedia dans status.wikimedia.org.

L'histoire ne se termine pas par l'élimination du code : le rapport post-incident, les mesures concrètes prises par la Fondation et l'évolution des pratiques de sécurité sur l'une des plateformes collaboratives les plus visitées de la planète. Pendant ce temps, la leçon est claire : sur le web ouvert, la confiance doit s'accompagner de contrôles techniques et de processus qui minimisent l'impact des échecs et des mauvais acteurs.