Que faire si votre Discourse est compromis

Nous avons récemment eu deux rapports de sites Discourse qui ont été compromis, probablement en raison de mots de passe de compte administrateur faibles. Nous souhaitons donc documenter :

  • ce qu’il faut faire en cas de compromission
  • ce que nous pouvons faire pour mieux prévenir cela à l’avenir

La base de données

Veuillez noter que Discourse, depuis plusieurs années, met en place les protections suivantes concernant la base de données du site :

  • Les liens de téléchargement complets des sauvegardes de la base de données ne seront envoyés que par e-mail valide d’un administrateur de site. Vous ne pouvez donc pas simplement vous connecter (par observation furtive ou en oubliant de vous déconnecter), vous devez également contrôler l’adresse e-mail d’un administrateur de site. Et vous avez configuré la 2FA pour votre e-mail, n’est-ce pas ? :wink:

  • Pour changer l’e-mail du personnel, vous devez vérifier le contrôle des adresses e-mail à la fois l’ancienne et la nouvelle – alors qu’un utilisateur normal n’a besoin de vérifier que le contrôle de la nouvelle adresse e-mail. Cela rend beaucoup plus difficile le changement d’adresse e-mail d’un membre du personnel.

  • En supposant que vous ayez configuré la clé API de la base de données de géolocalisation (elle est gratuite, nécessite une inscription), vous êtes activement averti lorsque les membres du personnel se connectent depuis des emplacements physiquement éloignés de leur dernière connexion.

  • Les administrateurs qui ne se sont pas connectés depuis plus d’un an sont tenus de revalider leur adresse e-mail, afin de réduire la surface d’attaque. Le paramètre du site pour cela est invalidate inactive admin email after days et sa valeur par défaut est de 365.

:warning: Néanmoins, en cas de compromission, vous devez toujours supposer qu’un compte administrateur malveillant a téléchargé une copie complète de la base de données/sauvegarde du site.

Par conséquent, vous devez IMMÉDIATEMENT réinitialiser tous les mots de passe des comptes en utilisant la commande suivante :

./launcher enter app
rails r 'UserPassword.update_all(password_hash: SecureRandom.hex * 2)'

De plus, vous devez déconnecter tous les utilisateurs

./launcher enter app
rails r 'UserAuthToken.destroy_all'

Enfin, vous devez supprimer toutes les clés API

./launcher enter app
rails r 'UserApiKey.destroy_all' 
rails r 'ApiKey.destroy_all'

Mots de passe des comptes dans la base de données

Conformément à notre documentation de sécurité, Discourse utilise des hachages très solides et lents à attaquer pour les mots de passe stockés dans la base de données :

Discourse utilise l’algorithme PBKDF2 pour chiffrer les mots de passe salés. Cet algorithme est approuvé par le NIST. Les experts en sécurité sur le web ont tendance à convenir que PBKDF2 est un choix sûr.

Et la longueur minimale par défaut du mot de passe est de 10 pour les utilisateurs et de 15 pour les administrateurs – ce qui rend difficile l’inversion par force brute des hachages de mots de passe pour obtenir le hachage. Mais cela n’empêche pas les utilisateurs de définir un mot de passe comme password1password1 ou quelque chose d’autre qui est trivial à inverser, même avec un hachage fort.

E-mails dans la base de données

L’attaquant peut voir toutes les adresses e-mail de tous les utilisateurs de votre site. Il s’agit normalement d’informations privilégiées que même les modérateurs doivent cliquer sur un bouton pour les révéler.

Contenu des messages dans la base de données

Puisque l’attaquant dispose d’une copie de la base de données, il peut voir toutes les informations stockées dans tous les messages.

  • Si vous avez transmis des mots de passe externes ou des informations de compte dans vos réponses, privées ou publiques, vous devez changer ces mots de passe immédiatement.

  • Si vous avez des informations sensibles dans vos réponses, privées ou publiques, sachez que l’attaquant peut voir ces informations.

Messages chiffrés

Si vous utilisez le plugin Discourse Encrypt, les messages chiffrés seront chiffrés de bout en bout. Cela signifie que si une base de données fuit, l’attaquant ne pourra pas accéder au contenu des messages chiffrés.

Réglementations

Assurez-vous de demander un avis juridique professionnel concernant vos obligations légales. Certaines réglementations telles que le RGPD et le CCPA peuvent imposer une divulgation.

À l’avenir

Vous souhaiterez peut-être exiger l’authentification à deux facteurs pour les utilisateurs du personnel si vous avez des raisons de croire que votre site fera l’objet d’attaques. Le paramètre de site que vous recherchez est « enforce second factor » (forcer la deuxième authentification)

enforce second factor

Force les utilisateurs à activer l’authentification à deux facteurs. Sélectionnez « all » pour l’imposer à tous les utilisateurs. Sélectionnez « staff » pour l’imposer uniquement aux utilisateurs du personnel.

44 « J'aime »