Facebook Connect, Google Sign-In, Twitter Sign-In… Depuis plusieurs années, les géants du Net proposent des services d’authentification unique (Single Sign On, SSO) que les développeurs peuvent intégrer dans leurs applications mobiles. Ainsi, une personne qui veut utiliser TripAdvisor, Pokemon Go ou la base IMDb peut, ainsi, télécharger l’application et presque directement commencer à l’utiliser car l’inscription et la connexion sont prises en charge par Facebook Connect ou Google Sign-In. Mais ce aisance lors la création de compte de la gestion d’accès cache aussi d’énormes risques de sécurité.
A l’occasion de la conférence Black Hat Europe 2016, trois chercheurs en sécurité hongkongais – Ronghai Yang, Wing Cheong Lau et Tianyu Liu – viennent de démontrer qu’un grand nombre d’applications tierces implémentent mal ces services d’authentification, de sorte qu’un pirate peut se connecter au compte de l’utilisateur au travers de son propre terminal mobile, de n’importe où dans le monde, simplement en connaissant le numéro de compte de l’utilisateur. Ce qui n’est pas difficile à trouver: parfois, une recherche Google suffit.
Payer une chambre d’hôtel, faire des achats en ligne…
D’après les chercheurs, ce problème est très largement répandu et impacterait au moins un milliard d’utilisateurs dans le monde. En effet, les chercheurs ont établi une sélection de 14 applications très populaires et vulnérables, en précisant les données exposées et les transactions frauduleuses rendues possibles (voir tableau ci-dessous). Ils ne donnent évidemment pas leurs noms, mais on y trouve un peu de tout: des applications de cartographie, de réservation d’hôtel, d’e-commerce, de musique, de messagerie, etc. En usurpant l’identité de l’utilisateur, un pirate pourrait donc se payer une chambre d’hôtel, faire des achats en ligne, passer des coups de fil gratuits, etc.
Ces applications ont été téléchargées au total plus de 2,4 milliards de fois. Compte tenu du taux d’adoption des services d’identification (51 %), les chercheurs ont estimé qu’au moins un milliard de comptes étaient donc vulnérables. Ils ont concentré leur analyses sur le monde Android, mais ils soulignent que ce problème ne dépend pas du système d’exploitation. Ils sont donc persuadés que les applications iOS sont tout autant vulnérables.
Pour comprendre techniquement ce problème, il faut d’abord se plonger dans les mécanismes d’authentification. Facebook Connect et consorts utilisent les protocoles OAuth2.0 et OpenID Connect (voir schéma ci-dessous).
Lorsqu’un utilisateur veut se loguer sur une appli tierce (IMDB par exemple), celle-ci va s’adresser à l’appli du fournisseur du service d’identification (Facebook par exemple). Qui va ensuite interroger son serveur pour obtenir les données utilisateur (e-mail et identifiant de compte généralement) ainsi qu’un jeton d’accès (Access Token, AT). Les données utilisateurs peuvent, de surcroît, être signées.
Signature et jeton sont être transmis à l’appli tierce, qui les envoie à son serveur. Ce dernier va ensuite vérifier la signature des données et s’assurer que le jeton corresponde bien aux données utilisateur. Si tout concorde, on peut accéder à son compte.
Malheureusement, ces vérifications ne sont pas toujours bien implémentées. Certaines applications ne vérifient pas le jeton, ni la signature des données. Elles vont identifier l’utilisateur en s’appuyant uniquement sur leur identifiant chez Google, Facebook ou consorts.
Pour exploiter cette faille, le pirate peut rester tranquillement chez lui. Tout ce qu’il a faire, c’est de se doter d’un terminal sur lequel sont installés l’application tierce (IMDB par exemple) et l’application d’identification (Facebook par exemple), et surtout un dispositif permettant une attaque de type Man in the Middle (un proxy SSL par exemple) en mesure d’intercepter et de modifier les requêtes. Il se connecte avec son propre compte, capte la réponse du service d’authentification et remplace son numéro de compte avec celui de sa cible. Et hop, il est connecté au compte de sa victime au travers de son propre terminal.
Certes, l’application du service d’authentification peut procéder à une vérification des certificats TLS (certificate pinning). Dans ce cas, le pirate peut essayer de la désinstaller. Ainsi, l’appli tierce se verrait contrainte de lancer le navigateur web qui, sur un smartphone, ne supporte cette fonction. Dans le cas où le service d’authentification interdit tout bonnement l’usage d’un navigateur web, les choses se compliquent. Le pirate peut alors être contraint de faire une analyse par rétroingénierie de l’application pour y supprimer la fonction de certificate pinning. C’est d’ailleurs ce qu’ont fait les trois chercheurs avec l’application Facebook.
Pas évident à corriger
Résoudre ce problème ne se fait pas d’un claquement de doigt. C’est d’abord aux différents développeurs d’applications tierces d’implémenter correctement les protocoles d’authentification. Néanmoins, les fournisseurs de services d’identification devraient également mieux informer et guider ces développeurs sur tous ces aspects de sécurité, par exemple en fournissant une meilleure documentation.
Un moyen simple d’éviter les mauvaises surprises, c’est de ne pas utiliser ces services d’authentification, mais de définir directement un mot de passe sur l’application tierce. Evidemment, c’est moins pratique et contraint a bien gérer ses mots de passe. Mais c’est une autre problème…
🔴 Pour ne manquer aucune actualité de 01net, suivez-nous sur Google Actualités et WhatsApp.
