Covert Redirect isn’t a vulnerability, and it’s nothing like Heartbleed

On Friday, a PhD student at the Nanyang Technological University in Singapore, Wang Jing, published a report focused on a method of attack called “Covert Redirect,” promoting it as a vulnerability in OAuth 2.0 and OpenID.

However, this isn’t the first time the issue has been raised, and it isn’t anywhere near as bad as Heartbleed was.

OAuth 2.0 and OpenID enable access. Using these services allows a visitor to a given domain, to gain access by using their existing credentials on another website, such as Facebook, Google, Microsoft, or LinkedIn. Doing so removed the step of registering a new account.

Over the years, the two services have grown in popularity, as they enable a wide range of interaction across brands, and offer an easy path of access for the end user.

Jing’s disclosure points out the fact that unless implemented properly, users who see the typical OAuth 2.0 or OpenID pop-up form a given provider, could be falling for a trap.

In a statement, CloudLock’s Kevin O’Brien explained further:

“The ‘Covert Redirect’ component of the vulnerability refers to a similarity to how some phishing attacks work: when the user grants OAUTH access on the provider pop-up, the actual OAUTH token that is generated is not granted to the service that the user thinks they are using, but rather to a third party service that is potentially malicious.”

Is this a potentially serious issue? Yes, it is. However, it isn’t anywhere near as bad as Heartbleed was.

Brandon Edwards, the VP of SilverSky Labs, agreed, stating that Covert Redirect is far less impactful than Heartbleed, “which has the potential to expose the most critical information that a site processes.”

Moreover, despite what early reports have said, this isn’t a Facebook problem, or a Google problem, the root cause is a lack of token whitelisting in OAuth 2.0.

Personally, I think that vulnerability is a strong word, bordering on irresponsible when used in this context.

It isn’t a vulnerability at all, as the problem isn’t in the OAuth 2.0 framework, it’s in how the framework is implemented by developers. 

As mentioned, this isn’t the first time the issue has been made public. Last year, Egor Homakov reported the same issues. (“TL;DR: all OAuth exploits are based on tampering with the redirect_uri parameter.”)

Even the IETF outline on OAuth 2.0 warns about the risk associated with open redirects in the redirect_uri, and LinkedIn issued a warning about registering URIs earlier this year.

So is it something to be concerned over? Yes. But there is so much going on here, that the problem isn’t a big as it seems. Most of the websites using OAuth 2.0 and OpenID are social in nature. So infrastructure, such as VPN access, isn’t impacted and neither is banking or other financial data.

In this case, basic Phishing would be more effective at scale. While Covert Redirect would enable some data collection, it’s a multistage process that a majority of criminals won’t bother with.

Even if they did, they’d still need to get the victim on the domain, and once there, get them to click the login button for Google or Facebook to authorize the release of information.

Moreover, there isn’t a patch for this. Not like Heartbleed. The fix here is proper implementation, which means using URI whitelisting.

That’s unlikely to happen for massive websites like Facebook. They can’t add whitelisting unless they want to break a high number of client implementations (killing the user experience in the process), the same can be said for other providers.

So be aware that the issue exists, but it isn’t a vulnerability, it isn’t the end of the world, and it’s nothing like Heartbleed.