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

It seems like the worm code/the replicated code only really attacks stuff on site. But leaking credentials (and obviously people reuse passwords across sites) could be sooo much worse.

[0] https://varun.ch/posts/autofill/

af78• 5 months ago

Time to add 2FA...

stephbook• 5 months ago

Chrome doesnt actually autofill before you interact. It only displays what it would fill in at the same location visually.

tantalor2• 5 months ago

Nice to see jQuery still getting used :)

256_4• 5 months ago

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

Dwedit2• 5 months ago

PHP is the language where "return flase" causes it to return true.

https://danielc7.medium.com/remote-code-execution-gaining-do...

m4tthumphrey2• 5 months ago

Also the language that runs half of the web.

Also the language that has made me millions over my career with no degree.

Also the language that allows people to be up and running in seconds (with or without AI).

I could go on.

420official• 5 months ago

FWIW this was fixed in 2020

ale42• 5 months ago

Except that in a contemporary PHP that doesn't work any more.

  PHP Warning:  Uncaught Error: Undefined constant "flase" in php shell code:1

This means game over, the script stops there.

nhubbard3• 5 months ago

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.

256_4• 5 months ago

As someone on the Wikipediocracy forums pointed out, basemetrika.ru does not exist. I get an NXDomain response trying to resolve it. The plot thickens.

pKropotkin• 5 months ago

Yeah, basemetrika.ru is free now. Should we occupy it? ;)

dheera2• 5 months ago

Wouldn't be surprised if elaborate worms like this are AI-designed

nhubbard3• 5 months ago

I wouldn't be surprised either. But the original formatting of the worm makes me think it was human written, or maybe AI assisted, but not 100% AI. It has a lot of unusual stylistic choices that I don't believe an AI would intentionally output.

integralid• 5 months ago

I would. AI designed software in general does not include novel ideas. And this is the kind of novel software AI is not great at, because there's not much training data.

Of course it's very possible someone wrote it with AI help. But almost no chance it was designed by AI.

idiotsecant• 5 months ago

I mean....elaborate is a stretch.

streetfighter647• 5 months ago

Turns out it's a pretty rudimentary XSS worm from 2023. If all you have is a hammer, everything looks like a nail; if all you have is a LLM, everything looks like slop?

bawolff12• 5 months ago

Vandalizes 20 random articles with a 5000px wide image and another XSS script from basemetrika.ru

Note while this looks like its trying to trigger an xss, what its doing is ineffective, so basemetrika.ru would never get loaded (even ignoring that the domain doesnt exist)

divbzero• 5 months ago

There doesn’t seem to be an ulterior motive beyond “Muahaha, see the trouble I can cause!”

batiudrami• 5 months ago

A classical virus, from the good old days. None of this botnet/bitcoin mining in the background nonsense.

creatonez2• 5 months ago

No one actually knows what the payload from basemetrika.ru contains, though. So it's possible it was originally intended to be more damaging. But no matter what it would have caught attention super fast, so there's probably an upper limit to how sophisticated it could have been.

Uhhrrr2• 5 months ago

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

nhubbard3• 5 months ago

This is the official Wikimedia Foundation status page for the whole of Wikipedia, so it's a reliable primary source.

vova_hn2• 5 months ago

Actually, usage of primary sources is kinda complicated [0], generally Wikipedia prefers secondary and tertiary sources.

[0] https://en.wikipedia.org/wiki/Wikipedia:No_original_research...

devmor• 5 months ago

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.

0xWTF2• 5 months ago

Ok, so there are tons of mediawiki installations all over the internet. What do these operators do? Set their wikis to read-only mode, hang tight, and wait for a security patch?

Also, does this worm have a name?

bawolff12• 5 months ago

There is nothing to do, the incident was not caused by a vulnerability in mediawiki.

Basically someone who had permissions to alter site js, accidentally added malicious js. The main solution is to be very careful about giving user accounts permission to edit js.

[There are of course other hardening things that maybe should be done based on lessons learned]

0xWTF2• 5 months ago

Looking forward to the postmortem...

Wikipedianon4• 5 months ago

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.

256_4• 5 months ago

Maybe somewhat unrelated, but I'm reminded of the fact that people have deleted the main page on a few occasions: https://en.wikipedia.org/wiki/Wikipedia:Don%27t_delete_the_m...

