21 October 2023
Open Redirection vulnerabilities occur when an application incorporates user-controllable data in an unsafe way during redirection. This vulnerability when leveraged by an attacker in a phishing attack can allow the attacker to redirect a user to an arbitrary site.
To remediate an open redirection vulnerability, PortSwigger provides two high-level recommendations on their open redirection vulnerability summary page:
For this blog post’s purpose, we are only going to tackle the second point which is the creation of a server-side list of URLs which are permitted for redirection. Specifically, when a web application has a list which points to third-party websites.
While performing testing on a bug bounty program, I identified an endpoint which was vulnerable to an open redirection vulnerability. However, I observed that the developers had an allowlist implemented, meaning that the endpoint could only redirect to ‘trusted’ sites. For example, in this instance I could only redirect subdomains of the domain and a few well-known popular sites such as Google, Yahoo, Facebook, Instagram, and Bing.
At this point, it is fair to say that many testers may move on as this vulnerability doesn’t appear to be reportable as an ‘open redirection’ vulnerability. Rather, another vulnerability would need to be leveraged on a subdomain or trusted site to successfully demonstrate impact. Rather, testers may note this and move onto testing other sites within scope.
However, earlier that month I had read an article which would allow me to exploit this vulnerability for fun and profit.
Earlier this year, Cofense published an article detailing how threat actors are leveraging Google Accelerated Mobile Pages (AMP), an open-source HTML framework used to build websites optimized for both browser and mobile use in phishing campaigns.
I won’t dig into the technical details in this post as Cofense’s post provides a detailed overview of the vulnerability with nice screenshots, but essentially, the Google AMP URL “acts very similar to a redirect by sending users from the initial URL to the URL found within the path”.
To make it even more simple, clicking the following link: https://google.com/amp/s/parzival.sh will redirect you right back to my blog. Note, that is a real Google link, it just works! However, the evil part of this which Cofense called out is that threat actors are leveraging Google AMP in phishing campaigns as ‘Google.com’ being a trusted domain may allow for the bypass of Secure Email Gateways.
Now knowing the above information, we can go back to the Open Redirection vulnerability discovered in earlier in this blog post. Remember when I said that the domain I identified this vulnerability on allowed for redirection to Google.com? Well, now we have identified a way to leverage Google.com and redirect the user to an arbitrary website of our choosing.
This is one of those edge cases where the developers behind the application ‘trusted’ Google.com, and we the attacker, can abuse that trust leveraging the ‘vulnerability’ present in Google AMP. It’s a tricky situation, and further evidence on how important it is for developers to be cautious when referencing or leveraging any third-party website or service in their application.
For example, our successful payload would end up being the following:
demonstrating that we can redirect a user who is visiting the legitimate
website to an arbitrary URL. Furthermore, this vulnerability could be
leveraged by an attacker in phishing campaigns against the organization
and/or its users as mentioned in the Cofense article linked above.