User:OrangeStar/Compromised handling

When a security vulnerability shows itself, it's important to understand what the vulnerabilities can actually do, and follow a standardized checklist on how to respond to them to ensure no further damage can be done.

It is helpful to keep this quote by Steven M. Bellovin in mind: "A former official at NSA's National Computer Security Center told me that the standard assumption there was that serial number 1 of any new device was delivered to the Kremlin". Applied to security vulnerabilities, assume that an attacker knew about the vulnerability before you even read about it, and that everything that could be compromised, was compromised.

What can be compromised

 * Bacula (passwords)
 * Grafana (passwords)
 * Icinga2 (It contains passwords to connect to the db)
 * Icingaweb2 (Includes user passwords in the db and contains passwords to connect to the db)
 * IRC (mirahezebots password)
 * Mail (DKIM key, noreply password)
 * MariaDB (account passwords and databases)
 * MediaWiki (multiple things, see its own section)
 * PostgreSQL (account passwords, databases, private keys)
 * PuppetDB (passwords for postgresql)
 * Redis (password)
 * Roundcubemail (Password to connect to mail server, also password to connect to db)
 * Salt master (SSH private keys)
 * SSL
 * Certificates used on cp*, like the miraheze.org wildcard and custom domains' certs.
 * Certificates used on mw*, for establishing a TLS connection between them and cp* via stunnel.

MediaWiki

 * The integrity of revisions in public wikis, additionally the confidentiality of private wiki's revisions and deleted and suppressed revisions on all wikis.
 * Password hashes.
 * TOTP secrets. This includes the TOTP secret key and scratch codes for every account.
 * Anything on PrivateSettings.php.

SQL injections
SQL injections call into question the confidentiality of any private data in the db that the affected application had access to, as well as the integrity of everything.

MediaWiki
Everything in this list should be done if this happens to MediaWiki or one of its extensions.


 * If applicable, disable the extension in question (add it to https://github.com/miraheze/mw-config/blob/master/LocalSettings.php#L5684). If it happened to MediaWiki core, update it immediately. After all, there's no point in doing the rest of this list if the vulnerability can still be exploited.
 * Advise users to change passwords and disable and enable 2FA. The hashing should prevent the passwords from being compromised immediately, but don't count on it keeping the password secret once an attacker has it. TOTP secrets are stored in the DB, disabling and re-enabling TOTP generates new secrets and invalidates the older ones.

WebAuthn
If an user was using WebAuthn (coming soon, T10700), SQL injections would only compromise the confidentiality of the public key, which is useless on its own unless the attacker has broken RSA/ECDSA/Ed25519 public key cryptography, in which case we have much bigger things to worry about.