RGamma• 5 months ago

Seems like a good time to donate one's resources to fix it. The internet is super hostile these days. If Wikipedia falls... well...

PsylentKnight• 5 months ago

My understanding is that Wikipedia receives more donations than they need, surely they have the resources to fix it themselves?

logophobia• 5 months ago

Sounds more like a political issue this. Can't buy your way out of that.

Wikipedianon4• 5 months ago

It's a political issue. Editors are unwilling or unable to contribute to development of the features they need to edit.

Unfortunately, Wikipedia is run on insecure user scripts created by volunteers that tend to be under the age of 18.

There might be more editors trying to resume boost if editing Wikipedia under your real name didn't invite endless harassment.

tick_tock_tick• 5 months ago

Wikipedia doesn't even spend donation of Wikipedia anymore.

diath• 5 months ago

They have 100s of millions USD, they will be fine: https://upload.wikimedia.org/wikipedia/foundation/3/3f/Wikim... (page 5-7).

_verandaguy• 5 months ago

    > Based on the fact user scripts are globally disabled now I'm guessing this was a vector.

Disabled at which level?

Browsers still allow for user scripts via tools like TamperMonkey and GreaseMonkey, and that's not enforceable (and arguably, not even trivially visible) to sites, including Wikipedia.

As I say that out loud, I figure there's a separate ecosystem of Wikipedia-specific user scripts, but arguably the same problem exists.

howenterprisey• 5 months ago

Yeah, wikipedia has its own user script system, and that was what was disabled.

karel-3d4• 5 months ago

This is apparently not done browser side but server side.

As in, user can upload whatever they wish and it will be shown to them and ran, as JS, fully privileged and all.

Wikipedianon4• 5 months ago

The sitewide JavaScript/CSS is an editable Wiki page.

You can also upload scripts to be shared and executed by other users.

gucci-on-fleek2• 5 months ago

Any user with "interface administrator" status can change global JavaScript or CSS for all users on a given Wiki with no review.

True, but there aren't very many interface administrators. It looks like there are only 137 right now [0], which I agree is probably more than there should be, but that's still a relatively small number compared to the total number of active users. But there are lots of bots/duplicates in that list too, so the real number is likely quite a bit smaller. Plus, most of the users in that list are employed by Wikimedia, which presumably means that they're fairly well vetted.

[0] https://en.wikipedia.org/w/api.php?action=query&format=json&...

notRobot• 5 months ago

There are 15 interface admins as per these links

https://en.wikipedia.org/wiki/Wikipedia:Interface_administra...

https://en.wikipedia.org/wiki/Special:ListUsers/interface-ad...

Wikipedianon4• 5 months ago

There shouldn't be any interface admins as such. There should be an enforced review process for changes to global JavaScript so stuff like this can't happen.

I'm sure there are Google engineers who can push changes to prod and bypass CI but that isn't a normal way to handle infra.

AlienRobot2• 5 months ago

For reference

There are currently 15 interface administrators (including two bots).

https://en.wikipedia.org/wiki/Wikipedia:Interface_administra...

Nemo_bis• 5 months ago

Reminds me of the famous quip starting with "found a bug in the english site" (early 2000s)...

https://bash.toolforge.org/quip/AU8FCPz66snAnmqnLHDj

bawolff12• 5 months 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).

You're mixing up events. Superprotect is unrelated to the IAdmin separation from normal admin. The two are separated by many years and basically totally unrelated.

I agree with the rest of your post.

skrtskrt2• 5 months ago

Long past time to eliminate JavaScript from existence

dgxyz6• 5 months ago

This.

Actually fuck the whole dynamic web. Just give us hypertext again and build native apps.

Edit: perhaps I shouldn't say this on an VC driven SaaS wankfest forum...

rainingmonkey• 5 months ago

You may be interested in https://geminiprotocol.net/

dlivingston2• 5 months ago

I mean sure, but that's never going to happen, so complaining about it is just shaking your fist at the sky. The only way it will change is if the economics of the web change. Maybe that is the economics of developer time (it being easier/fast/more resilient and thus cheaper to do native dev), or maybe it is that dynamic scripting leads to such extreme vulnerabilities that ease of deployment/development/consumer usage change the macroeconomics of web deployment enough to shift the scales to local.

