I found that several world-renowned web applications lack protection of web resources from UI Redressing attacks, thus revealing data that can be abused to disclose a user's identity. An identification attack could be successfully performed by exploiting a UI Redressing flaw affecting web resources that include, for example, the name or the e-mail address of the victim.
A series of vulnerabilities are presented below in order to exemplify some of these attacks. The first issue affects a Google's web application: an authenticated Google user can be attacked by abusing a UI Redressing vulnerability related to the support.google.com domain. As shown in Figure 1, no X-Frame-Options header is adopted, thus allowing the cross-domain extraction of personal data such as:
- Victim's e-mail address;
- Victim's first and last name;
- Victim's profile picture URL.
|Figure 1 - Google Support vulnerable to UI redressing attacks.|
Similar vulnerabilities have been found on other popular web applications. The following is a list of identified vulnerable web resources, exposing user's data:
Microsoft Profile (First name, last name, e-mail address, etc - Figure 2)
|Figure 2 - Microsoft Profile web resource vulnerable to UI Redressing attacks.|
Yahoo! (e-mail address, first name, birth date, sex, etc - Figure 3):
|Figure 3 - Yahoo! web resource vulnerable to UI Redressing attacks.|
Beyond the iframe-to-iframe extraction method
The Google Chrome web browser seems to have defeated any extraction methods, denying the use of the view-source handler and disallowing cross-origin drag&drop. Despite these adverse conditions, I identified some attack scenarios where a UI Redressing issue could be still performed in order to extract sensitive data. Once again, the method is extremely simple. Instead of a cross-origin drag&drop, the victim is tricked to perform a same-origin action, where the dragged content belongs to a vulnerable web page of the targeted application and the "dropper" is a form (text area, input text field, etc.) located on the same domain. Using a site's functionality that allows publishing externally-facing content, it is still possible to extract information. Under these circumstances, Chrome will not reasonably deny the same-origin drag&drop, thus inducing the victim to involuntary publish sensitive data. As a matter of fact, the attacker is exploiting a subsequent clickjacking vulnerability on the same domain, which causes the publication of the personal information. I refer to this kind of attack chain as a "bridge" that allows the attacker to move sensitive data from being private to public, while remaining on the same domain. Then, the attacker can simply access the (now) public information to obtain the extracted data. It should be outlined that the technique requires two vulnerabilities: a web resources that is not protected by the X-Frame-Options (or uses a weak frame-busting code) and a site's functionality that is affected by clickjacking.
The following list summarizes a series of functionalities that could be abused to extract the sensitive data:
- Forum's post mechanism;
- "comment this item" functionalities;
- Public profile information updating function (or any "update function" that involves public available data - e.g. administrative functions that cause the updating of the web site's content);
- Messaging functionalities (e.g. from the victim to the attacker);
- The exploit frames both the vulnerable URL and the comment form of a attacker-chosen Amazon's book;
- The victim is triggered to drag his data and drop the information to the framed comment form;
- A clickjacking attack is then performed against the "Post" mechanism, in order to publish the dropped data;
- At that point the attacker can access all personal details by simply visualizing the submitted comment of the Amazon's item.
Update - media coverage: http://threatpost.com/chrome-clickjacking-vulnerability-could-expose-user-information-google-amazon-010213/77358