Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

wikimediastatus.net

Post reply on HN
Print view View original

91–100 of 405 posts

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

#91

Post by kbolino »

streetfighter64 wrote: post #69
kbolino wrote: post #54

Earlier quoted context omitted.

Where and how they spent their money is on p. 21 of this PDF [1] which can be obtained from this official source [2]. This is just a high-level breakdown, but it does illustrate that, for example, more than twice as much is spent on "Donation processing expenses" ($7.5M) as "Internet hosting" ($3.1M), and that the largest line item, by far, is "Salaries and benefits" ($106M). [1]: https://wikimediafoundation.org/wp-c…

Well obviously salaries will be the highest expense in any organization like this. The more interesting question is if it's salaries to security programmers or teachers at an african womens' coding bootcamp (yes they did spend money on that, and yes it's probably useful, but hardly what people think of when they see those "donate now to keep wikipedia alive" banners). A big percentage probably goes to their CEO who d…

There are a couple of ways to approach this information. One is to compare to the past. For example, comparing with 2008-2009 [1], they now spend 3.75 times as much on hosting, but 48 times as much on salaries, illustrating a more-than-tenfold relative growth in salaries compared to hosting. While hosting is not now nor ever was their only relevant expense, it is a good anchor point.

Another key difference over the last 15 years has been the introduction of awards and grants, which didn't exist then but now comprise $26.8M (15%) of their expenditures. This is where most of the ideological/controversial spending actually goes, rather than the salaries per se, but even more to the point, this one line item is more than 3 times their entire inflation-adjusted budget from 15 years ago ($5.6M times 150% CPI = $8.4M) and is still more than if we adjusted their entire budget using the hosting cost as an index ($5.6M times 3.75 = $21M).

[1]: https://upload.wikimedia.org/wikipedia/commons/a/a4/WMF_Annu...

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

#92

Post by bbor »

i_think_so wrote: post #85

> 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 i…

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.

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

#93

Post by shevy-java »

bbor wrote: post #87
pixl97 wrote: post #82

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

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!

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

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

#94

Post by shevy-java »

dns_snek wrote: post #83
j45 wrote: post #58

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.

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.

How does 2FA prevent this here?

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

#95

Post by nubinetwork »

nzeid wrote: post #15
greyface- wrote: post #2

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

Wikipediocracy link gives "not authorized".

works for me

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

#96

Post by mannykannot »

ChrisMarshallNY wrote: post #31
m4tthumphrey wrote: post #16

Earlier quoted context omitted.

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.

I use it on the backends of my stuff. Works great, but, like any tool, usage matters. People who use tools badly, get bad results. I've always found the "Fishtank Graph" to be relevant: https://w3techs.com/technologies/history_overview/programmin...

People who use tools badly inflict bad results on other people, quite often far more so than they do so on themselves.

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

#97

Post by LaGrange »

streetfighter64 wrote: post #75
bawolff wrote: post #57

Earlier quoted context omitted.

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]

Well, admins (or anybody other than the developers / deployment pipeline) having permissions to alter the JS sounds like a significant vulnerability. Maybe it wasn't in the early 2000s, but unencrypted HTTP was also normal then.

> Well, admins (or anybody other than the developers / deployment pipeline) having permissions to alter the JS sounds like a significant vulnerability.

It's a common feature of CMS'es and "tag management systems." Its presence is a massive PITA to developers even _besides_ the security, but PMs _love them_, in my experience.

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

#98

Post by Kiboneu »

bbor wrote: post #87
pixl97 wrote: post #82

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

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!

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.

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

#99

Post by derefr »

shevy-java wrote: post #93
bbor wrote: post #87

Earlier quoted context omitted.

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!

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

In fact, as long as the malware is just doing deletes, you can just merge the two "timelines" by restoring the snapshot and then replaying all the edits but ignoring the deletes. Lost deletes really aren't much of a problem!

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

#100

Post by Sohcahtoa82 »

radium3d wrote: post #46
jjice wrote: post #17

Earlier quoted context omitted.

PHP is a fine language. It started my career. That said, it has a lot of baggage that can let you shoot yourself in the foot. Modern PHP is pretty awesome though.

Pretty sure we've seen people coding in essentially every other programming language also shoot themselves in the foot.

Every language has foot-guns of some sort. The difference is how easy it is to accidentally pull the trigger.

PHP makes it easy.

Post reply on HN