Covert Redirect serves as a reminder to be careful about what applications you grant access to.
While logging on to a website or registering to comment using your Facebook, Twitter, or Google account may be convenient, the latest security flaw in open source code shows it's not such a great idea.
No sooner has the furor over Heartbleed abated than a new vulnerability has raised its ugly head, and it's to do with that oh-so-useful ability to skip creating unique accounts everywhere and instead log on through Facebook and such. And no, it's not new. But after a week of publicity in the technology and security community following the announcement of the flaw, dubbed Covert Redirect, you can bet that bad guys who were previously unaware of it will joyously pounce.
How nasty is Covert Redirect? Security vendor Symantec argued on on its blog that it was nowhere as widespread as Heartbleed, but worryingly for users it said "do not expect a patch – it is up to the service providers to secure their own implementations to effectively address the Covert Redirect flaw ... Covert Redirect serves as a reminder to be careful about what applications you grant access to."
According to the man who discovered the flaw, the list of sites that were vulnerable to Covert Redirect includes Microsoft Live, Google OpenID, Linkedin, Yahoo, The New York Times, blog platform Wordpress, developer resource GitHub and likely many more.
Here's how it works:
Two open source session authorization protocols – OAuth 2.0 and OpenID – are the culprits – or rather, corner-cutting implementations thereof. What they do, in broad strokes, is allow you to log on to a third party site such as a Web forum with your major provider account (say, Facebook) by passing your login credentials to the provider, receiving the authorization that you are who you say you are, possibly along with other information you're allowing the third party to access, and returning that info to the third party. At no time does the third party site see your Facebook login ID or password; it just gets the OK.
That sounds pretty innocent. The problem, reported last week by Ph. D student Wang Jing of the Nanyang Technological University in Singapore, but previously noted by other researchers, arises when the third party uses what's known as an open redirect, which puts a different return address in a parameter on the URL that returns login approval, without verifying that it's legitimate. A hacker compromises that new return address, redirecting it to the location of his or her choice. At that point, any information you've authorized Facebook to reveal is handed to the hacker. That can be anything from your e-mail address or birth date, or even full access to your Facebook account. It depends what permissions you've allowed to the third party.
Smartphone and tablet apps are also susceptible, and anyone who's actually read the list of permissions many apps request will know that they're a goldmine for identity thieves as well as phishers – some even demand the ability to send e-mail from your account without your knowledge.
Covert Redirect takes advantage of the fact that many third parties don't give the major providers a list of the allowable return addresses for redirects, known as a whitelist. And when the provider dutifully provides authorization, which comes back first to the third party's site or app, the third party doesn't check any redirect parameters to make sure they're legitimate before executing them. The combination of those two checks would prevent Covert Redirect attacks from happening.
The irksome thing about this is that, as users, there's not much we can do except avoid allowing other sites or apps to log in using our Facebook (etc) credentials. That means setting up independent accounts for everything. It's a pain, but there's no patch for Covert Redirect, and no way for us to even verify that our credentials aren't being misused.
According to Mr. Wang, service providers, on both the authenticator and third party sides, are expressing a serious lack of enthusiasm about implementing a fix. He said in his blog post describing the flaw, "One concern is the cost. And the other is that in their (third party) view, the host company is responsible for making the attacks appear more credible; therefore, it is not solely their problem. The onus would fall onto the Big Brother (the provider). However, to the provider, the problem does not originate from its own website. Even if it is willing to take on the responsibility, it has to gain cooperation from all the clients, which is nonetheless a daunting task."
Independent technology analyst Carmi Levy puts it all into perspective, noting, "In many ways we are falling victim to the increased modularity of the Internet. It's much easier to build a service using pre-fabricated blocks of code, or services, than it is to build those services on your own from scratch."
"So," he said, "companies like Google, Facebook and Microsoft are equally at risk when the inevitable vulnerabilities are discovered in these commonly used elements. It may be more efficient up-front to architect systems in this way, but the price we pay in the longer-term is increased exposure to widespread hacking after a weakness is discovered."
These flaws also highlight a potential blind spot in software development: Trust. Both Heartbleed and Covert Redirect are caused by a similar thing: forgetting to check inputs. Whatever the reason, checking inputs should be computer programming 101, and as more bad actors seek vulnerabilities on our increasingly connected digital lives, the devil is indeed in the details.