But if there's one thing I've learned over the years as a technologist, it's this: the "best technology" is not often the "technology that wins".

Engineering is not done in a vacuum. Indeed, my personal definition of engineering is that it is "constraint-based applied science". Yes, some of those constraints are "VC buxx" wanting to see a return on investment, but even the OSS world has its own set of constraints - often overlapping. Time, labor, existing infrastructure, domain knowledge.

streetfighter647• 5 months ago

Imagine if wikipedia was a native app, what this vuln would have caused. I for one prefer using stuff in the browser where at least it's sandboxed. Also, there's nothing stopping you from disabling JS in your browser.

Ekaros2• 5 months ago

Doing some security work now. And it seems half of my problems are because some other site get to run any random code so they might call my site. And I have to protect against that. I am somewhat annoyed. Why is this design acceptable in first place?

krisoft• 5 months ago

You will have a long trek to do that. We have a javascript interpreter deployed at the second Sun-Earth Lagrange point.

https://www.theverge.com/2022/8/18/23206110/james-webb-space...

dgxyz6• 5 months ago

I live happily in the knowledge that in 20000 years when that eventually drifts off into another system and is picked up by aliens that they will reverse engineer it and wonder why the fuck '5'-'4'=1

msla3• 5 months ago

Yep, WASM is so much more secure.

nixass• 5 months ago

I can edit it

j455• 5 months ago

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

j455• 5 months ago

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.

dns_snek4• 5 months ago

The amount of javascript is really beside the point here. The problem is that privileged users can easily edit the code without strong 2FA, allowing automatic propagation.

shevy-java3• 5 months ago

How does 2FA prevent this here?

j455• 5 months ago

It's not, application logic exposed on the client side is always an attack vector for figuring out how it works and how attack vectors could be devised.

It's simply a calculated risk.

How much business and application logic you put in your Javascript is critical.

On your second unrelated comment about Wikipedia needing to use 2FA, there's probably a better way to do it and I hope mediawiki can do it.

lifeisstillgood• 5 months ago

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.

Aperocky• 5 months ago

All persistent data should have backup.

It's not a high bar.

lyu07282• 5 months ago

There are so many mirrors anyway and trivial to get a local copy? What is much more concerning is government censorship and age verification/digital id laws where what articles you read becomes part of your government record the police sees when they pull you over.

CaptainNegative• 5 months ago

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

Haven't we hit that point already with bad faith (and potentially government-run) coordinated editing and voting campaigns, as both Wales and Sanger have been pointing out for a while now?

See, for example,

* Sanger: https://en.wikipedia.org/wiki/User:Larry_Sanger/Nine_Theses

* Wales: https://en.wikipedia.org/wiki/Talk:Gaza_genocide/Archive_22#...

* PirateWires: https://www.piratewires.com/p/how-wikipedia-is-becoming-a-ma...

wizzwizz44• 5 months ago

Haven't we hit that point already with bad faith (and potentially government-run) coordinated editing […] campaigns,

Yes, this is a real phenomenon. See, for instance, https://en.wikipedia.org/wiki/Timeline_of_Wikipedia%E2%80%93...: the examples from 2006 are funny, and the article's subject matter just gets sadder and sadder as the chronology goes on.

and voting campaigns

I'm not sure what you mean by this. Wikipedia is not a democracy.

as both Wales and Sanger have been pointing out

{{fv}}. Neither of those essays make this point. The closest either gets is Sanger's first thesis, which misunderstands the "support / oppose" mechanism. Ironically, his ninth thesis says to introduce voting, which would create the "voting campaign" vulnerability!

These are both really bad takes, which I struggle to believe are made in good faith, and I'm glad Wikipedians are mostly ignoring them. (I have not read the third link you provided, because Substack.)

streetfighter647• 5 months ago

If you're using wikipedia to "agree on common facts" I think you might have bigger problems...

hnfong• 5 months ago

Not the GP, and I don't believe in the existence of "common facts" in general, but Wikipedia is indeed a good place to figure out what other people might agree as common facts...

GuB-42• 5 months ago

if Wikipedia vanished what would it mean …

