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

81–90 of 405 posts

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

#81

Post by stephbook »

varun_ch wrote: post #8
varun_ch wrote: post #4

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.

Also, I’m also surprised an XSS attack like hasn’t yet been actually used to harvest credentials like passwords through browser autofill[0]. 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/

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

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

#83

Post by dns_snek »

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.

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

#84

Post by varun_ch »

stephbook wrote: post #81
varun_ch wrote: post #8

Earlier quoted context omitted.

Also, I’m also surprised an XSS attack like hasn’t yet been actually used to harvest credentials like passwords through browser autofill[0]. 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/

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

but any interaction is good for Chrome, like dismissing a cookie banner

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

#85

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

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

#87

Post by bbor »

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!

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

#88

Post by jkaplowitz »

vova_hn2 wrote: post #80
nhubbard wrote: post #50

Earlier quoted context omitted.

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

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

Yeah, but the purpose of an encyclopedia like Wikipedia (a tertiary source) is to relatively neutrally summarize the consensus of those who spend the time and effort to analyze and interpret the primary sources (and thus produce secondary sources), or if necessary to cite other tertiary summaries of those.

In a discussion forum like HN, pointing to primary sources is the most reliable input to the other readers' research on/synthesis of their own secondary interpretation of what may be going on. Pointing to other secondary interpretations/analyses is also useful, but not without including the primary source so that others can - with apologies to the phrase currently misused by the US right wing - truly do their own research.

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

#89

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

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

#90

Post by shevy-java »

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

Post reply on HN