english - deutsch

How to handle a Wiki Security breach

For Wiki Users

In case the operator of a wiki you use pointed you to this page, saying you are affected (or a wiki you use is affected) by a security breach, you are strongly advised to follow these guidelines:

• Use strong passwords, don't reuse passwords.

• You must change the password(s) used in the affected wiki.

• You must change the password(s) on any other site, if you used the same or a similar password as on the affected wiki.

• You should consider all the data you had/have on the affected wiki copied/stolen, including but not limited to:
  • all data on wiki pages, including old revisions, including "deleted" pages
  • all file attachments
  • all data stored in your user profile, like:
    • the password hash (the wiki did not store your password(s) in plaintext, but as a so-called hash - but today there are means to crack even those hashes if your password is not very long and random, so better play safe.)
    • your E-Mail address, your wiki user name, your alias name, etc.
• Potentially, other data on same server might also be affected.
• In case of doubt or troubles, ask the wiki administrator / owner for help.

Note: The wiki administrator might do a global password reset for all users (either to enforce a password change, see above, or to just improve password hash strength, even if there was no security breach). In that case, you should just change your wiki password again.

For Wiki Admins / interested Users

In case your wiki is (potentially) affected by a security breach (like e.g. an attacker getting direct filesystem access or being able to execute code as the wiki process uid/gid), you are strongly advised to read and follow below guidelines.

Impact

If someone can directly access the filesystem, he could potentially read (or modify) any data or code readable (modifyable) by this uid/gid on the wiki server.

If the wiki uses the default MoinAuth authentication code, authentication happens using the username and the password (hash) stored in the user profile (which is stored in the data_dir, besides the page/attachment data).

How the password is usually hashed depends on the moin version:

• >=1.9.7 (2013) strong password hashes provided by passlib, by default sha512_crypt is used, auto-upgrades to that on login.

• >=1.9.4 (2012) additionally supports other (weaker) hashes, auto-upgrades to salted sha1 on login.

• >=1.8.0 (2008) uses salted sha1 pw hashes, auto-upgrades to salted sha1 on login.

• >=1.2.1 (2004) additionally offered script moin_usercheck.py (later became "moin account check") to remove all cleartext passwords

• >= 1.1 (2003) support username/password authentication, store sha1 pw hashes, kills cleartext passwords on login and profile load/save.

• >=0.7 (2000) optional passwords (not used, no authentication yet), stored in cleartext

Please note: Even salted SHA1 is not secure enough any more nowadays as you can use brute force (e.g. with powerful GPU hardware) to crack them - especially if the users used relatively short/weak passwords. So even if the users' passwords were stored as salted-SHA1, better consider them compromised. The stronger algorithms provided by passlib are slowing down brute force attacks a lot (like a million times slower).

Your TODO as wiki admin

Find out whether your wiki is vulnerable

If you run a MoinMoin wiki, find out whether it is still vulnerable.

Check your moin version (SystemInfo page, MoinMoin/version.py file, distribution package version), wiki configuration and follow the hints given on SecurityFixes page or other advisories.

If you use original, unmodified moin code downloaded from our web site, these hints usually apply directly.

If you use (patched) moin code as provided e.g. by Linux distributors, you will have to check their changelogs to find out whether specific security fixes have been applied. The moin version number will often stay the same, e.g. 1.9.3, but the code will get patched with security fixes. Be careful: this is usually only done while the distribution is considered "supported", if you run a outdated distribution release, you won't get security updates.

Apply the workaround to avoid your server getting compromised

On page SecurityFixes, there might be hints about how to immediately work around security issues even if you can't immediately upgrade the code or apply patches.

Here is what you usually need to do:

• stop all moin processes (e.g. stop your web server or whatever runs moin)
• apply the workarounds, often putting some stuff into your wiki config
• start all moin processes again (e.g. start your web server or whatever runs moin)

Did a security breach happen on your wiki?

Find out whether a security breach actually happened on your system:

• review the logs (check the permissions on the log also: could the wiki uid/gid edit the log?)
• look around in the filesystem for indications of a breach

Review / Evaluate

If a breach happened:

• inform your users (you can point them to this page)
  • put a note on your wiki front page or into the page header so it can be seen even when not looking at a specific page
  • put a note on your web site
  • write a mailing list post
  • always give a wiki admin / support contact in case there are problems with password reset, mail delivery, etc.
• evaluate whether privilege escalation (to root/Administrator) could have happened, consider:
  • if you run a rather old, not security-updated operating system: likely YES
  • if system is current, security-updated and well maintained: MAYBE (it is less likely, but you never can be sure)
• evaluate what other damage (even without root/Admin) might have happened:
  • check what uid/gid your moin process runs as. evaluate what code provided by an attacker running locally under that uid/gid could do in the worst case.
  • the attacker could have read (written) all files that are readable (writable) by that uid/gid, especially (but not limited to):
    • all wiki pages and attachments
    • all wiki user profiles
    • all moin caches, esp. the session storage
    • likely also plugin code (see data/plugin/*/*.py*)
    • maybe moin code or configuration (depends on your installation / file permissions)
• review your system thoroughly

Clean up

If your evaluation indicates so:

• install a fresh, clean system from scratch

• install a fresh, clean, fixed MoinMoin

• carefully migrate data over to it (be extremely careful with any executable code, including python or script files)
• change all secrets the attacker might know (see also below for the wiki user passwords)
• use the wiki uid/gid to run these commands (e.g. sudo -u wikiuser ...)

  • invalidate all wiki user passwords and notify users by E-Mail (this is new in moin >= 1.9.7).

    • moin --config-dir=... --wiki-url=... account resetpw --all-users --notify

  • clean all sessions (the session id might be known to the attacker!)

    • moin --config-dir=... --wiki-url=... maint cleansessions --all

  • clean all caches, some contain python bytecode and will be executed by moin:

    • moin --config-dir=... --wiki-url=... maint cleancache

Take care

Even if you don't think a breach happened:

• consider strongly upgrading to the latest release code / to patched moin code with all security fixes applied

• make sure passlib support is enabled/working (for moin >= 1.9.7 / patched moin code with passlib support)

• reset all user passwords - just to get rid of all weak password hashes