Google UI-Redressing Bug That Discloses The User's Email Address
- 3 minsIn this post, I will discuss an exciting bug affecting Google Blogger. This security bug has been left undiscovered since almost 2007.
The bug allows an attacker to trick the victim into revealing his email address using UI-redressing techniques.
Background
We always see a header on blogs that is hosted on Google Blogger that looks like the following:
For unauthenticated users:
For authenticated users:
As you can see, the user’s email address is shown in the screenshot of an authenticated user. The challenge is using this feature to reveal users’ email addresses.
After testing the issue, the response of the HTTP request holds the user’s email address and lacks the usage of the X-Frame-Options header. This means that anyone can make an HTTP request within an Iframe and craft it in a way that can help the attacker in making unintended actions.
In most cases, we use UI-Redressing when we can perform “clicks”; in that form, we would specify it as “Clickjacking.” This case is a slightly different type of UI-Redressing from an exploitation point of view.
The idea that came to mind was to create a proof of concept that includes an Iframe that responds with the user’s email address and then forces the user into pasting the email within the page, where it gets sent to an external server (e.g., the attacker’s server).
I have put this idea into code that does that. You can watch the following demonstration video to see an example of the exploitation of the issue.
A second idea, which failed to be performed due to the robust Same-Origin Policy of modern browsers, was to have an Iframe that responds with the user’s email address. Once the response is received, a Javascript within the same HTML page executes that takes a screenshot of the Iframe and then sends it to an external server, where a function will run to transform the image into plain text. This issue was not possible due to the Same-Origin Policy, as the API of getscreenshot() is restricted to being unable to read pixels of a non-same-origin Iframe.
Vendor Response
After a discussion with Google Security, Google decided not to patch the issue.
Final Thoughts
This was quite an interesting bug, yet the issue’s impact could be a lot higher. I want to share it as this issue is almost ten years old, and no one has discovered, exploited, or discussed it before.
I thank the Google Security Team for their prompt and quick response.