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.

Continuously revert a file

You can perform the revert of an uploaded file endlessly, by just hitting F5 on the page once you've done the revert of a file. Choose a big file and you can potentially make the server run out of disk space if you're persistent enough. See task T53383

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 the original. 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 most likely other MediaWiki pages that can be exploited similarly, but they're probably not used as much as the copyright notice is.

MediaWiki pages can also be used to make the entire wiki invisible. The easiest way of doing this is to add the line * { display: none; } to MediaWiki:Common.css, which tells everything not to be displayed. Another way is to exploit MediaWiki:Sitenotice, which appears on all pages; simply add something like this: <div style="position: fixed; top: 0px; left: 0px; width: 100%; height: 100%; background: #fff; z-index: 9999"></div>. If Extension:CSS or Extension:PageCSS is enabled, one can instead use {{#css: * { display: none; } }} (for CSS) or <css> * { display: none; } </css> (for PageCSS). These things may be particularly effective because it is impossible to edit the wiki until the offending code is removed, and removing the code requires another admin to adjust various settings on their browser (developer tools and/or turning off all CSS styles) to make the relevant wiki page visible in order to remove the code. Anyone attempting to resolve the attack will also have to have some idea of what has been done before they are able to begin fixing it, and that may not be immediately obvious. It is also more effective if multiple pages are affected, for obvious reasons. For example, the CSS files for all the skins as well as MediaWiki:Common.css. However, as this requires editing pages after the wiki has been made uneditable by malicious code, it requires the admin performing the attack to know how to either use the developer tools to manipulate the CSS on a page, or find the setting that turns off all CSS styles.

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 pages' 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 "{{<includeonly>subst:</includeonly>TemplateName}}". Save the page and wait for dozens of people to sign their name and insert lots and lots of 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 ".* <noedit>" 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 "<noedit|errmsg=PageTitle>".

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 for a user with many edits, filtered for a particular, rarely-used namespace (unoptimized database queries)
• Editing templates that are used a lot
• Add a huge amount of garbage to a page, and diff it with the previous version. Alternative if editing is not possible/feasible: Find 2 long pages, open a diff of one of them and change the diff or oldid parameters of the URL to match an oldid of the other page, to cause a huge diff output. Or just keep changing one of the parameters to compare one revision against any other random revision.

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 enabled by default will affect both logged in and anonymous users.

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.

AutoWikiBrowser

Admins and users whose names are on wikipedia:Project:AutoWikiBrowser/CheckPage are able to use AutoWikiBrowser to make automated or semi-automated edits. (For making entirely automated edits, the bot mode must be enabled.) This could be very useful for vandalising a large number of pages in a relatively small amount of time. Ordinary users can gain access to AWB on English Wikipedia by requesting it here; on other wikis no authorisation is usually required.