Wikipedia In A Worm Alert, die bei der Änderung von Benutzerskripten

Heute Morgen erwachten die Wikimedia-Gemeinschaft und Tausende von Nutzern auf der ganzen Welt mit einer störenden Nachricht: Ein schädliches Skript, das selbst repliziert wurde, lief innerhalb der Projektinfrastruktur und begann, versteckte Codes einzufügen und Benutzerskripte in mehrere Wikis zu modifizieren. Die ersten Warnungen kamen aus Dorfpumpe (technisch) aus Wikipedia, wo die Editoren eine Welle von automatischen Editionen entdeckten, die unsichtbare JavaScript-Fragmente und Vandalismus auf zufälligen Seiten hinzugefügt.

Was geschah, erklärt in einfachen Begriffen: MediaWiki - die Software, die Wikipedia und Hunderte von verwandten Wikis bewegt - ermöglicht es Administratoren und registrierten Editoren, kleine JavaScript-Dateien zu laden, um die Website-Erfahrung anzupassen. Diese Dateien können global sein (z.MediaWiki: Comun.js) oder Benutzerspezifisch (z.Benutzer: Ihr Name / common.js) Das Problem ist, wenn ein schädlicher Schauspieler bekommt einen Code mit Editing-Privilegs zu laufen, kann es diese Dateien ändern und den Code auf anderen Benutzer-Browsern laufen lassen und so die Infektion verbreiten.

Laut der öffentlichen Aufzeichnung des Vorfalls im Zwischenfallsystem der Wikimedia Foundation ( Phabicator), die Kette von Ereignissen scheint gestartet zu haben, als ein in der russischen Wikipedia gehostetes Skript aufgerufen wurde und von dort ein globales Skript mit schädlichem Code geändert wurde. Im Webspeicher steht eine archivierte Kopie des Problemskripts zur Verfügung: Datei test.js.

Fördermechanismus: das schädliche Skript arbeitete an drei gleichzeitigen Fronten. Zuerst versuchte er einen "loader" der persönlichen JavaScript-Datei des Benutzers hinzuzufügen, die sie ausgeführt hatte, so dass er das nächste Mal, wenn der Benutzer verbunden segelte, den schädlichen Code aus seinem persönlichen Raum laden würde. Zweitens, wenn dieser Benutzer die richtigen Berechtigungen hatte, versuchte das Skript, dasMediaWiki: Comun.jsfür den Code für jeden, der dieses gemeinsame Skript verwendet. Und drittens, die Worm enthalten eine Routine des Vandalismus, die Seiten zufällig gewählt (durch Besonderes: Random) ein Bild und einen versteckten Block einfügen, der den externen Code von einer bösartigen URL geladen hat.

Die Kombination dieser drei Vektoren macht den Vorfall besonders gefährlich: ein einzelner Browser kann Samen für eine in anderen Benutzern replizierte Infektion werden und, wenn es das globale Skript erreicht, während des gesamten Projekts.

Die ersten öffentlichen Analysen, die mit Sicherheit repliziert werden, zeigen, dass der Wurm Tausende von Seiten und Dutzende von Benutzerskripten verändert hat. Die vorläufige Zählung, die zirkulierte, stellt die Ausgaben rund 3,996 Seiten betroffen und etwa 85 Benutzer, die sah diehäufig.jsüberschrieben. Während der unmittelbaren Reaktion begrenzte das technische Team der Stiftung zeitweilig die Möglichkeit, in verschiedenen Projekten zu bearbeiten, um die Verbreitung zu stoppen, während Änderungen und Reinigungsreferenzen auf den injizierten Code umkehren.

Während der Eindämmungsphase führten die Mitarbeiter der Stiftung auch massive Restaurierungen derhäufig.jsvon mehreren Benutzern und "deleted" die geänderten Seiten, so dass die schädlichen Änderungen in öffentlichen Aufzeichnungen nicht sichtbar waren. Zu diesem Zeitpunkt wurde der injizierte Code entfernt und die Ausgabe wiederhergestellt, aber wichtige Zweifel bleiben: Die Stiftung hat noch keinen detaillierten Post-Incident-Bericht veröffentlicht, in dem erläutert wird, wie genau das Skript ausgeführt wurde und ob die Ausführung versehentlich war, das Ergebnis eines Tests oder das Ergebnis eines kompromittierten Kontos.

