Can someone explain the "Covert Redirect" vulnerability in OAuth and OpenID?

Question

CNet is reporting that all OpenID and OAuth sites are vulnerable to an attack called "Covert Redirect". What is this attack, how does it work, and as an end user, how can I mitigate the risk?

I think it's worth mentioning that this isn't something new and can be found in section 4.2.4 of the OAuth2.0 RFC: http://tools.ietf.org/html/rfc6819#page-22 — gsgx, May 02 '14 at 18:21

dthorpe · Accepted Answer · 2014-05-29T16:38:40.703

This isn't a vulnerability of/in OAuth 2.0 at all. The issue has been wildly overblown and misstated by CNET and the original finder.

Here it is in a nutshell: If your web site (example.com) implements an open redirect endpoint - that is, implements a URL that will redirect the browser to any URL given in the URL parameters - AND your redirect copies URL parameters from the incoming URL to the outgoing redirect URL, then it is possible for third parties to exploit this artifact of your web site in a wide variety of nasty ways.

Worst case: evil.com is able to get the auth code originally intended for your web site (example.com) and may be able to use that auth code to extract user information from the auth provider (Google, Facebook, etc) or possibly even take control of the user's account on your web site.

Would evil.com be able to take control of the user's Google account using that access code? No, because the access code was minted for your site, example.com, and only works there.

Who's fault is it? Yours, for implementing an open redirect on your site. Don't blame Google or Facebook or others for your poor implementation.

There are a few legitimate use cases for having a redirect on your site. The biggest one is to redirect the browser after login to the web page (on your site) that the user originally requested. This only needs to redirect from your web site to pages in your web site, on your domain.

