~bohwaz/blog/

Avec de vrais morceaux de 2.0 !

Forum Mesdiscussions.net : A l'abri des pirates... Ou pas ?

Pour ceux qui ne connaissent pas le logiciel de forum "Mesdiscussions.net" c'est celui qui équipe de nombreux forums à forte audience (Doctissimo, Hardware.fr, Fluctuat...). Si au niveau performances ça semble remplir ses promesses (encore que sur Hardware.fr c'est parfois indisponible), au niveau de la sécurité c'est pas la même.

Voilà ce qu'ils promettent sur leur site :

A l'abri des pirates !

Les forums indisponibles pour cause de piratage ou submergés par les messages indésirables sont nombreux. Afin de protéger les données sensibles de votre forum et garantir son accessibilité, MesDiscussions.net a été développé dès l'origine par une seule et même équipe, avec le souci de garantir une sécurité maximale : vous bénéficiez ainsi d'un forum sûr, hermétique aux messages indésirables, et ne nécessitant pas de mise à jour hebdomadaire complexe pour corriger ses failles.

(L'emphase est de mon fait.)

Si on s'intéresse plus en profondeur au logiciel on va avoir de mauvaises surprises. D'abord au niveau du code, car le forum est fourni chiffré, il faut installer ionCube PHP Loader pour pouvoir exécuter le code. Si c'est ça qu'ils entendent par un forum "sûr" c'est pas des masses rassurant, la sécurité par l'obscurité n'étant jamais une bonne idée.

Au niveau sécurité je n'ai pu découvrir de failles d'injection SQL, mais je me suis arrêté avant la fin de l'audit sur un problème digne d'un débutant, actuellement (car mon audit date de 2007) toujours visible sur le forum hardware.fr (au moins, j'ai pas vérifié les autres) : le site n'utilise pas de sessions mais stocke à la connexion 2 cookies pour identifier l'utilisateur :

user: bohwaz
passs: 721a9b52bfceacc503c056e3b9b93cfa

Le mot de passe (ici 'coucou') est simple hashé en MD5, sans salt ni rien. Il est facile d'imaginer à partir de là de nombreux angles d'attaques :

  • On pourrait sniffer la connexion d'un wifi ou la sortie d'un nœud tor, récupérer les cookies et les rejouer dans son navigateur, permettant de se connecter à la place de l'utilisateur, poster à sa place, etc.
  • Idem en sniffant on peut aussi matcher le hash avec une base de données de hash existants (au hasard celle-ci) et retrouver le mot de passe de la personne. Ainsi on pourrait changer le mot de passe du compte, et utiliser ce mot de passe pour essayer de se connecter sur le compte mail associé au compte forum (vu que beaucoup de gens ont le même mot de passe partout).
  • Enfin on pourrait essayer de trouver le mot de passe d'un utilisateur par brute force de manière très simple vu qu'il suffit de renvoyer un hash différent en cookie.

Bref une erreur de base qui ne devrait pas exister. PHP propose un système de sessions tout à fait correct et s'il ne convient pas il est toujours possible d'en faire un soi-même. Stocker les données personnelles de l'utilisateur (même "cachées" comme ici) est une très mauvaise idée. Et l'image de forum sûr en prends directement un coup...

Écrire un commentaire
(facultatif)
(facultatif)
(obligatoire)
  __      _                 _ _          
 / _|_ __(_) __ _ _ __   __| (_)___  ___ 
| |_| '__| |/ _` | '_ \ / _` | / __|/ _ \
|  _| |  | | (_| | | | | (_| | \__ \  __/
|_| |_|  |_|\__,_|_| |_|\__,_|_|___/\___|
                                         
(obligatoire)

Les adresses internet seront converties automatiquement.
Tags autorisés : <blockquote> <cite> <pre> <code> <var> <strong> <em> <del> <ins> <kbd> <samp> <abbr>

Haru

Huhu, et dire que les forums du site où je bosse tournent avec mesdiscussions... Heureusement que le chantier communautaire est prioritaire, ils s'inquiéteront ainsi peut être du soucis :s

niluje

Tient, pareil qu'Haru, au boulot nous utilisons ce système de forum.

Mais concernant cette pseudo faille de sécurité : à partir du moment où tu peux intercepter les requêtes réseaux d'un utilisateur (de forum ou autre), que le système utilise des sessions, cookies ou autre, tu peux forcément usurper de son identité non ?

Que le mot de passe soit hashé de façon standard ou avec quelques contournements (genre salt), ça ne change en rien au soucis exact ?

De façon un peu plus poussée concernant ton audit de sécurité, niveau SQL injections & co (qui sont nettement plus préjudiciable que l'usurpation de l'identité potentiel d'un membre !) le système est très robuste, nous n'avons jamais eu à nous plaindre à ce niveau, c'est carré !

BohwaZ

Comme dis dans l'article, c'est une question de sécurité de tes utilisateurs et de celle de leurs données. Car on peut imaginer intercepter ces hashs de diverses manières : proxy transparent d'entreprise (assez commun), hotspot wifi, noeud tor, etc. Une fois les hashs interceptés il suffit d'utiliser des rainbow tables pour retrouver les mots de passe en clair et les essayer sur les comptes e-mails des utilisateurs (qui ont souvent le même mot de passe), usurper leur identité sur le forum, spammer le forum, etc.

Le hashage avec salt (le salt doit être différent pour chaque utilisateur) rendrait la manoeuvre plus complexe, car du coup impossible d'utiliser des rainbow tables, mais ça resterait une mauvaise pratique de le stocker dans le cookie utilisateur.

Le problème est grave et sérieux car il pose le souci de la confidentialité et la protection des données utilisateur.

Si tu utilise une session, oui tu peux usurper l'identité, si tu arrive à intercepter l'identifiant de session. Maintenant plusieurs obstacles : une session a une durée de vie limitée, il est possible qu'elle n'existe plus (par expiration ou par déconnexion de l'utilisateur), et en l'état elle ne permettrait pas de s'emparer du contrôle du compte : pour changer le mot de passe du compte il faut en connaître le mot de passe. Et comme on n'aurait pas le mot de passe du compte, impossible d'aller voir s'il fonctionne aussi sur le compte mail etc. Donc le pire qui pourrait arriver : poster quelques messages sur le forum, voir réussir à faire bannir l'utilisateur en postant des contenus contraires au règlement du forum. Bref, moins tentant que de récupérer le mot de passe.

Concernant les injections SQL, impossible de te répondre, le code étant chiffré il est impossible de voir sa qualité, mais si c'est à la hauteur de l'erreur des cookies (erreur de débutant), il y a de quoi avoir peur. On peux analyser les requêtes SQL envoyées au serveur, mais c'est plus fastidieux et je t'avoue qu'à l'époque on n'avait pas été plus loin que le système de cookies douteux qui était déjà rédhibitoire pour nous en termes de sécurité.

Maintenant en tant qu'utilisateur de forums basés sur ce logiciel voici mon point de vue : j'ai pas confiance.