Warum dieser Vorfall uns betrifft: Über den Vandalismus hinaus hat ein solcher Wurm ernste Sicherheitsaspekte. Es kann als Vektor dienen, um Sitzungstoken zu stehlen, Aktionen im Auftrag der betroffenen Benutzer durchführen, Links oder Skripte eingeben, die auf externe Server zum Tracking oder Laden von Malware umleiten und das Vertrauen in Projektinhalte untergraben. Darüber hinaus kompliziert die verteilte und offene Natur Wikipedia automatische Abwehrmaßnahmen: Viele Schutzmaßnahmen werden auf Vertrauen zwischen Redakteuren und in manuellen Steuerungen gebaut, die Stunden menschlicher Arbeit benötigen.

Ebenfalls relevant ist die Tatsache, dass das Skript den Code beherbergte, der ihn mit früheren Kampagnen verknüpfte, was darauf hindeutete, dass es kein harmloses Experiment war, sondern ein Muster, das zuvor im Wiki-Ökosystem gesehen wurde, nach Berichten, die ähnliche Skripte in anderen Vorfällen verfolgt haben.

Was Benutzer jetzt tun können: Wenn Sie kürzlich Wikimedia Wikis bearbeitet haben und das Skript hochgeladen werden, überprüfen Sie Ihre Benutzerseite (insbesondereBenutzer: Ihr Name / common.js), entfernt jeden verdächtigen Code und stellt offizielle Skripte von vertrauenswürdigen Kopien. Berücksichtigen Sie, Passwörter zu ändern und zwei Faktoren Authentifizierung zu ermöglichen, wenn verfügbar. Die technische Dokumentation von MediaWiki über User JavaScript ist ein guter Ausgangspunkt, um zu verstehen, welche Dateien auf Ihrem Browser ausgeführt werden können: Handbuch: JavaScript (MediaWiki).

Für die Community- und Software-Betreuer sollte die Folge eine tiefe Reflexion über die Notwendigkeit zusätzlicher Steuerungen auf den Seiten fördern, die Code auf den Browsern der Editoren ausführen: obligatorische Überprüfung von Änderungen in globalen Skripten, bessere Telemetrie, um ungewöhnliche Belastungen zu erkennen, und strengere Prozesse, um Skripte in isolierten Umgebungen auszuführen und zu testen, bevor sie live aktivieren.

Transparenz und herausragende Lehren: Die unmittelbare technische Antwort beendete die Verbreitung, aber das Fehlen eines vollständigen technischen Berichts macht es schwierig, zu wissen, ob es unberechtigten Zugang zu Personalkonten gab, ob es keine Verbesserung der internen Berechtigungen und Testprozesse gibt, oder ob es Schwachstellen in der Bearbeitung von Werkzeugen gibt, die behoben werden müssen. Die Gemeinschaft verdient eine öffentliche und dokumentierte Untersuchung, die die Ursachen und die vorgeschlagenen Korrekturmaßnahmen erläutert. In der Zwischenzeit Werkzeuge von Dritten und spezialisierten Medien wie BlepingComputer haben vorläufige Analysen veröffentlicht, die dazu beitragen, den Angriff zu kontextualisieren, und der Vorfall in Phabicator dient als primäre Quelle für die Nachverfolgung von Technikern und Freiwilligen.

Dieser Vorfall erinnert daran, dass in groß angelegten offenen und kollaborativen Projekten die Sicherheit nicht nur die Verantwortung der Manager, sondern ein kollektiver Aufwand ist: klare Protokolle für interne Tests, Code-Audits, Antwortverfahren und transparente Kommunikation sind wesentliche Bestandteile. Die Gemeinschaft, die Entwickler und die Stiftung müssen zusammenarbeiten, um Lücken zu schließen und Vertrauen wiederherzustellen.

Wenn Sie als Redakteur in einem Wikimedia-Wiki teilnehmen und seltsame Verhaltensweisen erkennen - unerwartete Textanzeigen, auf Ihren Benutzerseiten versteckte Skripte, unbefugte Massenausgaben -, melden Sie es sofort auf Community-Technical Support-Kanäle (z.B. Dorfpumpe (technisch)) und folgt den von der Stiftung veröffentlichten offiziellen Leitlinien. Um der Untersuchung und den offiziellen Ankündigungen zu folgen, überprüfen Sie die Folgemaßnahmen bei Phabicator und die Statusseite von Wikimedia in Status.wikimedia.org.

Die Geschichte endet nicht mit der Beseitigung des Codes: der nachmittagige Bericht, die konkreten Maßnahmen der Stiftung und wie sich die Sicherheitspraktiken auf einer der am meisten besuchten Kooperationsplattformen auf dem Planeten entwickeln werden. Inzwischen ist die Lektion klar: Auf dem offenen Netz muss Vertrauen von technischen Kontrollen und Prozessen begleitet werden, die die Auswirkungen von Fehlern und schlechten Akteuren minimieren.