Sur Android, des gestionnaires de mots de passe laissaient fuiter des identifiants

Certains gestionnaires de mots de passe sur Android laissent filtrer des informations quand ils remplissent automatiquement les champs d’authentification dans une application. Cette découverte a été présentée la semaine dernière la conférence Black Hat. Des correctifs ont déjà été apportés.

Les gestionnaires de mots de passe jouent un rôle crucial dans la sécurité aujourd’hui. Ils permettent non seulement de stocker les identifiants pour les régurgiter quand nécessaire, mais surtout de créer des mots de passe uniques et aléatoires. On peut dès lors avoir un mot de passe différent pour chaque service, en plus de pouvoir créer de longues chaines de caractères (majuscules, minuscules, chiffres et caractères spéciaux).

Bien qu’ils apportent un surplus de protection, la sécurité proposée dépend de la manière dont les informations sont traitées, comme on l’a vu avec LastPass.

Des chercheurs, menés par Ankit Gangwal de l’Indian Institutes of Information Technology, ont montré à la dernière conférence Black Hat qu’il était assez simple, sous Android, de récupérer les identifiants échangés entre un gestionnaire et une application, quand le premier ne fait pas attention aux conditions de l’échange.

C’est (pas) la faute de WebView

Sur Android comme sur iOS, on peut déclarer une application comme gestionnaire de mots de passe par défaut. Lorsque l’on souhaite se connecter sur une application ou un site web, ce gestionnaire peut venir alors fournir les identifiants dans les champs correspondants.

De nombreuses applications proposent une webview pour gérer ces champs. Il s’agit d’une vue déportée du navigateur, qui vient s’intégrer naturellement dans l’application. Cela évite des allers-retours entre l’application et le navigateur, avec un important gain de temps.

Selon les chercheurs qui ont présenté leurs travaux la semaine dernière, c’est justement autour de cette webview que se situe le problème. Malheureusement, quand l’échange d’informations n’a pas été bien préparé, cette webview peut laisser filtrer les informations d’authentification à l’application censée les recevoir, alors qu’elles sont censées ne jamais être révélées.

Il devient donc possible d’imaginer des vecteurs d’attaque pour récupérer ces informations, notamment via une application malveillante qui surveillerait ces échanges. C’est ce qu’ont fait les chercheurs.

Le problème survient également avec les mécanismes SSO d’Apple, Facebook, Google, Microsoft et autres. À partir du moment où une webview est demandée par une application, le gestionnaire peut lui confier ses précieuses informations. Si le mécanisme n’est pas suffisamment robuste, les données d’authentification peuvent fuiter.

1Password, LastPass, Keeper…

Devant les tentatives des chercheurs, plusieurs gestionnaires ont été épinglés pour avoir révélé à la fois l’identifiant et le mot de passe : LastPass (5.11.0.9519), Enpass (6.8.2.666), Keepas2Android (1.09c-r0) et Keeper (16.4.3.1048). 1Password (7.9.4) a révélé le mot de passe seul, tandis que Google Smart Lock (13.30.8.26) et Dashlane (6.2221.3) n’ont rien révélé.

Curieusement, BitWarden ne semble pas avoir été testé. Avec un peu de JavaScript, tous les gestionnaires ont en revanche révélé les deux informations. Les tests ont eu lieu sur les versions 10, 11 et 12 d’Android.

Ces travaux ont été menés l’année dernière. Tous les éditeurs concernés ont été avertis, et tous ont depuis corrigé le tir, comme l'a indiqué Forbes notamment.

Comme l’a confirmé Google à BleepingComputer, le problème ne réside pas dans le composant WebView, mais dans la manière dont les applications l’utilisent. Chez LastPass et Keeper, on insiste sur la faible dangerosité de la faille, car les chercheurs avaient utilisé un malware pour intercepter les informations, ce qu’une application classique provenant du Play Store ne peut a priori pas faire. Du côté de 1Password, on ne cherche pas à se défendre : les travaux ont permis d’identifier une faiblesse, qui a depuis été colmatée.

Interrogée par TechCrunch, l’équipe de chercheurs a confirmé que d’autres travaux étaient en cours pour vérifier si le problème était reproductible sur iOS.