Incident SQL et changement de mot de passe obligatoire

De Wiki IRC
Aller à :navigation, rechercher

Bonjour,

Entre le 20 mars à 16h45 et 21 mars à 12h30, la base de données SQL de Discussionner.com a été compromise (un hack par injection SQL). L'hackeur en SQL a dérobé toutes les informations de chaque compte par lequel vous vous connectez (https://discussionner.com, de la partie identifiant/mot de passe).

Informations volées (probablement)

Les informations qui ont été volées :

  • le pseudo (identifiant unique)
  • l'adresse e-mail
  • le mot de passe (à la fois en clair et en hash)
  • date de création du compte
  • dernière connexion au compte
  • numéros de téléphone pour l'OTP (seulement si vous l'avez confirmé)

Toutes les informations volées sont celles que vous avez renseignées sur le formulaire d'inscription au tout début.

Informations non volées

Voici les données qui n'ont pas été volées, car soit elles n'existent pas, soit elles ne font pas partie d'une base de données SQL :

  • Les conversations (elles n'existent pas)
  • Les uploads (messages vocaux, photos, …) (l'hackeur n'a volé que les stats (dates, heures, noms de fichier, indice NSFW) via SQL qui sont remises à zéro tous les 7 jours)
  • Les utilisateurs qui se connectent avec Google sur Discussionner.com ont un mot de passe généré automatiquement. Ce mot de passe a été changé et n'est pas utilisé, sauf s'ils décident de le modifier eux-mêmes.
  • Les informations des bots (Quiz, Tapavu, etc..) n'ont pas été volés, car ils n'ont pas de compte SQL.

Résumé des informations sensibles

Pour faire simple, l'hackeur n'a volé que les informations sensibles suivantes :

  • l'adresse e-mail
  • le mot de passe
  • le numéro de téléphone ou WhatsApp (seulement si vous l'avez renseigné)

Mise à jour et sécurisation

Dans la soirée du 22 mars 2026, une mise à jour du site a été faite, ce qui a réparé l'injection SQL par laquelle l'hackeur a pénétré. La faille est corrigée depuis le 22/03/2026 à 23h00.

Le 23/03/2025 à 18h00, une protection en plus a été mise en place qui permet de bloquer automatiquement une tentative d'injection SQL dès le premier essai.

Mise en place d'un grand signalement pour changer de mot de passe

Les comptes qui ne sont pas concernés par injection SQL sont ceux des utilisateurs qui se sont connectés sur Discussionner.com avec l'authentification via Google (en utilisant le bouton: se connecter avec un compte Google).

À partir du lundi 23 mars 2026 (dans la journée), nous forcerons tous les utilisateurs à changer leur mot de passe obligatoirement. Vous pouvez le faire dès maintenant à partir de votre compte sur https://discussionner.com en vous connectant, si ce n'est pas déjà fait.

Si vous ne pouvez pas vous connecter à votre compte, allez sur la page "Mot de passe perdu", saisissez votre adresse e-mail, cliquez sur le lien dans votre e-mail, fournissez un nouveau mot de passe, puis connectez-vous.

Conseils pour vos mots de passe

Veuillez ne pas mettre le même mot de passe sur tous les sites que vous utilisez. Par exemple, sur Discussionner, votre mot de passe peut très bien être :

  • AABBCCDD@EE;@FF

Et sur un autre site sur Internet, ça peut très bien être :

  • DDBBAA@F;F@EE

Et sur vos autres comptes d'autres sites sur Internet :

  • DDBBAA@F;F@EE111
  • DDBBAA@F;F@EE222
  • DDBBAA@F;F@EE333

À la place de 111, 222 ou 333, ça peut être les derniers chiffres d'une plaque d'immatriculation ou autre. Il suffit d'inverser, d'en mettre plus, de mixer, et vous aurez un mot de passe unique et sécurisé pour tous vos comptes sur Internet.

Après avoir changé votre mot de passe, votre compte redeviendra tranquille comme avant.


Une reproduction du hack par injection SQL a été faite

Le 25/03/2026 : Un administrateur du site Discussionner a reproduit la faille de ce qu'elle pourrait révéler comme informations. Pour plus de facilité, l'admin a modifié directement les commandes SQL en dur dans php dans "query".

Voici les résultats de nos analyses :

Test 1

- La commande "SHOW ..." ajoutée peut montrer la liste des tables, liste des bases de données, noms des colonnes...

Test 2

- Du code PHP ajouté directement dans la commande query est resté sans succès. Ça retourne des erreurs PHP.

Test 3

- En cas d'erreur PHP, la page peut afficher environ 50 caractères dans le query qui casse tout, et cela a dévoilé une clé unique qui permet de crypter un mot de passe d'utilisateur. Cette clé a été renouvelée lundi 23 mars 2026.

Test 5

- Du code JavaScript ou PHP: (<script>, <?php) est impossible à générer.

Vérification N°6

- Aucun script ni code malveillant trouvé dans les répertoires du site.

Test 7

- Il est possible que le hackeur ait injecté des commandes SQL courantes qui peuvent être : UNION, OR, AND, SELECT... ainsi que des commandes connues en SQL, mais rien ne prouve qu'il peut afficher le contenu des tables.

Vérification N° 8

- En février 2026, et vers le 15 mars, il y a eu des tentatives de commandes injectées à cet endroit

Test 9

- Il est possible que le hackeur ait injecté " OR 1=1" ou " OR id=1", et qu'il se soit connecté sur des comptes utilisateurs sans avoir besoin du mot de passe.

Test 10

- Impossible d'afficher quoi que ce soit avec LOAD_FILE() et impossible d'écrire quoi que ce soit avec INTO OUTFILE.

Test 11

- Il est possible que le hackeur se soit amusé avec d'autres commandes SQL en jouant aux devinettes, sans que rien ne s'affiche, mais que s'il se connecte, alors le caractère est forcément bon. Cependant, il n'aurait pas pu faire ça pour tous les utilisateurs, car rien que d'en faire 3 d'utilisateurs pourrait durer une journée entière.

Test 12

- En testant UNION en sélectionnant la base de données, il y a un accès possible aux colonnes qu'ils souhaitent. La commande ne fait que 7 mots. Les données sont affichées directement rien qu'avec un simple query.


Pour conclure :
Le test N°12 montre qu'il est possible d'accéder aux données des tables. Du coup, il faut considérer les bases de données comme compromises.

En testant tout ça, ça m'a permis de comprendre comment fonctionnent les queries avec les GET, POST, etc., ce qui améliore mon expérience ainsi que ma compréhension du fonctionnement de SQL et des hacks par injection SQL sur de nombreux sites et applications sur Internet.