How to fix it? Have your redirect endpoint (example.com/redirect?&destination=ht.tp://foo.com...) validate the destination URL. Only allow redirects to pages on your site, in your domain.

More info on my blog: http://dannythorpe.com/2014/05/02/tech-analysis-of-serious-security-flaw-in-oauth-openid-discovered/

Update: There is an open redirect issue when using Facebook for OAuth user login. When you configure your app definition on Facebook, be sure to enter your domain-specific redirect URL in the redirect field provided. Facebook allows this field to be left blank. If left blank, Facebook itself acts as an open redirect while processing user logins for your web site.

Facebook should fix this by simply not allowing the redirect URL field to be left blank.

Well put. I was suspicious of the vague description on CNET myself, wondering how this represented an actual flaw in OAuth. — Dan Tao, May 02 '14 at 22:54

score 13 · Answer 2 · answered May 02 '14 at 20:28

As others have stated, this is not a new idea. Eran Hammer (one of the creators of the Oauth 1.0 spec, who resigned from the Oauth 2.0 committe) wrote a good synopsis of the vulnerability, almost 3 years ago. His description didn't get a fancy logo or any sensational media coverage.

http://hueniverse.com/2011/06/21/oauth-2-0-redirection-uri-validation/

chrisdrobison · Answer 3 · 2014-05-02T19:30:08.253

10

Here is a Youtube video the original finder put together leading you through the vulnerability: https://www.youtube.com/watch?v=HUE8VbbwUms.

OpenId and OAuth both provide a field that allows a third-party site to specify a redirect when authentication has completed and is successful. For instance, you go to Good Reads, they want you to login with your Facebook account. Good Reads will tell Facebook, "hey, when the user authenticates successfully, redirect them back to http://goodreads.com." The vulnerability is that some of these third-party sites allow redirects to be specified in their URLs (http://google.com/redirect?url=http://attacker.com) and may not validate them before they redirect the user. So, an attacker could create a "Login with Facebook" link for a valid site like Good Reads and could specify the redirect url to be something like http://goodreads.com/redirect?url=http://attacker.com (assuming Good Reads did this kind of redirect), your Facebook login popup would show that Good Reads (a perfectly normal site for you to be going to) wants to authenticate with Facebook, but when you authenticate and redirect back to Good Reads, if Good Reads doesn't validate the redirect URL, you'll be immediately redirected to http://attacker.com.

The fix would be for third-parties to validate redirects, but that may take a while to happen. The other thing is, CNet has reported that attackers might be able to steal information through this little interchange, but I'm not quite sure if that is possible. Someone else can comment on the matter. But, getting a user to a bad site is probably good enough for them.

edited May 02 '14 at 19:30

answered May 02 '14 at 17:03

chrisdrobison

201
1
4

6

The video does show how the attacker site can get the access token, but it looks like it's beyond OpenId or OAuth at that point. It looks like ESPN has some parameter you can use to tell the redirect to copy all current parameters into the redirect. That seems less like an OpenId or OAuth issue and more like a generic open redirect issue in ESPN's site. – chrisdrobison May 02 '14 at 17:17
4

So, if I understand correctly, this has nothing to do with OpenID or OAuth at all, and is simply an XSS attack on an open redirector? This is an interesting attack vector, but open redirectors are well known to be an XSS vulnerability so I'm not sure why this is so newsworthy. – Daniel Pryden May 02 '14 at 19:49
3

Correct. As mentioned by gsingh2011 in his comment above, this kind of problem is already warned about in the RFC, but it's up to the third-party to take care of it. The news is sensitive to reporting vulnerabilities right now after Heartbleed and IE. This guy can make a name for himself without actually having found anything new. – chrisdrobison May 02 '14 at 20:01
If the auth-provider (e.g. Facebook) was stricter and only allowed redirect URLs that are in the registered domain of the app, then this issue would be easily mitigated. Sites that truly require open (i.e external) redirectors can implement that logic themselves, and I would suspect this is a much smaller set of apps. – Shyam Habarakada May 02 '14 at 21:16
1

@ShyamHabarakada Major auth providers already do validate redirect URLs against the client app's preconfigured domain name. I know Google does, and I would bet Facebook does too. The exploit is not in the redirect from the auth provider to the client app, but that the client app itself implements an open redirect. That's what is being exploited here. – dthorpe May 02 '14 at 21:31

score 1 · Answer 4 · answered May 02 '14 at 15:10

1

This is a form of man in the middle attack where a site can grab your OpenID credentials. It works because the sources of openID (facebook, google, etc) do not perform sufficient checks when openID queries are sent.

There's nothing you as the user can do about it, all you can do is be very wary about using Oath and openID. If a site you wouldn't expect to use openID pops up an openID window then don't allow it. If you suspect that your openID credentials have been captured go to the authentication source (facebook, google, whatever) and change it there as soon as possible.

answered May 02 '14 at 15:10

GdD

17,291
2
41
63

3

This doesn't make much sense to me -- for example, Google [OpenID](https://developers.google.com/accounts/docs/OpenID#openid-connect) and [OAuth](https://developers.google.com/accounts/docs/OAuth2Login#sendauthrequest) implementations require the `redirect_url` parameter to match a URI specified in the Developer Console. So doesn't this exploit require the participation of the site I'm trying to log into (at which point, is it really an exploit at all)? – Daniel Pryden May 02 '14 at 16:51

score 0 · Answer 5 · answered May 03 '14 at 02:38

http://tetraph.com/covert_redirect/

From the website,

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.

score -1 · Answer 6 · answered May 02 '14 at 15:04

-1

So imagine I executed some form of phishing link that you opened. Let's say I pretended to be your bank. Under normal conditions, I'd have to create a spoofed domain to trick you. www.y0urb4nk.com and hope you clicked the link. With the Covert Redirect attack, an attacker exploits Oath/OpenID to use the actual bank's info to pull off the phish for me. Instead of me using y0urb4nk.com I can now use yourbank.com (the actual site) to pull of the hack. This is the flaw explained.

So in an nutshell:

attacker [ exploit oauth/openid ]

    generate phishing attack

        send vulnerability to target

    domain is legitimate attacker abuses this

        user falls for exploit and enters data

    now send this data to attacker instead of legit domain

game over

Fix? Short term would be to stop using OpenID/Oauth until a fix is found

answered May 02 '14 at 15:04

munkeyoto

8,682
16
31

What "actual bank's info" is being extracted here, and how, and how is it used to "pull of the phish"? That is exactly the question I'm asking, and this just appears to be a handwave of the details I'm curious about. – Daniel Pryden May 02 '14 at 16:52
banks info as in the link IS NOW COMING FROM THE BANK (legitimate bank) attackers no longer have to impersonate – munkeyoto May 02 '14 at 17:08
1

Please add a little more information on details. As it stands, this answer does not appear credible and does not point at any particular weakness in the protocols. – Christopher Creutzig May 05 '14 at 05:36

Can someone explain the "Covert Redirect" vulnerability in OAuth and OpenID?

6 Answers6

Linked