<- Back
Comments (211)
- tux3See the public phab ticket: https://phabricator.wikimedia.org/T419143In short, a Wikimedia Foundation account was doing some sort of test which involved loading a large number of user scripts. They decided to just start loading random user scripts, instead of creating some just for this test.The user who ran this test is a Staff Security Engineer at WMF, and naturally they decided to do this test under their highly-privileged Wikimedia Foundation staff account, which has permissions to edit the global CSS and JS that runs on every page.One of those random scripts was a 2 year old malicious script from ruwiki. This script injects itself in the global Javascript on every page, and then in the userscripts of any user that runs into it, so it started spreading and doing damage really fast. This triggered tons of alerts, until the decision was made to turn the Wiki read-only.
- nhubbardWow. 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 articlesEDIT! 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.
- Kiboneu> Cleaning this up is going to be an absolute forensic nightmare for the Wikimedia team since the database history itself is the active distribution vector.Well, worm didn't get root -- so if wikimedia snapshots or made a recent backup, probably not so much of a nightmare? Then the diffs can tell a fairly detailed forensic story, including indicators of motive.Snapshotting is a very low-overhead operation, so you can make them very frequently and then expire them after some time.
- wikiperson26A 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."
- varun_chWoah 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.
- infinitewarsA comment from my wiki-editor friend: "The incident appears to have been a cross-site scripting hack. The origin of rhe malicious scripts was a userpage on the Russian Wikipedia. The script contained Russian language text. During the shutdown, users monitoring [https://meta.wikimedia.org/wiki/special:RecentChanges Recent changes page on Meta] could view WMF operators manually reverting what appeared to be a worm propagated in common.js Hopefully this means they won't have to do a database rollback, i.e. no lost edits. " Interesting to note how trivial it is today to fake something as coming "from the Russians".
- greyface-
- WikipedianonThis 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.
- lifeisstillgoodI 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.
- pixl97>Cleaning this upFind the first instance and reset to the backup before then. An hour, a day, a week? Doesn't matter that much in this case.
- tantalorNice to see jQuery still getting used :)
- DweditI just checked a wiki, and the "MediaWiki:Common.js" page there was read-only, even for wikisysop users.
- shevy-javaThis is unfortunate that Wikipedia is under attack. It seems as if there are more malicious actors now than, say, 5 years ago.This may be unrelated but I also noticed more attacks on e. g. libgen, Anna's archive and what not. I am not at all saying this is similar to Wikipedia as such, mind you, but it really seems as if there are more actors active now who target people's freedom now (e. g. freedom of choice of access to any kind of information; age restriction aka age "verification" taps into this too).
- mafrieseI’m not saying that this is related to Wikipedia ditching archive.is but timing in combination with Russian messages is at least…weird.
- dlcarrierI've never understood why client-side execution is so heavy in modern web pages. Theoretically, the costs to execute it are marginal, but in practice, if I'm browsing a web page from a battery-powered device, all that compute power draining the battery not only affects how long I can use the device between charges, but is also adding wear to the battery, so I'll have to replace it sooner. Also, a lot of web pages are downright slow, because my phone can only perform 10s of billions of operations per second, which isn't enough to responsively arrange text and images (which are composited by dedicated hardware acceleration) through all of the client-side bloat on many modern web pages. If there was that much bloat on the server side, the web server would run out of resources with even moderate usage.There's also a lot of client-side authentication, even with financial transactions, e.g. with iOS and Android locally verifying a users password, or worse yet a PIN or biographic information, then sending approval to the server. Granted, authentication of any kind is optional for credit card transactions in the US, so all the rest is security theater, but if it did matter, it would be the worst way to do it.
- clcaevWe should be using federated organizational architectures when appropriate.For Wikipedia, consider a central read-only aggregated mirror that delegates the editorial function to specialized communities. Common, suggested tooling (software and processes) could be maintained centrally but each community might be improved with more independence. This separation of concerns may be a better fit for knowledge collection and archival.Note: I edited to stress central mirroring of static content with delegation of editorial function to contributing organizations. I'm expressly not endorsing technical "dynamic" federation approaches.
- devmorIn 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.
- sciencejerkI wonder if any poisoned data made it into LLM training data pipelines?
- krater23Just thought about.Who wins the most from a Wikipedia outage and has questionable moral views? The same who currently struggles to find paying customers for his services.The large AI companies.
- garbagecreatorAnother 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.
- j45Too 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.
- KiboneuGOD 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?
- TZubiriThere's thousands of copies of the whole wikipedia in sql form though, IIRC it's just like 47GB.
- lynx97Time to spend some of this excess money on a bit of security tightening? I hear we're talking about a 9 digit figure.
- 0xWTFLooking forward to the postmortem...
- 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.
- nixassI can edit it
- j45It's reassuring to know Wikipedia has these kinds of security mechanisms in place.
- tantalor"Закрываем проект" is Russian for "Closing the project"
- epicprogrammer[flagged]
- 256_Here before someone says that it's because MediaWiki is written in PHP.
- meetpaleltech[dead]
- pKropotkin[flagged]
- noobahoi[flagged]
- yabones[flagged]
- MagicMoonlightThey have no incentive to improve the site, because they’re a for-profit entity.Despite the constant screeching for donations, the entire site is owned by a company with shareholders. All the “donations” go to them. They already met their funding needs for the next century a long time ago, this is all profit.
- UhhrrrHow do they know? Has this been published in a Reliable Source?
- skrtskrtLong past time to eliminate JavaScript from existence