That someone would need to restore some backups, and in the meantime, use mirrors.

Seriously, not that big of a deal. I don't know how many copies of Wikipedia are lying around but considering that archives are free to download, I guess a lot. And if you count text-only versions of the English Wikipedia without history and talk pages, it is literally everywhere as it is a common dataset for natural language processing tasks. It is likely to be the most resilient piece of data of that scale in existence today.

The only difficulty in the worst case scenario would be rebuilding a new central location and restarting the machinery with trusted admins, editors, etc... Any of the tech giants could probably make a Wikipedia replacement in days, with all data restored, but it won't be Wikipedia.

tempaccount5050• 5 months ago

What you're suggesting is literally impossible. There are plenty of mirrors and random people that download the thing in its entirety. The entire planet would have to be nuked for that to be possible.

__turbobrew__• 5 months ago

You can download the entirety of wikipedia and store it in your own offline immutable backup.

mrguyorama• 5 months ago

The dump of english wikipedia is 26gb compressed and completely usable with that compressed format plus a small index file.

That's small enough to live on most people's phones. It's small enough to be a single BluRay. Maybe Wikipedia should fund some mass printings.

What you do not get however is any media. No sounds, images, videos, drawings, examples, 3D artifacts, etc etc etc. This is a huge loss on many many many topics.

CSMastermind• 5 months ago

https://grokipedia.com/

xandrius• 5 months ago

Don't worry, I personally have an offline backup of the English on my phone.

garbagecreator• 5 months ago

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• 5 months ago

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."

orbital-decay• 5 months ago

I remember someone mass-defacing the ruwiki almost exactly a year ago (March 3 2025) with some immature insults towards certain ruwiki admins. If I'm not mistaken it was a similar method.

Lockal2• 5 months ago

No, I think you are mixing something.

- There are constant deface incidents caused by editing of unprotected / semiprotected templates

- There were incidents of UI mistranslation (because MediaWiki translation is crowdsourced)

- The attack that was applied is well know in Russian community, it is pretty much standard "admin-woodpecker". The standard woodpecker (some people call it neo-woodpecker) renamed all pages with a high speed (I know this since 2007, the name woodpecker appeared many years later); then MediaWiki added throttling for renames; then neo-woodpecker reappeared in different years (usually associated with throttling bypass CVEs). Early admin-woodpeckers were much more destructive (destroyed a dozens of mediawiki websites due to lack of backups). Nuking admin woodpecker it quite a boring one, but I think (I hope) there are some AbuseFilter guardrails configured to prevent complex woodpeckers.

- The attack initiator is 100% a well known user; there are not too many users who applied woodpecker in the first place; not too many "upyachka" fans (which indicates that user edited before 2010 - back then active editors knew each other much better). But it is quite pointless to discuss who exactly the initiator is.

- Wikireality page is hijacked by a small group and does not represent the reality.

pixl97• 5 months ago

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.

bbor2• 5 months ago

It is true that they have a particularly robust, distributed backup system that can/has come in handy, but FWIW the timing matters to them. English Wikipedia receives ~2 edits per second, or 172,800 per day. Many of them are surely minor and/or automated, but still: 1,036,800 lost edits is a lot!

shevy-java3• 5 months ago

Are they really lost though? I think they should not be lost; they could be stored in a separate database additionally.

Kiboneu12• 5 months ago

Filesystem & database snapshots are very cheap to make, you can make them every 15 minutes. You can expire old snapshots (or collapse the deltas between them) depending on the storage requirements.

i_think_so4• 5 months ago

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.

bbor2• 5 months ago

It warms my heart that there's basically a 0% chance that they ever approach this camp's viewpoint based on the Herculean effort it took to switch over to a slightly more modern frontend a few years back. I'm glad you don't think of yourself of a Luddite, but I think you're vastly overstating how open people are to a purely-static web.

Also, FWIW: Wikipedia is "specialsnowflake". If it isn't, that's merely because it was so specialsnowflake that there's now a healthy of ecosystem of sites that copied their features! It's far, far more capable than a simple blog, especially when you get into editing it.

i_think_so4• 5 months ago

Ok, fair point. I presumed that this crowd would be far more familiar with the capabilities of HTML5 and dynamic pages sans js than most. (Surely more familiar than I, who only dabble in code by comparison.)

