Intéressant. J'allais demander des précisions mais tu en as apporté quelques-unes. Je recommande à tous ceux qui utilisent le même mot de passe ou un mot de passe proche de celui utilisé sur MV de le changer sur tous les autres sites. Le changer sur MV est également recommandé dès maintenant (en ne prenant surtout pas le même mot de passe que sur un autre site), mais également une fois la faille identifiée et corrigée.
Citation :
dans laquelle les mots de passe ne sont pas stockés en clair
Attention cependant, il y a pas mal de types d'attaque possibles pour récupérer un mot de passe.
Déjà, si les mots de passe sont chiffrés en base de données, récupérer la clé de chiffrement permet de les lire sans problème. Les mots de passe
devraient plutôt être hashés (si possible avec un salt pour compliquer la tâche lors des attaques de type rainbow table).
Ensuite, même si l'application ne stocke que des hash de mots de passe, celui-ci reste vulnérable à plusieurs moments lors de la connexion de l'utilisateur.
Sur la machine de l'utilisateur
Si un
script malicieux est présent dans la page il peut lire le mot de passe sans problème et l'envoyer sur un serveur quelconque. La machine du client peut aussi être infectée (malware) sans rapport avec MV en particulier. Un simple accès aux mots de passe enregistrés dans les options du navigateur par un proche ou toute personne ayant un accès physique à la machine est également possible.
Dans la requête HTTP de connexion
Lors de la validation du formulaire de connexion, si la connexion n'est pas sécurisée par HTTPS, ou si la clé privée du certificat SSL associé a fuité, la requête HTTP est vulnérable aux attaques de type
man-in-the-middle ou
network sniffing. Elles sont simples à réaliser sur un réseau local ouvert (wifi non chiffré par exemple) en utilisant
une simple extension dans le navigateur de l'attaquant ou un
analyseur réseau, mais
beaucoup plus complexes à réaliser sur un réseau local sécurisé ou sans avoir accès au réseau local de la victime (en gros il faut avoir un accès à un des équipements réseau entre la victime et le serveur de l'application).
Dans la RAM du serveur applicatif
Même si le serveur ne persiste pas le mot de passe saisi par l'utilisateur en base de données, il doit forcément au moins récupérer et hasher celui qui a été saisi par l'utilisateur lors de sa tentative de connexion, avant de comparer le résultat avec le hash sauvegardé en base. Par conséquent le mot de passe existe en clair dans la RAM du serveur MV au moins pendant un court laps de temps à partir de la tentative de connexion.
Des attaques de type
heartbleed permettent d'accéder à des extraits de la RAM de l'application et récupérer (entre autres) ce genre d'informations. Il est également possible pour un hacker ayant eu un accès admin au répertoire physique hébergeant le code de l'application, de déposer une version vérolée modifiée du code, qui envoie les mots de passe saisis par tous les utilisateurs à l'attaquant.
---------------------
Étant donné les infos présentées jusque là :
- Extraction des mots de passe depuis un dump de la base de données : probable si les mots de passe ne sont pas hashés (PBKDF2-style).
- Serveur applicatif compromis : envisageable étant donné la très forte recrudescence d'attaques bruteforce SSH via botnet notamment sur les serveurs OVH ces derniers mois. J'ai moi-même dû prendre certaines mesures pour endiguer le flot sur mon serveur perso (filtrage IP, etc.).
- Attaque XSS : envisageable, j'ai moi-même identifié (et déjà remonté à JMB) au moins une façon d'exploiter cette faille, mais elle ne permet pas dans mon cas la récupération du mot de passe. Il faudrait faire une passe sur les différentes pages où on peut se connecter pour vérifier la présence de scripts de ce genre.
- Man-in-the-middle pré-HTTPS (évoqué par JMB) : envisageable mais peu probable selon moi, vu la complexité de mise en œuvre et la faible exposition de MV.
- Heartbleed : improbable, a priori la version de modssl devrait trop récente pour permettre d'exploiter la faille.
- Sniffing de réseau local : improbable en raison de l'envergure de l'attaque (plusieurs personnes sans lien apparent affectées).
Il y a aussi la possibilité d'une autre faille non identifiée, ou d'une infection des machines clientes sans rapport avec MV (keylogger, trojan, extension navigateur corrompue, etc.).