User talk:MZMcBride/Attacks

Deletion

I may request a deletion of this page because it does nothing but teach people how to do harm to Wikipedia.

Themaeeandhisfriend 19:41, 28 February 2009 (UTC)

Which is another way of saying, "Ignorance is strength!" Leucosticte (talk) 19:29, 19 July 2014 (UTC)

Same here. NonvocalScream 16:37, 5 April 2009 (UTC)

It would be nice if you didn't deliberately drama-whore like this, MZMcBride. —Simetrical (talk • contribs) 16:39, 5 April 2009 (UTC)

Restored page

I just restored this page (and its talk page, obviously). I don't really remember the specifics of it being deleted (my deletion summary was "user request"). I don't believe I'm breaking any promises to anyone by restoring the page, but if I am, please let me know and I'll try to make it right.

Why the restore? I think the page is a good starting point on a broader page about how to attack a MediaWiki wiki. Most of the current content is going to be sub-sectioned into an "With an admin account" section. Plenty of damage is possible without an admin account. --MZMcBride (talk) 19:59, 18 March 2012 (UTC)

Page organization

I'm not sure if the page should be organized by account type or if it should be a flatter list with a better table of contents/index (and maybe an infobox per section?). Dunno. Hmmm. --MZMcBride (talk) 21:02, 18 March 2012 (UTC)

Interesting

Most of these attacks are meh. (Sure mediawiki:Signature messing could make a mess, and is certainly cleaver. But why both with that if you can mess with mediawiki:Common.js. Privileged users can do damage, hence the reason we only give those rights to privileged folks), but some are interesting:

• Protip: sometimes the pages don't even end in .js, so you may not even need an admin account to exploit this. that's really scary to think about.

Users went through the English Wikipedia at some point and protected (moved, really) a lot of the unprotected pages. It's more difficult on a wiki like that. Some of the smaller wikis are probably still importing JavaScript from unprotected pages, but it's likely uncommon simply due to conventions and import history. That is, people will typically use the same (safe) titles when they move scripts from other, larger sites. --MZMcBride (talk) 01:24, 19 March 2012 (UTC)

• Merge page histories - That's quite creative. But if you have admin you can do things much worst that are much harder to cleanup.

Such as? --MZMcBride (talk) 01:24, 19 March 2012 (UTC)

• there are comments that say that moving a page and then immediately trying to delete it will work Really? I don't understand how that could be (unless you hit a race condition of some sort, but i doubt people are that fast). When you move a page, the revisions do not get moved. Only the page title in the db gets changed (2 fields). Guess this is something I should try out on my own wiki to double check.

This may be a rumor. Basically the idea here was that (for whatever reason), when you move a page, it screws up the revision counter that has to run very quickly when the deletion form is loaded. If that count can be manipulated a bit, you can bypass the restriction. Not sure if it actually works. --MZMcBride (talk) 01:24, 19 March 2012 (UTC)

• Increase server load - meh increasing the job queue load won't affect users that much (at least in wikipedia's set up). For the special:contribs point, I can think of things so much worst then that, but I won't mention.

Job queue is bad enough, but editing a template such as w:en:Template:! would quickly start to break the thousands of other templates that rely on it for table syntax, image syntax, etc. If the attack is nasty enough and it's a busy time on the wiki, nearly any page save or re-parse will get super-fucked from a change to that one template. If you can combine substitution magic, it's even worse. --MZMcBride (talk) 01:24, 19 March 2012 (UTC)

Bawolff (talk) 23:50, 18 March 2012 (UTC)

I'm actually kind of more interested in what you can do with subtle vandalism on smaller wikis in an automated fashion. Obvious vandalism ("penis penis penis") is the "best" kind on a small wiki where few people speak the language. But if your vandalism is moving page titles to versions with different accents or moving a few characters around (small page text corruption) on a large scale (over a sustained period of time across dozens of wikis), your attack would be much better. It's my theory that you could go undetected for weeks. The people monitoring a lot of these wikis are doing so in an online role-playing game kind of way. They're able to easily spot and revert the obvious vandalism, but what about edits that are wrong that require a native speaker to recognize? As far as I know, on a lot of wikis, there's very little monitoring of this. And even if people notice quickly, spreading out the bad edits across time and across accounts makes it much uglier.

It may make sense to re-work the page in a smarter way. Basically if you achieve nearly any kind of JavaScript injection on a privileged account, it's game-over. But that's just one very easy vector with infinite sub-possibilities (the JavaScript can do nearly anything). The more creative attacks (such as overloading the server with unoptimized database queries) are where it gets actually interesting from a technical perspective, in my opinion. Or privilege escalation (injecting JavaScript as a typical or even anonymous user) if the pages aren't properly protected. Or doing some kind of exploit on a giant scale (CentralNotice campaign that couples an invisible banner with malicious JavaScript that affects every visitor, anonymous or not).

The page was restored to make it much less admin-specific. And some of the content is probably just wrong or outdated. Plenty of room for improvement; feel free to jump in. :-) --MZMcBride (talk) 01:17, 19 March 2012 (UTC)

'Block active admins' section

Using list=recentchanges&rctype=log seems to give a list of what pages had log actions performed on them, but not any information about what action it was or who performed it. It also includes logs that aren't specific to admins. Unless there are additional parameters that could specify these things, I don't see how this API query could be of much use in locating active admins to block. If I were trying to find active admins, I'd just have a look at one of the admin-specific logs (blocking, deletion and protection are probably the most frequently used) but that's just me; maybe you know a better way. Cathfolant (talk) 21:50, 1 June 2014 (UTC)

Merging histories

With regard to User:MZMcBride/Attacks#Merge_page_histories, I'm told that OffWiki gave all regular users deletion/undeletion rights, and someone did exactly what you described. I was thinking of ways that this could be reversed:

1. Refer to the last daily backup to see which revisions belong with which pages.
2. Look at the content and figure out which revisions are similar to which other revisions; e.g. two revisions with 99% the same content probably belong to the same page.
3. Look at revision.rev_user; if you know that user X edited page A but not page B, then you know that all user X revisions belong with page A.
4. Look at revision.rev_timestamp; if page A was created in 2013 and page B was created in 2014, then any revisions prior to 2014 belong with page A.

Some automated tools could probably be created to do this stuff. A really sneaky person could try to foil remedy #2 above by making revisions to page A that are a copy-and-paste of page B. However, that could be defeated by filtering out any revisions by said vandal before doing the comparisons. Besides tightening up user rights, another preventive measure for these situations would be to add a serialized rev_former_pages field that would include all the page IDs that the revision has ever existed under, in chronological order. Leucosticte (talk) 16:46, 19 July 2014 (UTC)