No, I'm not suggesting we all go back to purely-static web pages, imagemap gifs and server side navigation. But you're going to have a hard time convincing me that I really truly need to execute code of unknown provenance in my this-app-does-everything-for-me process just to display a few pages of text and 5 jpegs.

And for the record, I've called myself a Technologist for almost 30 years now. If I were a closet Luddite I'd be one of the greatest hypocrites of human history. :-)

zelphirkalt2• 5 months ago

It would not have hurt to make a version of wikipedia, that will work without JS for the most part, including all that is important. However, that requires a mindset for supporting static pages, which is mostly what W should consist of, and would require a skill set, that is not so common among web developers these days. Such a static version would be much easier to test as well, since all the testing framework would need to do is simple requests, instead of awaiting client-side JS execution resulting in mutation of content on the page.

cesarb3• 5 months ago

and see if, maybe just maybe, they can get by without js.

Unless it changed recently (it's too slow right now for me to check), Wikipedia has always worked perfectly fine without JS; that includes even editing articles (using the classic editor which shows the article markup directly, instead of the newer "visual" editor).

Edit: I just checked, and indeed I can still open the classic edit page even with JS blocked.

Kiboneu12• 5 months ago

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?

Imustaskforhelp4• 5 months ago

edit: lol downvoted with no counterpoint, is it hitting a nerve?

I have upvoted ya fwiw and I don't understand it either why people would try to downvote ya.

I mean, if websites work for you while disabling js and you are fine with it. Then I mean JS is an threat vector somewhat.

Many of us are unable to live our lives without JS. I used to use librewolf and complete and total privacy started feeling a little too uncomfortable

Now I am on zen-browser fwiw which I do think has some improvements over stock firefox in terms of privacy but I can't say this for sure but I mainly use zen because it looks really good and I just love zen.

Kiboneu12• 5 months ago

I mean, if websites work for you while disabling js and you are fine with it. Then I mean JS is an threat vector somewhat

It's also been torture, I definitely don't prescribe it. :P Like you say, it's a sanity / utility / security tradeoff. I just happen to be willing to trade off sanity for utility and security.

And yes, unfortunately I have to enable JS for some sites -- the default is to leave it disabled. And of course with cloudflare I have to whitelist it specifically for their domains (well, the non analytics domains). But thankfully wikipedia is light and spiffy without the javascript.

pluralmonad• 5 months ago

What is uncomfortable about Librewolf? I thought it was basically FF without telemetry and UBO already baked in?

Kiboneu12• 5 months ago

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.

Extropy_• 5 months ago

Even if they reset to several days ago and lose, say, thousands of edits, even tens of thousands of minor edits, they're still in a pretty good place. Losing a few days of edits is less-than-ideal but very tolerable for Wikipedia as a whole

Kiboneu12• 5 months ago

Nah, you can snapshot every 15 minutes. The snapshot interval depends on the frequency of changes and their capacity, but it's up to them how to allocate these capacities... but it's definitely doable and there are real reasons for doing so. You can collapse deltas between snapshots after some time to make them last longer. I'd be surprised if they don't do that.

As an aside, snapshotting would have prevented a good deal of horror stories shared by people who give AI access to the FS. Well, as long as you don't give it root.......

tetha• 5 months ago

At $work we're hosting business knowledge databases. Interestingly enough, if you need to revert a day or two of edits, you're better off to do it asap, over postponing and mulling over it. Especially if you can keep a dump or an export around.

People usually remember what they changed yesterday and have uploaded files and such still around. It's not great, but quite possible. Maybe you need to pull a few content articles out from the broken state if they ask. No huge deal.

If you decide to roll back after a week or so, editors get really annoyed, because now they are usually forced to backtrack and reconcile the state of the knowledge base, maybe you need a current and a rolled-back system, it may have regulatory implications and it's a huge pain in the neck.

bawolff12• 5 months ago

Nothing was rolled back in the db sense, i think people just used normal wiki revert tools.

It also never effected wikipedia, just the smaller meta site (used for interproject coordination)

hinkley4• 5 months ago

I wonder if the bad traffic overwhelmed the good traffic enough that it's simpler to pick out some of the good traffic from the bad and replay it rather than spot all of the bad traffic.

shevy-java3• 5 months ago

This 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).

