Published using Google Docs
Clickjacking Attacks Unresolved
Updated automatically every 5 minutes

Clickjacking Attacks Unresolved

Lin-Shung Huang and Collin Jackson (Carnegie Mellon University)

Clickjacking attacks were originally described by Robert Hansen and Jeremiah Grossman in 2008 [1][2]. In these attacks, the attacker tricks the user into interacting with a malicious web page, but routes the user’s input to another web page that would result in undesirable consequences. A commonly used technique is to embed the targeted web page with a completely transparent IFRAME and lure the user to click on it unintentionally. There are plenty of known variants demonstrated by researchers, with or without JavaScript [3].

Clickjacking seems to have caught more attention since the exposure of widespread real-world exploits, including Tweetbomb [4] and Likejacking [5] worms. These attacks trick users to share malicious links to their friends, which quickly propagates across the social network. There are many potential consequences of clickjacking such as allowing click frauds or performing online payment, although the impact of these attacks in the wild is less clear. One concerning clickjacking PoC [6] allowed accessing the user’s webcam via Flash Player, fortunately this specific vulnerability has been fixed by Adobe.

Note that the security risks of transparent IFRAMEs have been discussed as early as 2002 [7]. However, disabling the transparency of cross domain IFRAMEs would break the functionality of some websites, yet still fail to prevent clickjacking attacks completely. Unarguably, designing a reliable clickjacking defense without breaking compatibility is non-trivial. Notably, Michal Zalewski offered some valuable insights on how browsers may help to prevent clickjacking [8], and ClearClick [9] can be used to provide automatic protection with some compatibility cost. The current solution for web pages to protect themselves is using JavaScript framekillers or the browser-enforced X-Frame-Options [10] to opt out of being framed. Given that framekillers may be circumvented [11] and X-Frame-Options has made its way into current major browsers (check Browserscope), the recommended defense for sensitive web pages is probably to deploy both.

However, popular web applications nowadays provide widgets (or social plugins, e.g. Facebook Like buttons) that are designed to be embedded by third party websites. It should be noted that previous solutions do not offer any protection for these widgets. Some attacks on widgets may even cause serious privacy implications. In the following sections, we first describe a practical de-anonymization attack on social network users, based on Likejacking. Then, we introduce a new type of click timing attack called double-clickjacking that can bypass current defenses and steal the user’s data from popular OAuth service providers. We would like to make clear that IFRAME-based defenses are ineffective. Moreover, clickjacking is not all about IFRAMEs.

Social Network User De-anonymization

Most users probably do not want to reveal their real identity when visiting random websites. We learned in Oakland 2010 [12] that it is feasible for a malicious website to uniquely identify 42% of the users in social networks that use groups based on browsing history leaks. Fortunately, the history sniffing technique required in their attack has been prohibited by major browsers thanks to David Baron’s fix [13]. However, we will explain how social network users can still be uniquely identified if they are tricked to perform a single click on a malicious website. We tested these attacks on all major browsers.

Facebook User De-anonymization

Facebook provides a Like button that can be embedded by third party websites and allows users to share content with friends and become a fan of a Facebook page with a single click. We already know that existing Likejacking worms can cause massive Like frauds, we further explore the possibility of websites using Likejacking to de-anonymize users in real-time. A web attacker who is an admin of a Facebook page and has his own server may craft a malicious web page to clickjack the Like button and fetch the user’s public profile.

Demo link: http://webperflab.com/david/like.html

Attack steps:

  1. Victim visits the attacker’s web page while logged in to Facebook.
  2. Victim clicks on the Facebook Like button that is hidden in a transparent IFRAME, and becomes a fan of the attacker’s Facebook page. (Up to this point, we are using techniques not much different from the existing Likejacking worms.)
  3. The attacker’s web page is notified when the victim clicks on the Like button via FB.Event.subscribe('edge.create', ...), triggering the attacker’s server to pull the fan list from his Facebook page and identify the newly added fan.
  4. The attacker’s server queries the user’s public profile via Facebook Graph API, and then removes the user from the fan list.

Twitter User De-anonymization

Analogously, Twitter provides a Follow button that can be embedded by third party websites and allows users to become a follower of a Twitter account with a single click. A web attacker who owns a Twitter account and has his own server may craft a malicious web page to clickjack the Follow button and fetch the user’s public profile.

Demo link: http://webperflab.com/david/follow.html

