Des chercheurs découvrent deux failles dans le protocole OAuth 2.0
Des chercheurs découvrent deux failles dans le protocole OAuth 2.0
qui peuvent conduire à des attaques de type MITM
Un groupe de chercheurs de l’université de Trier (en Allemagne) a effectué une analyse de sécurité de la norme OAuth 2.0. Ils ont découvert que deux types d’attaques auraient pu être utilisés pour briser les autorisations et authentifications dans OAuth.
En guise d’introduction dans le document décrivant leur recherche, ils ont rappelé que le protocole OAuth 2.0 permet aux utilisateurs d’accorder à des parties de confiance un accès aux ressources de fournisseurs d’identité. En plus d’être utilisé pour ce type d’autorisation, OAuth est également souvent utilisé pour l’authentification dans les systèmes SSO (single sign-on, système à authentification unique, une méthode permettant à un utilisateur d'accéder à plusieurs applications ou sites web sécurisés en ne procédant qu'à une seule authentification). Il faut noter qu’OAuth 2.0 est l’un des protocoles les plus utilisés dans ces desseins sur le web avec des entreprises comme Google (avec Google Account), Yahoo (avec YahooID), Facebook (avec Facebook Login) ou Microsoft (avec Live ID) qui jouent le rôle de fournisseurs d’identité et des millions de sites web qui se connectent à ces services jouent le rôle de parties de confiance.
Si OAuth 2.0 est au cœur de nombreuses implémentations à l’instar de celles qui sont citées en sus, l’étude note que la prochaine version du système SSO Open ID Connect va également se baser dessus. Pour rappel, OpenID est un système d’authentification décentralisé qui permet l’authentification unique, ainsi que le partage d’attributs. Il permet à un utilisateur de s’authentifier auprès de plusieurs sites (devant prendre en charge cette technologie) sans avoir à retenir un identifiant pour chacun d’eux, mais en utilisant à chaque fois un unique identifiant OpenID.
« Malgré la popularité d’OAuth, jusqu’à présent les efforts d’analyse ont été orientés pour trouver des bogues dans des implémentations spécifiques et se basaient sur des modèles formels qui faisaient abstraction de nombreuses fonctionnalités web ou ne fournissaient pas du tout un traitement formel », précisent les chercheurs, avant de relever deux vulnérabilités qui peuvent permettre d’exécuter deux attaques.
Les chercheurs ont expliqué que dans la première attaque (aussi connue sous le nom de HTTP 307 Temporary Redirect – redirection temporaire), les fournisseurs d’identité font suivre par inadvertance des identifiants (nom d’utilisateurs et mots de passe) aux parties de confiance ou à un attaquant.
« Cette attaque sévère est causée par une erreur logique dans le protocole OAuth 2.0 et est tributaire de la présence de parties de confiance malveillantes », ont-ils commenté. « Dans cette attaque, le pirate (qui se sert d’une partie de confiance malveillante) glane des informations sur les identifiants de l’utilisateur lorsque celui-ci se connecte à un fournisseur d’identité qui se sert du mauvais code d’état de redirection HTTP ».
Voici le scénario d’attaque qu’ils ont décrit : l'utilisateur se sert d’OAuth pour se connecter à une partie de confiance malveillante gérée par l'attaquant, et est redirigé vers le fournisseur d'identité où il est invité à entrer ses informations d'identification. Les identifiants sont envoyés au fournisseur d'identité via une requête POST, puis vérifiés et par la suite l'utilisateur est redirigé vers l’extrémité de la redirection de la partie utilisatrice. Si le fournisseur d'identité utilise le code d'état de redirection 307 HTTP, la partie de confiance malveillante (c’est-à-dire l'attaquant) recevra également une requête POST contenant toutes les données issues du formulaire précédent, ce qui inclut les informations d'identification de l'utilisateur.
Les chercheurs estiment que, pour résoudre ce problème, seuls les codes HTTP 303 devraient être autorisés dans OAuth étant donné que « la redirection 300 est définie sans ambiguïté pour ne pas utiliser le corps d’une requête HTTP POST ».
La seconde faille implique une attaque sur le site de la partie de confiance : « l’attaquant sème la confusion chez la partie de confiance concernant quel fournisseur d’identité l’utilisateur a choisi au début du processus de connexion/autorisation dans l’intention d’obtenir un code d’authentification ou un token d’accès qui pourrait être utilisé pour usurper l’identité de l’utilisateur ou accéder à ses données ».
Voici le scénario de l’attaque : « l’attaquant manipule la première demande de l’utilisateur de telle façon que la partie de confiance pense que l’utilisateur veut utiliser une identité gérée par un fournisseur d’identité de l’attaquant alors que l’utilisateur voudrait plutôt utiliser une identité gérée par un fournisseur d’identité légal. Par conséquent, la partie de confiance envoie le code d’autorisation ou le token d’accès (dépendant du mode de l’OAuth) délivré par le fournisseur d’identité légal à l’attaquant, qui peut par la suite utiliser ces valeurs pour se connecter à la partie de confiance sous l’identité de l’utilisateur (gérée par le fournisseur d’identité légal) ou accéder à ses ressources protégées ».
Pour pouvoir effectuer cette attaque, les pirates doivent être en mesure de manipuler les requêtes envoyées par les utilisateurs ainsi que les réponses, ce qui signifie qu’ils doivent avoir une présence sur le réseau (attaque Man-in-the-middle).
Les chercheurs ont expliqué que pour résoudre ce problème, OAuth devrait inclure l’identité du fournisseur d’identité dans la redirection d’une certaine façon. « Plus précisément, nous suggérons que les parties de confiance fournissent une extrémité de redirection unique pour chaque fournisseur d’identité. Ainsi, l’information redirigée par le fournisseur d’identité sera encodée dans la requête et la partie de confiance pourra détecter les anomalies ».
Avec ces problèmes résolus, les chercheurs ont estimé qu’OAuth 2.0 est suffisamment sécurisé pour fournir à la fois les autorisations et les authentifications, si elles sont implémentées correctement.
Ian Muscat, responsable de la communication produit chez Acunetix (spécialiste de la sécurité des applications web), a avancé que « lorsqu’il s’agit des processus d’authentification et d’autorisation au sein d’une application web, à moins d’avoir une compréhension profonde de la technologie ainsi qu’une raison spécifique, justifiable et soigneusement réfléchie, ne déployez pas votre propre système d’authentification. À la place, servez-vous d’une bibliothèque ou d’un Framework qui a été examiné par le public et a une communauté active qui traite la question de sécurité comme étant prioritaire ».
Pour Liviu Itoafa, chercheur en sécurité chez Kaspersky Lab, parlant de l’attaque qu’il est possible de lancer contre le site de la partie de confiance, il a avancé que « ce problème implique qu’il doit y avoir un souci du côté de la partie de confiance – par exemple elle pourrait ne pas se servir de HTTPS pour la requête initiale de l’utilisateur ».
Source : étude (au format PDF)
Et vous ?
Que pensez-vous de ce protocole ? L'utilisez-vous ?
Répondre avec citation
Partager