Ein kurzzeitiger, aber sicherheitsrelevanter Vorfall bei der Wikimedia Foundation zeigt, wie angreifbar moderne Webplattformen durch Benutzerskripte in JavaScript sind. Ein selbstverbreitender JavaScript-Wurm manipulierte binnen Minuten tausende Seiten in Meta-Wiki und ersetzte individuelle Skripte mehrerer Nutzer. Die Stiftung reagierte mit einem befristeten Editier-Stopp in allen Wikimedia-Projekten, um die Ausbreitung zu unterbinden.
Wie der Sicherheitsvorfall in Meta-Wiki entdeckt wurde
Die ersten Hinweise auf den Angriff kamen direkt aus der Community. Aktive Bearbeiter bemerkten massive, automatisierte Aenderungen, bei denen zufaellige Seiten mit verborgenem JavaScript-Code und inhaltslosem „Muells“ angereichert wurden. In Diskussionen auf der Seite Village Pump (technical) wurde die Auffaelligkeit dokumentiert und zeitnah an die Technik-Teams der Wikimedia Foundation eskaliert.
Als Reaktion auf die auffaellige Aktivitaet verhängten die Entwickler vorsorglich ein temporäres Bearbeitungsverbot fuer saemtliche Wikimedia-Projekte. Solche „Freeze“-Massnahmen gelten in der Incident Response grosser Plattformen als etablierte Praxis, um selbstverbreitenden Code zu stoppen, Systeme zu stabilisieren und forensische Analysen zu ermoeglichen.
Ursprung des JavaScript-Wurms: Testskript in der russischsprachigen Wikipedia
Laut Eintrag im Bugtracker Phabricator fuehrt die Spur zu einem Benutzerskript in der russischen Wikipedia unter der Adresse User:Ololoshka562/test.js. Dieses JavaScript wurde bereits im Maerz 2024 hochgeladen und zuvor mit Tools in Verbindung gebracht, die bei anderen Angriffen auf Wiki-Instanzen im Einsatz waren.
Recherchen des Magazins BleepingComputer zufolge wurde das Skript in der vergangenen Woche von einem Mitarbeiter der Wikimedia Foundation im Rahmen von Tests zu Benutzerskripten ausgefuehrt. Offen ist derzeit, ob dies versehentlich, absichtlich oder über ein kompromittiertes Konto geschah. Solche Grauzonen sind in der Informationssicherheit haeufig: Ein formal legitimer Zugang wird genutzt, um schadhaften Code zu aktivieren.
Technischer Ablauf der Attacke: Ausnutzung von MediaWiki-Benutzerskripten
Die Plattform MediaWiki bietet globale und persoenliche JavaScript-Dateien, etwa MediaWiki:Common.js und User:<username>/common.js. Diese Skripte laufen im Browser eingeloggter Bearbeiter und dienen u. a. zur Oberflaechenanpassung und Automatisierung von Routineaufgaben. Genau dieses Feature wurde hier zum Angriffsvektor.
Sobald der schadhafte test.js-Code im Browser eines angemeldeten Nutzers ausgefuehrt wurde, versuchte der Wurm, globale und individuelle Skripte zu modifizieren. Ziel war es, sich dauerhaft festzusetzen und bei jedem erneuten Besuch automatisch geladen zu werden. Dadurch steigt die Chance, weitere Benutzerkonten schrittweise zu kompromittieren – ein klassisches Muster selbstverbreitender XSS-Wuermer.
Zusaetzlich rief der Wurm über Special:Random zufaellige Wiki-Seiten auf, fuegte ein Bild sowie einen versteckten JavaScript-Loader ein und lud von dort einen externen Code von der Domain basemetrika[.]ru nach. Diese Architektur – kleiner Initialcode mit Nachladen der Hauptfunktionalitaet von einem Fremdserver – ist typisch fuer moderne XSS-basierte Web-Wuermer und erschwert deren Erkennung und Analyse.
Ausmass des Schadens und Reaktion der Wikimedia Foundation
Nach Auswertung der Aenderungshistorien wurden durch den JavaScript-Wurm rund 3996 Seiten in Meta-Wiki manipuliert. Zudem waren die common.js-Dateien von etwa 85 Benutzern betroffen. Diese Konstellation birgt besonderes Risiko: Selbst nach Bereinigung der Inhalte koennen infizierte Benutzerskripte beim Login weiterhin Schadcode ausfuehren.
Die Sicherheitsteams der Wikimedia Foundation setzten die betroffenen common.js-Dateien grossflaechig zurueck und versteckten kompromittierte Seiten so, dass sie nicht mehr in der oeffentlichen Versionshistorie auftauchen. Nach Entfernung des eingefuegten JavaScript-Codes und Integritaetspruefungen zentraler Komponenten wurde die Bearbeitungsfunktion wieder freigegeben.
Nach Angaben der Stiftung war der schadhafte Code nur 23 Minuten aktiv und beschraenkte sich auf Meta-Wiki. Hinweise auf Angriffe auf andere Wikimedia-Projekte, einschliesslich der Wikipedia-Ausgaben, liegen offiziell nicht vor. Ebenso gibt es derzeit keine Anzeichen fuer Datenabfluesse oder Konto-Uebernahmen im grossen Stil. Betroffene Inhalte konnten aus Backups und Revisionen rekonstruiert werden.
Einordnung aus Sicht der Cybersicherheit: Lehren aus dem Vorfall
Der Vorfall ereignete sich im Rahmen einer Sicherheitspruefung von Benutzerskripten. Im Zuge dieser Analyse wurde ein zuvor inaktives Skript gestartet, das sich als Wurm entpuppte. Die schnelle Erkennung und die Entscheidung, das Editieren plattformweit zu sperren, entsprachen etablierten Incident-Response-Empfehlungen etwa der FIRST- und ENISA-Leitlinien.
Die Wikimedia Foundation kuendigte an, zusaetzliche Schutzmechanismen zu implementieren. Dazu zaehlen aus Sicht der Best Practices: striktere Rechtevergabe fuer Skriptbearbeitung, Sandbox-Umgebungen für Benutzercode, automatisierte statische und dynamische Codeanalyse, Anomalieerkennung bei Massenbearbeitungen sowie eine staerkere Absicherung privilegierter Konten (z. B. per Multi-Faktor-Authentifizierung und Härtung von Admin-Workstations).
Risiken von JavaScript-Benutzerskripten auf kollaborativen Plattformen
Der Meta-Wiki-Vorfall reiht sich in eine Serie bekannter XSS-Wuermer ein – von Samy auf MySpace bis zu spaeteren Angriffen auf Foren-, Blog- und Ticketing-Systeme. Gemeinsam ist ihnen, dass clientseitiger Code mit weitreichenden Berechtigungen ausgefuehrt wird, ohne ausreichend isoliert oder geprueft zu sein.
Fuer Betreiber von Plattformen mit Benutzerskripten ergeben sich daraus klare Handlungsfelder: restriktive Standardkonfiguration, Begrenzung der Moeglichkeiten für global ausgefuehrten Code, regelmaessige Audits privilegierter Skripte, Monitoring von auffaelligen Bearbeitungsmustern und Sensibilisierung der Community fuer sichere Skriptentwicklung und -nutzung.
Der aktuelle Vorfall verdeutlicht, wie schmal der Grat zwischen nuetzlicher Automatisierung und gravierender Sicherheitslücke ist. Betreiber, Administratoren und Power-User sollten ihre Richtlinien für Custom-JavaScript und andere Erweiterungsmechanismen kritisch überpruefen, technische Schutzmassnahmen ausbauen und zugleich in Schulungen investieren. Wo das Verstaendnis für die Funktionsweise solcher Angriffe steigt, sinkt die Wahrscheinlichkeit, dass der naechste „harmlose“ Testcode zum selbstverbreitenden JavaScript-Wurm wird.
