Hacker News new | past | comments | ask | show | jobs | submit login
Ingenious Hack by Facebook Spammers: Smoking Hot Bartenders (liquidrhymes.com)
176 points by jgv on Aug 27, 2010 | hide | past | favorite | 61 comments



It's clickjacking. That was 2008. This is clickjacking with a like button. I wrote about it in early June ( http://www.h-i-r.net/2010/06/viral-like-jacking-on-facebook.... ) and it was already somewhat old-hat by then. In fact, I think I covered the same technical details this person did.

It's not really ingenious. It's just scammy behavior and yet another fine reason to run NoScript.


NoScript isn't a good solution and certainly not a scalable one - most people don't want to browse without js.

It'd be better for browser makers to simply detect clickjacking and block it.

If an element isn't visible to the user (either partially visible or behind other elements), that's probably a good sign it shouldn't be able to receive user actions such as clicks. Especially if it's an iframe.

I hope firefox+chrome do some work on this soon.


NoScript is a specific Firefox extension, not general advice to turn off Javascript. NoScript lets you whitelist trusted Javascript, so when you visit that spam site, its Javascript doesn't run. Meanwhile, when you visit omg-animated-lolcats-yay.com, you notice that the lolcats aren't omg-animated, so you click one button to whitelist the Javascript, and then you get your omg-animated-lolcats forever. Yay!


>> "so you click one button to whitelist the Javascript"

It's amazing how quickly 'click one button to be able to view this website' would irritate the hell out of anyone.

It's certainly an option for geeks or security freakouts, but not really an option for normal people.

Also how would a 'normal' person decide if a website is 'safe' to enable js or not? If you're the kind of person fooled into clicking for 'hot bartenders' and filling out a survey to get access, you're probably not able to decide if you should enable js or not.

The solution isn't to shift responsibility to users, it's to fix the browser flaws that allow clickjacking to happen.

The example given here should be a textbook easy to fix bug in browsers. It's a browser issue which should be high priority.

An iframe which isn't visible to the user, should not be able to receive input from the user.


> It's amazing how quickly 'click one button to be able to view this website' would irritate the hell out of anyone.

Back when I experimented with manually authorizing cookies on all websites I visited, it was surprising how quickly the number of cookie prompts dropped to near-zero. There really aren't that many websites that you visit.


What software did you use for this? I have tried a few cookie blocking extensions for Firefox but haven't found a good one.

Also I notice you say "Back when I experimented.." -- was there a reason it didn't work out in the end?


I was using Konqueror then. The experiment ended when I got another computer or something.


If it's so easy to fix, fix it?


I don't think it's technically hard to fix at all. I think the more likely issue is that it may break badly coded websites that do stupid stuff. Chrome+Firefox should definitely do it though.

You can't really just cop-out that if something is open source then it's not fair game for criticism. Firefox has some big bugs open for months before they get worked on.

To prevent the example cited from working would likely take 10-20 lines of code in webkit/firefox. But it'd likely take a week or so to get up to speed with the project to be able to know where to insert those lines of code. Fixing other methods of hiding an iframe would likely take a bit more thought, but it's hardly rocket science.

I have enough to do without fixing browsers ;)


Firefox has some big bugs open for months before they get worked on.

I have enough to do without fixing browsers.

You explained your own observation.

You can't really just cop-out that if something is open source then it's not fair game for criticism.

Open Source is certainly "fair game for criticism". But you aren't going to get anything out of criticism, because criticism cannot write any code. Open Source is all about people seeing a problem, fixing the problem, and sharing the fix. Nothing more. And it certainly has no obligation to a user who is quick to criticize but slow to fix.

It's the software engineering equivalent of yelling at the TV when the news makes you mad. It's pointless and makes you look insane.


I disagree. For the people working on webkit, the fix is probably an hours work.

For me, it'd likely be a week to get up to speed with the project. So it's more efficient for me, and other users not familiar with the codebase to yell at the developers for a day or two and see if they'll fix it.

I know in open source utopia everyone seamlessly just hops into other projects, fixes a bug, says 'here you go! bye for now', and carries on to the next project, but that doesn't happen in real life.

Who knows though, maybe I'm wrong. Maybe there's a really good reason they allow clickjacking. But I certainly can't see one.


