Nothing sets the technical journalists abuzz like the prospect of a catastrophic, Internet-wide vulnerability. Fresh off the very legitimate excitement over Heartbleed, some media outlets were hoping for a new scoop with "Covert Redirections". Spoiler alert: there's no catastrophe.
For those that haven't heard, this started with a paper and series of blog posts by Wang Jing. Wang describes an attack against websites that use third-party authentication services and are vulnerable to a specific type of Open Redirection. He named this attack "Covert Redirection".
Covert Redirection attacks are actually only one variant of a much larger group of attacks that can be described as Third-Party Auth Token Thefts. There are two important concepts to understand: third-party authentication or authorization and URL-based data routing.
There are two main standards involved in this family of attacks: OpenID and OAuth. OpenID only provides for authentication. OAuth was primarily designed for authorization services, but it can also be used for authentication.
Many people have used third-party auth (meaning either authentication or authorization). Any time a website allows you to login with your Google or Facebook account, you are using third-party authentication (OpenID or OAuth). When a website or mobile application asks you to allow Google or Facebook to share your information, you are using third-party authorization (OAuth).
Hidden to the user, the browser is passing information between the parties. The website you're accessing generates a request string that your browser sends to the authenticator or authorizer server (e.g., Google). The auth server may require that you click an "allow" button or provide your password before it sends your browser a security token in the URL (webpage address). The token is generated using cryptographic techniques to prevent forgery or modification. The final step is your browser sending that token back to the website you want to access.
The core of Wang's attack is based around an "Open Redirect" vulnerability being present on the targeted website. Open Redirects can be used (legitimately or otherwise) to point a user's browser at a second website. For example, requesting the following URL might send a browser to Trustwave's website.
http://www.example.com/redirect.do?destination=http://www.trustwave.com/
→
http://www.trustwave.com/
Some (but not all) open Redirects can be used to route data to a second website. The next URL could cause the "user" and "location" parameters to be included in the request to trustwave.com, even if they were intended for example.com.
http://www.example.com/redirect.do?destination=http://www.trustwave.com/&user=David&location=Colorado →http://www.trustwave.com/&user=David&location=Colorado
It is up to the webpage's programmer to determine what data the browser will send to the destination. Redirection webpages that include too much information can allow attacks like Third-Party Auth Token Theft.
There are many other legitimate website functions that can be used to route data from a URL. The attacker's end goal is to send data to a location he can access. The targeted location could even be on the same website. For example, forum posts, product reviews, email generation forms, or profile notes can all be used to store data in a location that an attacker can easily access remotely. The simplified example below shows how a URL might be crafted to post a product review online:
http://www.example.com/products/review.php?ID=123&stars=3&subject=My+Review&body=This+is+the+body
A poor implementation might allow for other parameters ("security_token" in the example) to be included in the review.
http://www.example.com/products/review.php?ID=123&stars=3&subject=My+Review&body=This+is+the+body&security_token=72616e646f6d74657874
In the attack descried by Wang, an open redirection vulnerability is used to capture the security token generated by the auth server and redirect it to a server controlled by the attacker. Once that security token falls into malicious hands, your identity can be spoofed on the targeted website and, in certain cases, some of your data on the auth service (Google, Facebook, etc.) may be captured.
The critical lesson missed by many bloggers and analysts is that Covert Redirection is only one of many possible attacks against third-party authentication/authorization. As described earlier, there are many techniques for URL-based data routing; any web component that stores or retransmits data is a potential attack vector. While OpenID and OAuth typically use URLs for data, techniques exist to capture data sent in other formats.
Intense security testing and strong development practices can prevent these data handling flaws, but some can still slip through the cracks. Website and mobile application developers need to think hard about whether third-party authentication fits their needs. Remember, this is effectively delegating the most critical security control. A blogging application that uses Facebook to authenticate commenters is certainly a reasonable use, but authenticating the Blog's administrator with Facebook is more questionable. Using a third-party to authenticate applications that handle critical data is very, very risky. It certainly makes authentication easy for users, but it can also turn normally low-risk vulnerabilities like open redirection into critical flaws being targeted by attackers.
Q: Are Covert Redirects or other Third-Party Auth Token Thefts a vulnerability in the OpenID or OAuth providers?
A: Not directly. First, the attacks can only be exploited against websites that are vulnerable to a specific type of open redirect or contain specific types of poorly implemented content creation. Additionally, many auth providers allow websites to limit the destination of security tokens, preventing the malicious use of open redirects.
Q: Are Covert Redirects or other Third-Party Auth Token Thefts a new vulnerability?
A: No. The OAuth standard actually describes the Covert Redirect attack specifically and outlines security controls that will prevent the entire class of attacks. More generally, open redirects and content generation from URLs have been long documented as poor practices.
Q: What can an attacker do with a successful exploit?
A: For OpenID, the attacker can impersonate a victim user, but only on the vulnerable site. The stolen token cannot be transferred anywhere else. The OpenID Identity Provider is not affected at all.
For OAuth, the attacker may be able to access data belonging to the user, but only data that the user has granted the vulnerable website access to.
Q: How can users protect themselves?
A: The best strategy is to limit how you use third-party authentication or authorization. When Google or Facebook prompt you to allow access to your data, realize that you are creating a trust relationship. Users will rarely know if the trust is well-placed, but the more trust relationships you create, the more opportunities there are for attack. Periodically reviewing your list of authorized apps or websites will allow you to delete ones that you no longer use.
Many websites give a choice between third-party authentication and creating a new account. For critical data, such as finance or purchasing, Trustwave advises users to avoid third-party authentication and stick with an account internal to the website.
Q: How can website developers or administrators protect their site?
A: Several precautions can be taken:
Q: What should OpenID or OAuth providers do?
A: Providers should always allow websites to define specific redirect destinations. Some providers may choose to make this optional to simplify integration, but the potential risk associated with that decision should be clearly documented.
Thanks to Charles Henderson and Scott Parcel for assisting with this post.