According to Microsoft, when it involves more than 1 click.

That’s the feedback I received when I recently submitted a Clickjacking bug to Microsoft’s Security team. This particular Clickjacking bug, on an authenticated portion of the site, could induce a victim to unknowingly change their account privacy settings. The problem, according to Microsoft, is that it requires a minimum of two clicks; one to change the privacy setting and one to save the change. I’ve had a hard time grasping this logic so I figured I’d share my thoughts and see what others think. Although Microsoft is adamant this is not considered a security vulnerability, I won’t reveal the exact site or settings. I will however provide some additional insight into the type of Clickjacking vulnerability, the POCs I submitted, and some of our back-and-forth communications to illustrate the differing opinions on what constitutes a Clickjacking attack.

For those not familiar with Clickjacking (aka UI redressing) I’ll spare any explanatory details as there are plenty of sites that already do a great job of it, including these: 1. SecTheory 2. OWASP and 3. Troy Hunt

The vulnerable Microsoft page I discovered is used to configure several user privacy settings, all of which can be modified by individual mouse clicks. The page is vulnerable because it does not employ an X-Frame-Options (XFO) header (or any other frame-busting code) to prevent framing. [Ironically Microsoft suggested the use of the XFO header back in 2009 in this MSDN blog and the Clickjacking attack example used by the author allowed for more than one mouse click!]

To illustrate how the Privacy Settings page could be exploited, I developed a very simple “game” in which the user has to click (“shoot”) a moving bulls-eye on the screen but instead of actually clicking the bulls-eye the user is actually clicking through an overlay to the framed vulnerable page and changing their Privacy settings in the process. I won’t take up space posting screenshots of this POC, but if you’re interested in how I implemented it, I’ve included a screenshot of some of the code below. Basically, I populated an array with the x-y coords of the privacy setting(s) I wanted to change and referenced that array to move the bulls-eye around the page. This is similar to the approach used by Jack, a UK-base security researcher, when he discovered Clickjacking on Etsy, though I rely a bit more on user interaction vs. timing to move the target around the page. I do this by detecting the user’s mouseover event which immediately changes the pointer-event of the bulls-eye div to “none” so that the user clicks through the bulls-eye and onto the vulnerable page. A second later, the pointer-event is changed back to “auto” (to detect the next mouseover) and the bulls-eye is moved to the next position.

I tested the POC many times and although one test resulted in a request for re-authentication and another resulted in an unexpected server error, the majority were successful in modifying the privacy settings via Clickjacking. I submitted the POC code and screenshots to Microsoft’s security team – letting them know that because the page in question does not implement XFO (or other defenses), it could be vulnerable to Clickjacking. I received the following in response:

A couple of things confused me about this response. First, was the reference to clicking “random places”. In a successful Clickjacking attack, the top-level overlay visually presented to the user is what is designed to trick them and remove the perception of “randomness”. If a user can be tricked into playing a game, submitting a form, or dragging an object from one side of the page to another, they will perceive their actions to be intentional rather than random. Second, while the Microsoft rep was correct in a sense that lack of XFO does not by itself constitute a Clickjacking vulnerability (you must also have something of interest to click on within the vulnerable page), it is a primary contributor/enabler. Thinking this might just be a misunderstanding of what Clickjacking is, my response was as follows:

To which I received the following response…

If this sounds somewhat familiar to you, it might be because another Security Researcher, Nikhil Kulkarni, discovered a Clickjacking vulnerability in Socl (a site owned by none other than Microsoft) and was informed that it was not a security issue–even after he submitted several POCs. Eventually Microsoft reconsidered Nikhil’s submission and declared it a vulnerability that warranted remediation.

Thinking maybe the perceived “randomness” of my initial POC game was to blame for the decision to disregard the issue, I developed a second, simplified POC. In this scenario the user is presented a static page that tells them they could win a free iPad just by submitting their email address (see a generic version of this POC below).

When the user clicks the check box, they are actually clicking through to the privacy setting (the mouseover event enables the click-through and a bit of timed JavaScript code actually clicks it for them) and the Submit button also allows for a click-through event to save the changes.

I submitted the second POC to Microsoft and received this response:

At this point I realized that no POC would change their minds if it involved more than one mouse click so that’s basically where we left it.

While I understand that a Clickjacking attack involving a single mouse click might be the most effective, any security professional that has studied social engineering or worked in an organization with more than a handful of employees will probably tell you that users can be tricked into almost anything—and it really doesn’t take too much effort. Your typical phishing email involves several steps, including reading a poorly worded message, clicking on a link to an unfamiliar external website, and submitting a web form that requests multiple pieces of personal information—and these are still incredibly effective. If successful phishing attacks have taught us anything, it’s that we don’t want to rely solely on user behavior for the prevention of Clickjacking or any other attacks.

If this is how Microsoft feels about a simple Clickjacking scenario involving two mouse clicks I’m curious how it feels about some of the advanced Clickjacking techniques that involve text and HTML source extraction, form spraying, drag & drop, etc (see here and here for some good examples).

In the end, each organization is going to have their own risk appetite but discounting a Clickjacking attack because it requires more than one click does not make sense to me. I think Microsoft just missed the boat on this one and I can’t think of any valid reason that could be preventing it from simply acknowledging the issue and implementing an XFO response header.

Thoughts?