NoScript has click-jacking protection, some XSS protection, and some other things. You could theoretically run it with those things on, but no scripting disabled.

I don't know how good the click-jacking or XSS protection is. For me it has always been a false positive, and usually very quickly fixed and ack'ed in the changelog, and otherwise, I really don't browse the web in such a way that I'm routinely encountering such things. (Plus I do use it with scripting off, so anything like a malicious script to further trigger an XSS elsewhere won't work on me.)

But even if you don't want the script blocking, it can be useful.

(And as others have observed, it is less annoying that you might initially guesstimate. I use it on two machines with no configuration sync'ing, and it still isn't annoying to me.)


tangentially related: I do not know if people have figured this out yet: liking something gives them permission to write to your status feed. I think after that gets widely understood people will be less promiscuous with the thumbs up, because it will be associated with being spammed to heck.

I have done this to myself, incidentally, because I did not believe the doc tha said it was possible.

If you include Open Graph tags on your Web page, your page becomes equivalent to a Facebook page. This means when a user clicks a Like button on your page, a connection is made between your page and the user. Your page will appear in the "Likes and Interests" section of the user's profile, and you have the ability to publish updates to the user. Your page will show up in same places that Facebook pages show up around the site (e.g. search), and you can target ads to people who like your content.


Worse yet, if your friends like something or run an app, they can get to your personal information because your friend has endorsed something.

This means either cutting your friends out of your private data, selecting your friends based on their computer savvy, or being as vulnerable as the most insecure of them.

I say again: Facebook is the devil. It's a brilliant platform that should continue to grow for years. It uses your own friends to make you do things you would not normally do (like join). As a platform it has no other goal than total domination of the net.


Simply liking something does not let a developer get access to your friend list. You will have to give the app at least basic permission (aka "run/install", which will share your friend names and uids) or extended permissions will get you friend's feed, statuses,birthdays, contact details etc. But extended perms have really poor conversions, so most spammers don't go that far.

Only a matter of time before that gets clickjacked though.


Can you link to the Facebook developer docs for this? I've been playing with their api and haven't seen anything like this, just getting name and uid of friends. Not saying your wrong, just curious.


"... Worse yet, if your friends like something or run an app, they can get to your personal information because your friend has endorsed something. ..."

Most don't understand this. It's a royal pain. Read through this article by PJF, "Facebook privacy - Instant personalisation and connections" ~ http://pjf.id.au/blog/?position=604


If you have any personal information that you're uncomfortable with the outside world knowing, don't put it on Facebook.


From your description in another comment, it seems like you've used 'status feed' when the more appropriate term is 'news feed.' As far as I can tell you're not saying that the companies can post public statuses; you're saying they show up in your personal news feed. There's a big difference.

Correct me if I'm wrong.


I don't speak the Engrish, sorry. It is whatever you call the big freaking div where Aunt Sally discovered a FarmVille cow and wants to share.


As always with Facebook, if you put in a bit of effort those things can be hidden from view forever.

Mouse-over the big freaking div, click on the little cross on its top right, and choose "Hide FarmVille" or "Hide Mafia Wars" or "Hide Doomaflotchie Widget", and you'll never see any updates from the damn thing again. Across computers. Which makes it better than Greasemonkey scripts or browser addons.


I've been through the Facebook API docs many times and don't recall reading about this.

If thats true it really needs to be better communicated by Facebook.


I had your reaction. Trust me on this, it works. I would tell you to like BCC so that I can spam you to prove it, but I took off my like buttons right after figuring it out. I thought it was a huge violation of my users' expectations, which I had been explaining as "Like this and your friends on Facebook will see it."


Make a bookmarklet with this code:

  javascript:(function(){try{var%20url=encodeURIComponent(location.href);var%20ifr=document.createElement('iframe');ifr.style.position='absolute';ifr.style.top=10+'px';ifr.style.left=10+'px';ifr.style.width=450+'px';ifr.style.height=100+'px';ifr.style.border='none';ifr.src='http://www.facebook.com/plugins/like.php?href='+url+'&show_faces=true&width=450&action=like&colorscheme=light';ifr.scrolling='no';ifr.frameborder=0;document.getElementsByTagName('body')[0].appendChild(ifr);}catch(e){}})();
Then you can visit any webpage and "like" it.


I can confirm too. A few months ago when Facebook pushed to convert everybody's "likes & interests" into "Like <page>" things, I initially agreed to it, to see what happened. What started happening was that my News Feed began to fill up with spammy events/messages being pushed out from all the things I Like-d. Bands, movies, books, TV shows, etc. The problem was it became much harder to see "real" events/activities from the people I was connected to, friends and coworkers, etc. So I went in and de-Liked all of it.


I think the confusion centers around the phrase "liking something gives them permission to write to your status feed." I first read that as "liking something gives them permission to publish updates as you." Which is similar to how some apps will get permission to publish as you, but what I believe the author means, is that liking will let the liked page publish their own updates, and you will see them in your personal feed.


Ever since a facebook widget showed the names of a bunch of people I know on the right-hand side of an unrelated website I've stopped going there. I logged out of facebook and I haven't logged in since then. I'd much prefer it if they stayed within their 'boundaries of expected online territory', and to see them popping up on sites that I normally visit but that I do not associate with facebook at all was enough to push me over the edge.

I'm sure that plenty of people couldn't care less, but I think it's a creepy thing.


Clickjacking (the name of this exploit) is one reason many sites have frame-busting JavaScript.

Of course the whole point of the Facebook "Like" button is to be embedded on other websites, so frame busting is out of the question. I'm not sure if there's a quick fix for this. Browsers need to disallow clicking of transparent iframes.


I got p0wned earlier today by the same sort of chat-bot/spam exploit I've been seeing from some of my friends.

As a Chrome user on Linux, and a pretty much lifelong user of Linux on the desktop, I am rather unaccustomed to being the victim of such exploits, so I didn't immediately know what to do. This one appears to be purely browser/JS-based and/or perhaps exploits some weakness in the Facebook API.

It started when a (presumably "infected") friend of mine posted on my wall. It looked to be just text, but presumably contained a trigger for this exploit. Anyway, within seconds, somehow, unbeknownst to me, I was apparently initiating chat conversations with every friend who was online "asking," "Do you have a second?" When they would reply "yes?", I would blast them with some bullshit quiz/test site link, which I can only assume is a phishing farm.

Anyway, this continued relentlessly so long as I was logged into the site (and possibly when I wasn't, never definitively established that) until it occurred to me to change my Facebook account password, after which it - knock on wood - seems to have stopped.

Does anyone have any idea how this exploit works? It caught me rather off-guard because I expected that sort of thing to be the work of viruses and/or malware on Windows. I would guess that my password was somehow phished out, after which some foreign agent logged into the Facebook messenger as me externally (quite possible to do, numerous IM clients now support the Facebook messenger protocol) and went nuts, but I can't be sure.


It sounds like a script injection, but that would be a pretty big flaw in FB and 1) Would spread pretty fast 2) Would be picked up by FB pretty quickly as well.