jibal3• 5 months ago

Wikipedia is not under attack. Some stupid admin running with full privileges unsandboxed ran a test that grabbed and ran random user scripts, and one of them just happened to be this 2 year old malicious script.

tonymet5• 5 months ago

that's a common attack vector -- like leaving malware usb sticks on the ground, knowing an admin will pick it up and insert it.

Phabricator reveals the ops tasks that WMF admins perform, so attackers can drop malware in common locations and bet on them getting run from time to time.

clcaev• 5 months ago

We 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.

brcmthrowaway• 5 months ago

Exactly. Wikipedia should be used on ipfs

dlcarrier• 5 months ago

I'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.

MagicMoonlight• 5 months ago

They 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.

charonn0• 5 months ago

That's a serious accusation. Can you elaborate? What is the name of the company? Why does the Wikimedia Foundation claim ownership? And if you're referring to the Wikimedia Foundation, then what do you mean by "shareholders"?

circlefavshape• 5 months ago

This is total horseshit.

/me wonders if you're a bad actor or just delusional

mafriese• 5 months ago

I’m not saying that this is related to Wikipedia ditching archive.is but timing in combination with Russian messages is at least…weird.

worksonmine2• 5 months ago

And they probably used mind-control to make the admin run random userscripts on his privileged account as well, the capabilities of russian hackers is scary.

It is just another human acting human again.

tonymet5• 5 months ago

Admin tasks are public in phabricator so it would be trivial to review chores and place malware in the chore's scope

armchairhacker• 5 months ago

The script was uploaded in 2024, and triggered today because of an accident

https://en.wikipedia.org/wiki/Wikipedia:Village_stocks#Scott...

tux3• 5 months ago

See the public phab ticket: https://phabricator.wikimedia.org/T419143

In 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.

londons_explore• 5 months ago

Didn't realise this was some historic evil script and not some active attacker who could change tack at any moment.

That makes the fix pretty easy. Write a regex to detect the evil script, and revert every page to a historic version without the script.

jacquesm• 5 months ago

True but it does say something that such a script was able to lie dormant for so long.

jl6• 5 months ago

Letting ancient evil code run? Have we learned nothing from A Fire Upon the Deep?!

observationist• 5 months ago

Are you sure? Are you $150 million ARR sure? Are you $150 million ARR, you'd really like to keep your job, you're not going to accidentally leave a hole or blow up something else, sure?

I agree, mostly, but I'm also really glad I don't have to put out this fire. Cheering them on from the sidelines, though!

Melatonic• 5 months ago

Or just restore from backup across the board. Assuming they do their backups well this shouldn't be too hard (especially since its currently in Read Only mode which means no new updates)

karel-3d4• 5 months ago

wait as a wikipedia user you can just put random JS to some settings and it will just... run? privileged?

this is both really cool and really really insane

hk__22• 5 months ago

Yes, you can have your own JS/CSS that’s injected in every page. This is pretty useful for widgets, editing tools, or to customize the website’s apparence.

kemayo• 5 months ago

It's a mediawiki feature: there's a set of pages that get treated as JS/CSS and shown for either all users or specifically you. You do need to be an admin to edit the ones that get shown to all users.

https://www.mediawiki.org/wiki/Manual:Interface/JavaScript

Ekaros2• 5 months ago

Fundamentally I feel whole "web" as in anything running in browser is insane an broken security wise. When you allow mostly arbitrary code to run when you load a page... Well it can do mostly arbitrary things and everyone else needs to protect against it.

And when you have enough rights, you get to add arbitrary code to everywhere on your site.

Ferret7446• 5 months ago

This is a pretty egregious failure for a staff security engineer

mcmcmc• 5 months ago

Pretty much the definition of a “career limiting event”

ljm• 5 months ago

It's a pretty egregious failure for the org because it controlled the conditions for it to happen.

The security guy is just the patsy because he actioned it.

They have obviously done this a million times before and now they got burned.

type0• 5 months ago

With all their donation begging, nothing will change, they will still spend money on useless seminars and continue to underfund security by hiring low paid web amateurs to do the important work

greatgib• 5 months ago

