OAuth & OpenID : Vulnérabilité “Covert Redirect”

OAuth & OpenID : Vulnérabilité “Covert Redirect”

Certaines implémentations des protocoles d’authentification OAuth et OpenID s’avèrent vulnérables à un récent vecteur d’attaque nommé “Covert Redirect“.

Ce type d’attaque permet à un assaillant de capturer vos données personnelles et de forcer des redirections vers des sites arbitraires (Open Redirect).

Les liens forgés par un attaquant exploitant cette vulnérabilité sont anodins, et leur comportement légitime est généralement de vous authentifier auprès de Facebook, Google ou un autre fournisseur d’identités pour accéder à un site tiers.

Le paramètre de redirection d’URL après authentification n’est pas suffisamment vérifié par ces fournisseurs d’identités implémentant ces protocoles. La plupart des majors fournisseurs de ce protocoles (Facebook, Google, Yahoo, LinkedIn, Microsoft, Paypal, GitHub, etc) sont, ou ont été vulnérables.

Ces faiblesses protocolaires et mises en garde sont indiquées directement au sein des RFCs de ces protocoles. Ainsi la faiblesse porte plus sur l’implémentation que le protocole en lui-même.

OAuth

4.2.4. Threat: Open Redirector

An attacker could use the end-user authorization endpoint and the
redirect URI parameter to abuse the authorization server as an open
redirector. An open redirector is an endpoint using a parameter to
automatically redirect a user agent to the location specified by the
parameter value without any validation.

Impact: An attacker could utilize a user’s trust in an authorization
server to launch a phishing attack.

Countermeasures:

o Require clients to register any full redirect URIs
(Section 5.2.3.5).

o Don’t redirect to a redirect URI if the client identifier or
redirect URI can’t be verified (Section 5.2.3.5).

OpenID :

This URI MUST exactly match one of the Redirection URI values for the Client pre-registered at the OpenID Provider, with the matching performed as described in Section 6.2.1 of [RFC3986] (Simple String Comparison). When using this flow, the Redirection URI MUST NOT use the http scheme unless the Client is a native application, in which case it MAY use the http: scheme withlocalhost as the hostname.

[youtube]https://www.youtube.com/watch?v=HUE8VbbwUms[/youtube]

Wang Jing (tetraph) a révélé cette vulnérabilité sur son site Internet et via un article sur CNet. Il a réalisé de nombreuses vidéos de démonstration / PoC du “Covert Redirect” sur les majors de l’Internet :

Ces récentes considérations à propos des protocoles d’authentification/d’autorisation ont été sujettes à une présentation de la conférence GRRCON 2014 “v09 OAuth20 a It’s the Implementation Stupid – Tony Miller” :

Recent media attention around “Covert Redirects” has stirred new concerns over an already identified weakness in OAuth 2.0 implementations. So if the weakness is not new, why do we keep hearing about it? OAuth 2.0 is a framework that when implemented correctly can be very secure but many developers do not understand or adhere to the specification and best practices for secure implementation. When implemented poorly, the resultant vulnerabilities can be a treasure chest of data exposure and session hijacking attack vectors. We’ll explore common mistakes in implementing OAuth2.0 and how they can be exploited. Use of OAuth has expanded well beyond its early implementations in social media platforms and is becoming increasingly common in enterprise development so we’ll delve into specific attack vectors that result. Of course we’ll also cover the design and remediation strategies that help prevent those common implementation flaws.

[youtube]https://www.youtube.com/watch?v=fuMU5zFfswM[/youtube]

Ce vecteur d’attaque, outre le fait qu’il concerne la plupart des fournisseurs d’identités et majors de l’Internet, s’avère difficile à patcher. Les redirections vers des sites tiers doivent être finement surveillées et acceptées qu’en cas de site de confiance. Nous vous invitons à surveiller l’actualité liée à cette vulnérabilité, en particulier si vous exploitez ces protocoles et ces fournisseurs au sein de votre SI.

Sources & ressources :

Yann

Consultant Sécurité

Étiquettes : , , , , , ,