We've seen this kind of scammy stuff before, where people overlay a transparent div on top of another div. This is the first time that I've seen them attach to the cursor and follow it around.

Other than keeping your browser logged out of facebook at all times, what's the protection against this?


The only possible protection that I can think of would be for Facebook to require confirmation when someone likes a page. Essentially it would redirect the user to Facebook where they would see a page that says "Are you sure you want to like ______?" Then, after they agreed, it would redirect them back to the original site. However, this would be highly undesirable for people who use the Facebook like button, because it could siphon away potentially valuable visitors who appreciated the site enough to like it.

Another option might be for Facebook to ban likes on a domain basis. If a domain is using spammy techniques like this then ban it from being liked by anyone. Of course that means more overhead and moderation.

I don't think there is a good solution to this, only work arounds.


Facebook already does ban on a domain basis, but of course that's not a fix at all. These things are "viral" by the nature of the Like button since it posts on the user's wall automatically, so it's very easy for the "spammer" to make a new domain and get going again very quickly.

The easiest fix to the spreading of this issue is FB not broadcasting every single time you like something... but they're not gonna do that, we already know. So, the spam will continue.


What about forcing embedding sites to load a FB JS file, such that a standard Facebook confirm dialog pops up? This way the user doesn't navigate away from the site but some level of confirmation is made.


