I Know Your Name, and Probably a Whole Lot More (Deanonymization via Likejacking, Followjacking, etc.)

Building on the previous section, where we learned a variety of ways that http://maliciouswebsite/ can detect what other websites a browser is logged in to, we’ll move onto the next step — deanonymizing visitors. Deanonymization refers to a website like http://maliciouswebsite/ surreptitiously uncovering a visitor’s full real name. To accomplish this requires only a little bit more than the passive data gathering we’ve seen in other sections: a single mouse-click from the visitor is necessary, utilizing a now common attack technique called “Clickjacking.”

For those unfamiliar with basic concept of Clickjacking, this is a browser-based attack technique first coined by Robert Hansen and myself back in 2008. Essentially a website places an invisible object, typically an IFRAME, over something a visitor is likely to click on, such as a link or an image. When the visitor clicks on something they visually see, they are instead tricked into clicking on something the website wanted them to. To demonstrate the power of Clickjacking, the first demonstration of the attack technique silently activated a computer’s camera and microphone.  Scary.

In the years since, various implementations of Clickjacking have been created for other purposes, including deanonymizationCollin JacksonEric Y. Chen, and David Lin-Shung Huang have done excellent work in this area.

[youtube]http://youtu.be/gNpRIZ9IWEs[/youtube]

When a website wants to obtain a visitor’s full name via Clickjacking, it first has to make a guess as to what other websites will already have that data. And since we’ve just covered Login Detection, we have to look no further than social networks such as Facebook, Twitter, Google, and LinkedIn. They will have a person’s full name, and probably a whole lot more!

How can http://maliciouswebsite/ get one of the aforementioned social networks to give up a person’s name and other personal data? Facebook’s “Like” button, Twitter’s “Follow” button, Google’s “+1” button, and LinkedIn’s “Follow” button can do exactly that! And because there are so many options to choose from, Login Detection is incredibly useful. Obviously it doesn’t make sense for http://maliciouswebsite/ to serve up a Like button to a browser not currently logged-in to Facebook.

Deanonymization via [Facebook] Likejacking

This is where I humbly disagree with the general consensus on Stackoverflow. It is absolutely possible to tell who on Facebook clicked the Like button. Being able to do so is the crux of an attack called “Likejacking,” a specific implementation of Clickjacking. In a nutshell, the Likejacking attack flow is as follows:

1)  A browser visits http://maliciouswebsite/

2)  http://maliciouswebsite/ detects that the browser is logged in to Facebook and dynamically serves up a specially crafted Like button. The Like button’s URL points to a Facebook page created ahead of time by http://maliciouswebsite/– something like: https://facebook/deanonymize

3)  When the visitor [mistakenly] clicks the Like button, http://maliciouswebsite/ immediately checks to see who is at the top of the Facebook page’s fan list and obtains the URL to their profile. That person is most likely who just clicked the Like button.

4)  Once http://maliciouswebsite/ has the person’s profile URL, they can easily obtain all their publicly available Facebook information. This information will undoubtedly show their full name, but also depending on their privacy settings, it could also include where they live, where they grew up, where they work, where they went to school, interests, list of friends, pictures, and so on.

From the visitor’s perspective, everything happens invisibly and with just a single mouse-click.


Deanonymization via [Twitter] Followjacking

The attack flow for Clickjacking Twitter Follow buttons, Followjacking, is very similar to that of Likejacking, only a bit easier. In Followjacking http://maliciouswebsite/ only has to dynamically create Follow buttons configured with Twitter accounts. In fact, http://maliciouswebsite/ does not even have to control these Twitter accounts; they can use whatever account they want! Here is the Followjacking attack flow:

 

1)  A browser visits http://maliciouswebsite/

2)  http://maliciouswebsite/ detects that the browser is logged in to Twitter and dynamically serves up a specially crafted Follow button. The Follow button is configured to Follow essentially any Twitter account http://maliciouswebsite/ chooses.

3)  When the visitor [mistakenly] clicks the Follow button, http://maliciouswebsite/ immediately checks to see who is at the top of the Twitter account’s followers page (i.e. https://twitter.com/jeremiahg/followers) and obtains the URL to their profile. That person is most likely who just clicked the Follow button.

4)  Once http://maliciouswebsite/ has the person’s Twitter profile URL, they then can easily obtain all their publicly available Twitter information. Most often this information will include their full name, along with whatever is in their profile description. Some people post pictures, check-ins, and other interesting personal information to their tweet stream.

 

By now it should be clear that this style of attack can be extended to LinkedIn, Google+, and other online services providing similar functionality. That list is quite long.

I would like to reiterate a key lesson and highlight a new one.

  • If a browser is logged-in to a social network or similar identity storage website, as many are persistently, a single-mouse click is all it takes for any website to reveal a visitor’s real name and other personal information.
  • If the browser happens to have the popular Tor proxy installed, it does not provide any protection against deanonymization via Likejacking and Followjacking.

Can we actually call this clickjacking -> deanonymization issue a “vulnerability?” If so, who is responsible for dealing with it? The browser vendors? The logged-in visitor? The social networking website(s)? The Web standards bodies? This discussion goes well beyond the scope of their blog series, so I’ll leave it as a thought exercise for the reader.

 

I Know…

This entry was posted in Web Application Security on by .

About Jeremiah Grossman

Jeremiah Grossman is the Founder and interim CEO of WhiteHat Security, where he is responsible for Web security R&D and industry outreach. Over the last decade, Jeremiah has written dozens of articles, white papers, and is a published author. His work has been featured in the Wall Street Journal, Forbes, NY Times and hundreds of other media outlets around the world. As a well-known security expert and industry veteran, Jeremiah has been a guest speaker on six continents at hundreds of events including TED, BlackHat Briefings, RSA, SANS, and others. He has been invited to guest lecture at top universities such as UC Berkeley, Stanford, Harvard, UoW Madison, and UCLA. Jeremiah is also a co-founder of the Web Application Security Consortium (WASC) and previously named one of InfoWorld's Top 25 CTOs. He serves on the advisory board of two hot start-ups, Risk I/O and SD Elements, and is a Brazilian Jiu-Jitsu Black Belt. Before founding WhiteHat, he was an information security officer at Yahoo! Jeremiah can be found on Twitter @jeremiahg.