Leveraging Google AMP to Exploit Open Redirect Vulnerabilities

Open Redirection Vulnerabilities

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:

• Remove the redirection function from the application and replace links to it with direct links to the relevant target URLs.
• Maintain a server-side list of all URLs that are permitted for redirection. Instead of passing the target URL as a parameter to the redirector, pass an index into this list.

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.

Discovering an Open Redirection Vulnerability

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.

Leveraging Threat Actors TTPs

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.

Back to the Open Redirection

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: https://www.target.com?redirect=https://google.com/amp/s/parzival.sh, 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.

A Real World Example

• Further information has been redacted until my HackerOne report has been both remediated and published!