User:MZMcBride/Attacks

MediaWiki wikis are subject to a variety of attacks. This page documents some of them.

No account
It's typically possible to edit MediaWiki wikis without needing to be logged in to a user account. This can be both a blessing and a burden for attacks.

Typical account
A "typical" account is a little ambiguous. An account slowly gains privilege over time (and often with an associated edit count increase). An account that's a few days old (four or so) and has ten edits or more typically meets a wiki's threshold for "autoconfirmed" status.

Privileged account
Privileged accounts are typically administrator or bureaucrat accounts. Bureaucrats generally have the ability to create new administrators. Administrator accounts contain a lot of additional user rights, allowing for far greater damage to the wiki should an account be compromised (or intentionally go rogue). Most wikis operate on a flat hierarchy system. That is, there's no in-between administrator and a typical user account. It's not fine granularity.

Delete the Main Page
The English Wikipedia's Main Page has some special types of protection on it that make it more difficult, but not impossible to delete it. The first protection is that the page has no "delete" tab (it's hidden with CSS), so you'll have to manually create the URL (protip: [ click here]). The second protection is that there is a PHP hack in place involving MediaWiki:Mainpage. So you'll need to change that page first. Once MediaWiki:Mainpage is changed, you should be able to delete the Main Page. If something like 'bigdelete' stops you (that checks for pages over 5,000 revisions), try moving the page first and then deleting it. That usually works.

Exploit the MediaWiki namespace
One of the easier exploits involves a MediaWiki vulnerability. Namely that some MediaWiki messages still allow injection of raw HTML (bug 212). MediaWiki:Copyright is used on almost every page and (still) allows for raw HTML injection. It also has the advantage of not being cached (as heavily) as the site-wide JS and CSS pages. And it's not as well watched. There are likely other MediaWiki pages that can be exploited similarly, but they're probably not used as much as the copyright notice is.

Exploit user scripts / gadgets
Generally very popular gadgets and user scripts will not be watched nearly as much as the site-wide JS and CSS pages. You'll be hit by caching, but it may not matter depending how many people use the gadget, how often the browser purges local cache, and how long the change goes unnoticed. Also, if you're sufficiently proficient at JavaScript, you'll be able to obfuscate the code enough that even most people with the page watchlisted will be clueless. Protip: sometimes the pages don't even end in .js, so you may not even need an admin account to exploit this.

Merge page histories
This one is good because it causes a royal mess that very few people can clean up properly. Find two pages with less than 2500 revisions (A and B) and one page with thousands and thousands of revisions (C). Delete page A and move page B to A's old location. Delete page B and then move page C to B's (and A's) old location. Restore the edits and suddenly you've merged three page's history into one. And there's nothing easy to do to reverse it. You've also stopped anyone from deleting the page because the really large page will hit 'bigdelete.'

Exploit MediaWiki:Signature
Wait until a peak time of the day when lots of people are commenting. Make a nasty template with lots of garbage. If you can make one that outputs randomized content, even better (will be harder to track). Edit MediaWiki:Signature and add the code " ". Save the page and wait for dozens of people to sign their name and insert lots of lots and garbage into the page. It won't be fun to clean up, especially on talk pages. If the content in the template is large enough and nasty enough, you'll wind up locking browsers when users try to edit the page to fix it.

Exploit MediaWiki:Titleblacklist
This is good if you want to cause small-scale minor disruption. Add ".* " to the blacklist to prevent all pages from being editable by anyone other than admins. This will likely be caught quickly enough (especially because of the descriptive default error messages), but it will certainly annoy people. Protip: you can customize the error message using "".

Cause a database lock
This used to be easier, but with the addition of the 'bigdelete' right, it's more difficult nowadays. Because the revision counter is such a hack, there are comments that say that moving a page and then immediately trying to delete it will work. The goal here is to overload the system by deleting a page with a lot of revisions. If the page history is large enough and you are able to get MediaWiki to delete it, you can cause a database lock of up to an hour if no sysadmin is around to fix the problem.

Similarly, if you're a capable script writer, you can write a script that deletes pages with about 5,000 revisions each. Protip: use the API. If you do this quickly enough, you'll cause a database lock.

Block active admins
This generally doesn't work as well on a large project like the English Wikipedia, but using a script, you can block active admins while concurrently causing mayhem (deleting lots of pages, inserting malicious JS, etc.). The trick here is to study activity levels. You need to triage. Don't block admins who haven't edited in six months first. And don't block admins who never edit during the time of your attack. Block admins who legitimately pose a threat to your plans. (Protip: If using the API, list=recentchanges&rctype=log can help to find currently active admins) And, write an unblock mechanism into your code (as self-unblocks are still possible).

Increase server load

 * User renames
 * Special:Contributions with a particular namespace specified (unoptimized database queries)
 * Editing templates that are used a lot (particularly templates that change parsing behavior such as "Template:!")

CentralNotice
Load JavaScript onto the computer of every visitor to a wiki. The pages are not well watched. This is incredibly easy to abuse with an administrator account.

Gadgets
Gadgets can now be enabled by default. This is another very easy injection vector for users, as gadgets are not very closely monitored. Gadgets currently only work for users with a registered account (an account with user preferences).

Abusefilter
Filters can be used to automatically block edits, actions, or users, and not very many other people tend to know how to use the extension, so reverting changes to an existing filter may not be very easy for other folks. Reverting all actions by a well-used filter can apparently also cause server strain and database weirdness or something.