If the dialog pops up and is not within an <iframe>, then the page can simulate a click on the confirm button. Even if the JS library uses an <iframe>, it can always be reverse engineered to not use one, and the user won't know because iframes are not obvious to the user. The way above, where a new page is opened with the Facebook URL clearly displayed in the browser address bar, is the only way for Facebook to ensure that likes are legit short of putting CAPTCHA's next to the like buttons. Oh, and users never check the address bar anyway.


I don't see how reverse engineering to not use an iframe would help. Presumably Facebook would have some type of check on the iframed like page that ensures that the request is actually coming from FB. How would an attacker recreate an iframed page they don't have access to?


Subdomains and DNS mods with a proxy?


It'd be trivial to modify js behavior before the FB JS file loads.

For example...

window.confirm = function(m) { return true; }


Perhaps a batch confirmation once a week on facebook; "likes" don't become active until you look through a list of likes from the last seven days and ok them? Most of that sort of thing isn't very time-sensitive.


Here's one: stop using facebook.


With imagemaps, there's no longer a legitimate reason to ever need to "click" on something that's transparent. Therefore, the browser should not allow objects that are not visible to receive "click" events.


I actually use this trick for good, not evil. It's a way of styling certain unstyleable elements in old browsers. But you have a point -- it's useless in modern browsers. That said, what is the standard? Is 5% enough?


Maybe we need fractional clicks. If you click on a 0% opaque button then you don't get a click. If it's 1% opaque, then you get 1% of a click event. :-)

Actaully... I started writing that as a joke but now that I think about it, if the browser embedded the opacity value of the clicked element in the GET or POST header, the webserver receiving the click could set the standard themselves.

Alternately, since facebook has lots of resources, facebook could make a request to the referring site themselves, render the page and determine if there are any shenanigans going on with z-ordering or opacity automatically. You could look at all of the css applied to all of the element affecting those pixels.

No... this is all crazy. Just pick a value like 30% and disallow clicks on anything less.


What about visibility: hidden?

What about background: transparent?

What about background: url(transparent.png)?

What about background: data:encoded-transparent-image...

Even browser-side "visibility" calculations can become an AI-level problem quickly.


There is an easy solution to the AI calculation though.

Anything not proven visible counts as invisible. Done!


Anything not "proven invisible"? So... any text on any image background? Any colored text on any background? (white text on white background...)


what's the protection against this?

Well, you could open these links in an Incognito window which doesn't have access to your Facebook cookies.

Obviously this solution doesn't scale to normal users.


This somewhat demonstrates why GET isn't supposed to be used to change server state. Somewhat.


Not particularly. If Facebook used POST internally to implement the Like button, the result would be the exact same.


Note the double use of "somewhat". They'd need to put the form to be POSTed on a page of their control that the browser would GET after clinking a simple link in the form a a "like" button.


It's because of crap like this that I only browse sites like Facebook from a secondary browser, Chrome in my case. On Firefox, I'm not even logged in to Facebook, to minimize the amount they can learn about me with their Like stuff.


Likewise, I only check Facbeook on my phone. There are some exceptions but I always use Incognito mode for those.


The question I have is how do these guys plan to make money off this scam? There doesn't seem to be any ads on this page or any affiliate pages.


lol no one knows? that's fishy


This has been a known vulnerability since at least July 13. Interactive demos: http://erickerr.com/like-clickjacking

This would appear to be (among?) the first malicious use of the like-jacking vulnerability.


If that matches your definition of malicious you've led a protected life style!


A few of these have been floating around for at least the past couple months. One of my friends clicked through and ended up "liking" some picture of a stupid tattoo, and earned an educational lecture from me as his reward.


I actually clicked on the page, following my girlfriend Facebook.

But I was protected due to the ever useful Adblock extension. Probably the best plugin out there, the easiest method to fire and forget about annoying web elements.


Agree there! When the like button started spawning everywhere, I consulted the internal annoy-o-meter and determined that the best solution would be to block the button.


I avoid this by keeping my core apps in Chrome/Chromium and by browsing everything else with Firefox+NoScript+ABP.


And the slippery slope begins...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: