OAuth 2.0 & OpenID Connect : 2 nouvelles vulnérabilités d’implémentation

Les implémentations d’OAuth 2.0 et OpenID Connect connaissent depuis ce début 2016 deux nouvelles vulnérabilités liées à leurs implémentations. OAuth 2.0 est l’un des protocoles de fédération des identités / authentification (Single Sign-On) et d’autorisation les plus utilisé sur le web ; OpenID Connect est une surcouche de ce protocole et s’avère donc également concerné. 

Introduction

Nombreux sont les majors de l’Internet à implémenter ces protocoles : Facebook, Google, Microsoft, GitHub et bien d’autres l’ont adopté. De plus en plus d’entreprises et nos clients adoptent ces mécanismes d’authentification / autorisation pour leurs diverses applications internes et/ou privées.

Un groupe de chercheurs allemand de l’Université de Trier a réalisé une analyse de sécurité fine du standard OAuth 2.0 / OpenID Connect, et a découvert deux nouveaux vecteurs d’attaques portant sur ces standards et affectant leurs implémentations.

The OAuth 2.0 authorization framework defines a web-based protocol that allows a user to grant web sites access to her resources (data or services) at other web sites (authorization). The former web sites are called relying parties (RP) and the latter are called identity providers (IdP). In practice, OAuth 2.0 is often used for authentication as well. That is, a user can log in at an RP using her identity managed by an IdP (single sign-on, SSO).

HTTP Redirection code 307

Le premier vecteur d’attaque concerne le mécanisme de redirection employé par l’IdP suite à l’authentification / autorisation, pour revenir sur l’application initial (le RP). Plusieurs techniques sont généralement observées, notamment celles liées aux codes HTTP de redirection (302, 303, etc.).

Le scénario se décrit ainsi : un utilisateur-victime utilise OAuth pour se connecter sur une application-RP malicieuse contrôlée par l’attaquant. La victime est par conséquent redirigée vers son IdP où il entre ses crédentiels pour s’authentifier.

Ces crédentiels sont soumis via une requête POST à l’IdP, ils sont vérifiés par celui-ci, puis, l’utilisateur est redirigé finalement vers l’endpoint de l’application-RP initial.

Si cette redirection finale implémente un mauvais code de redirection HTTP, tel que le code 307, le RP malicieux de l’attaquant va recevoir l’ensemble des données POST soumises par le formulaire d’authentification précédent, incluant les crédentiels de l’utilisateur.

En effet, une redirection HTTP 307 (Temporary Redirect) fait suivre également les données POST issues de la requête initiale, bien que les domaines diffèrent. Le protocole OAuth autorise explicitement n’importe quelle redirection HTTP d’où la présence de ce vecteur d’attaque, alors que seules les redirection 303 devraient être autorisées.

Identity Provider mix-up

Le second vecteur d’attaque, surnommé “Identity Provider mix-up”, nécessite que l’attaquant puisse manipuler les diverses requêtes émises et reçues par l’utilisateur-victime ; l’attaquant doit donc être placé en tant qu’homme du milieu (Man in The Middle attack).

L’attaquant peut ainsi manipuler la première requête de la victime afin que le RP pense que l’utilisateur cherche à utiliser une identité gérée par un IdP malicieux contrôlé par l’assaillant, bien que l’utilisateur pense utiliser son IdP légitime. Il en résulte que le RP transmet l'”authorization code” ou l'”access token” (dépend du mode OAuth employé) en provenance de l’IdP légitime vers l’IdP de l’attaquant.

Celui-ci peut par la suite utiliser ces données pour se connecter au RP sous l’identité de la victime ou accéder à des ressources personnelles de l’utilisateur sur l’IdP légitime (impersonation). Pour empêcher ce vecteur d’attaque, une correction est à apporter au niveau des endpoints de l’IdP.

Pour finir…

Chacune de ces attaques peut être menée à l’encontre du standard OpenID Connect, qui est une extension, une surcouche au protocole OAuth 2.0.

La bonne nouvelle est que chacune de ces attaques peut être évitée facilement. Le groupe de travail des standards OAuth 2.0 et OpenID Connect a d’ors et déjà décidé d’implémenter des mécanismes de sécurités additionnels.

Les chercheurs allemands de l’Université de Trier considèrent, suite à la réalisation de cet audit et des mesures prises pour corriger les vecteurs d’attaques, que le protocole OAuth 2.0 est suffisamment sécurisé pour assurer à la fois l’authentification et l’autorisation des utilisateurs, si implémenté correctement cela va de soit.

Sources & ressources :

• A comphrensive formal security analysis of OAuth 2.0
• After two fixes, AOuth standard deemed secure – HelpNetSecurity
• Boffins turn up a couple of protocol vulns in Facebook’s login standard – TheRegister

Yann

Consultant Sécurité