As a staff, you don't even imagine what his salary is for screwing up like that.

That being said, interesting to see how salaries skyrocketed over the years: https://meta.wikimedia.org/wiki/Wikimedia_Foundation_salarie... but not that much for engineering.

AlienRobot2• 5 months ago

On one hand, I was about to get irrationally angry someone was attacking Wikipedia, so I'm a bit relieved

On the other hand,

a Staff Security Engineer at WMF, and naturally they decided to do this test under their highly-privileged Wikimedia Foundation staff account

seriously?

streetfighter647• 5 months ago

To paraphrase Bush,

our enemies are innovative and resourceful, and so are we. They never stop thinking about new ways to harm our site and our users, and neither do we.

davidd_1004• 5 months ago

300 million dollar organization btw

aiiane• 5 months ago

aka tiny, relatively speaking, compared to similar sites with the same user base

Fokamul• 5 months ago

I'm guessing, "1> Hey Claude, your script ran this malicious script!"

"Claude> Yes, you're absolutely right! I'm sorry!"

cesarb3• 5 months ago

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.

So, like the Samy worm? (https://en.wikipedia.org/wiki/Samy_%28computer_worm%29)

amai2• 5 months ago

Why am I not surprised that the malicious script was from ruwiki?

cc-d2• 5 months ago

this was us. we pumpin hard. we literall run, as in literally run the organisms of, senior wikimedia staff as well as employees

this is just us playing on the computer, we got b0mbz

chuckreynolds• 5 months ago

...wow.

mos87• 5 months ago

they decided to do this test under their

what language is this?

infinitewars• 5 months ago

A 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".

Lockal2• 5 months ago

Why do you think it was faked? It is a well known Russian tech (woodpecker), the earliest version I can find now was created in 2013 (but I personally saw it in 2007), it is a well known Russian damocles sword against misconfigured MediaWiki websites.

sciencejerk• 5 months ago

I wonder if any poisoned data made it into LLM training data pipelines?

ibejoeb• 5 months ago

Interesting angle. Everyone has already pointed out that there are backups basically everywhere, and from an information standpoint, shaving off a day (or whatever) of edits just to get to a known-good point is effectively zero cost. But I wonder what the cost is of the potentially bad data getting baked into those models, and if anyone really cares enough to scrap it.

TZubiri• 5 months ago

There's thousands of copies of the whole wikipedia in sql form though, IIRC it's just like 47GB.

eblume• 5 months ago

Correct. Not sure about a sql archive, but the kiwix ZIM archive of the top 1M English articles including (downsized but not minimized) images is 43GiB: https://download.kiwix.org/zim/wikipedia/

And the entire English wikipedia with no images is, interestingly, also 43GiB.

Dwedit2• 5 months ago

I just checked a wiki, and the "MediaWiki:Common.js" page there was read-only, even for wikisysop users.

bawolff12• 5 months ago

You need to be a special type of admin, called "interface-admin" to edit it. Normal admin is not enough.

lynx97• 5 months ago

Time to spend some of this excess money on a bit of security tightening? I hear we're talking about a 9 digit figure.

krater232• 5 months ago

Just 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.

tonymet5• 5 months ago

It's Wikipedia's 25th birthday but their security discipline is still very much circa 2001. No code signing, BOM / supply chain security. Only recently activated 2fa for admins (after another breach). Most admins are anons.

Let's hope they allocate more of the $200M+ / year to security infra.

tonymet5• 5 months ago

there's a very active tech discussion on the Wikipedia discord you can join here https://en.wikipedia.org/wiki/Wikipedia:Discord

ForOldHack• 5 months ago

Its been opened. Although I have issues with Wikipedia, being a creep is not a valid response.

bawolff12• 5 months ago

Fyi they released an official statement: https://meta.wikimedia.org/wiki/Wikimedia_Foundation/Product...

xannabxlle• 5 months ago

Unit 8200 at it again

javascripthater• 5 months ago

if only you people had listened

amai2• 5 months ago

Why am I not surprised that the malicious script was from ruwiki?

connor_peterson• 5 months ago

Because you're a fed.

cc-d2• 5 months ago

we pumpin

alansaber• 5 months ago

Not even social engineering, just a guy running public JS scripts. Very oldschool.

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

Related Stories