Attack steps:

  1. Victim visits the attacker’s web page while logged in to Twitter.
  2. Victim clicks on the Twitter Follow button hidden in a transparent IFRAME, and becomes a follower of the attacker’s Twitter account.
  3. The attacker’s web page is notified when the victim clicks on the Follow button via twttr.events.bind('follow', ...), triggering the attacker’s server to fetch the list of followers of his Twitter account and identify the newly added follower.
  4. The attacker’s server queries the user’s public profile, and then removes the user from the follower list using the Twitter API. Removing a follower is automated by blocking and then unblocking the follower.

OAuth User Data Theft via Double-clickjacking

OAuth allows users to share private resources (e.g. photos, contacts, email) from one application to another application without handing out credentials. In the OAuth protocol workflow, the service provider typically displays a page asking the user to approve allowing the third party application to access the user’s private data. The key point here is that the user needs to click on the approval button to allow sharing his private data. One can imagine the serious consequences if the OAuth approval page can be clickjacked. Attacks using transparent IFRAMEs have been described in 2009 [14]. Fortunately, OAuth service providers such as Google have deployed X-Frame-Options on the approval page, thus previous attacks do not work. However, we demonstrate a double-clickjacking attack that can circumvent existing clickjacking defenses.

Google OAuth

As mentioned, Google deploys X-Frame-Options on their OAuth approval pages. Although the attacker can no longer embed the approval page in an IFRAME, it is possible to load the approval page in a pop-under window. A pop-under window is a basically a popup window that is hidden behind the main browser window right after it was opened. Since modern browsers block popup windows unless triggered by user-initiated clicks, we require multiple clicks in this specific attack to bypass popup blockers. While our demo pulls data from the user’s Google contacts, a real attacker may also choose to read the user’s GMail messages. We tested the attack on current versions of 4 major browsers.

Demo link: http://webperflab.com/david/oauth.html

Attack steps:

  1. Victim visits the attacker’s web page while logged in to Google.

  1. Victim is tricked to make a single click on the page, which opens a pop-under window that loads the Google OAuth approval page. The pop-under window immediately hides itself into the background, using window focus and blur methods. (Assume that the user does not notice the popup window.) A fake button on the attacker’s page is created exactly at the same screen position of the OAuth approval button in the pop-under window. Accurate button positioning is possible given that the layout of the OAuth approval page is known and window screenX and pageX properties are provided.

  1. Victim is tricked to make a double-click on the fake button. The first click will bring the pop-under window into focus, while the second click will drop onto the OAuth approval button. (Assume that the user completes the double-click before noticing the popup window.)

  1. The attacker’s server can instantly fetch the user’s Google contacts using the approved OAuth access token.

What’s next?

We’ve been experimenting other types of click timing attacks that do not require double-clicking. Another focus of our work is to provide a reliable clickjacking defense for web applications.

References

[1] R. Hansen and J. Grossman, “Clickjacking,” 2008.

[2] R. Hansen, “Clickjacking Details,” 2008.

[3] E. Vela, “About CSS Attacks,” 2008.

[4] M. Mahemoff, “Explaining the “Don’t Click” Clickjacking Tweetbomb,” 2009.

[5] Wikipedia, “Likejacking,” 2011.

[6] G. Aharonovsky, “Malicious camera spying using ClickJacking,” 2008.

[7] J. Ruderman, “Bug 154957 - iframe content background defaults to transparent,” 2002.

[8] M. Zalewski,“[whatwg] Dealing with UI redress vulnerabilities inherent to the current web,” 2008.

[9] G. Maone, “Hello ClearClick, Goodbye Clickjacking!” 2008

[10] E. Lawrence, “IE8 Security Part VII: ClickJacking Defenses,” 2009.

[11] G. Rydstedt, E. Bursztein, D. Boneh, and C. Jackson, “Busting frame busting: a study of clickjacking vulnerabilities at popular sites,” in Web 2.0 Security and Privacy (W2SP), 2010.

[12] G. Wondracek, T. Holz, E. Kirda, and C. Kruegel, “A Practical Attack to De-Anonymize Social Network Users,” in Proceedings of the 31st IEEE Symposium on Security and Privacy, 2010.

[13] D. Baron, “Preventing attacks on a user's history through CSS :visited selectors,” 2010.

[14] S. Sclafani, “Clickjacking & OAuth,” 2009.