Open Redirect is one of the most overlooked vulnerabilities with potentially devastating consequences. The simple flaw allows a fraudster to redirect the user to a phishing website without raising any suspicion by masking the URL as a legitimate one. Since ThreatMark deals with this issue often, let’s dig deeper and find out how this vulnerability operates.
Open Redirect is mostly used in phishing attacks which are still the most successful attacks in existence. The victim receives a trustworthy looking e-mail with a link that points to a seemingly legitimate domain. Even though the user might be knowledgeable about phishing e-mail tricks, parameters changing the link into a redirect are hard to spot. This is possible because of Open Redirect, a specific type of behavior allowing parameter values in an HTTP request in which a web application accepts a user-controlled input (e.g. specifying a link to an external website) and uses this input to redirect the user.
Example of such link:
The link above shows the structure of a fraudulent link. The application parses the request’s “url” parameter and then redirects the user to the specified URL. This could be abused by an attacker for a phishing campaign, where he could send the victim to a legitimate domain, and right after to the attacker’s website.
Sometimes, due to the specific architecture of the website, the actual redirection takes place after the victim provides credentials on a legitimate site first which makes it even easier to convince the victim to enter their credentials into the bogus phishing page.
The victim then hands over the credentials to the attacker and usually redirected to the valid website then. The whole process might look as if the victim mistyped their password the first time.
Live Example. Trick Google!
It is possible to exploit the google.com domain to redirect a user without any verification. This is possible thanks to the following url.
As can be seen, the endpoint consumes a “q” parameter containing the URL, the “sa” parameter, a “sntz” parameter and a “usg” parameter containing some kind of hash connected to the “q” parameter -> if the “q” parameter is changed, the “usg” parameter needs to be changed too.
The way the hash in the “usg” parameter is computed is not public. However, it can be easily obtained by using Gmail in the basic HTML view, as described here. In this way, we were able to generate a Google redirect link for the made-up URL:
and its Google redirect URL:
Danger That Lasts
Our Fraud Analysts encounter Open Redirect vulnerabilities in the vast majority of all phishing attempts that are analyzed in our Security Operations Center. Sometimes, the attacker exploiting the Open Redirect vulnerability uses the website of the banking institution itself. Links then look like they lead to the bank’s domain and users can easily be convinced to hand over the credentials to whatever page they see.
Sadly, the possibility to redirect users this way doesn’t get enough attention from the developers since it is not jeopardizing websites directly and doesn’t compromise directly the company’s sensitive data. Moreover, many companies are not considering this a vulnerability at all. For instance, Google itself does not consider this a vulnerability, as described here.
There is not much to do about this situation. There are some mitigations suggested by OWASP, but aimed mostly for the web admins. For the rest, a proper and reliable anti-phishing strategy should be put in place. ThreatMark solution offers multiple measures to mitigate phishing attacks, sometimes even in their initial stage.
Luca Winter, Lukáš Jakubíček