×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Facebook's URL Scanner Vulnerable To Cloaking Attack

timothy posted more than 2 years ago | from the spy-vs-jerk dept.

Facebook 34

Facebook's recent move to scan for malicious URLs sounded like a pretty good idea, but itwbennett writes with word that it's already been bypassed.'Hatter,' a member of hacking think-tank Blackhat Academy, provided a live demonstration, which involved posting the URL to a JPEG file on a wall. Facebook crawled the URL and added a thumbnail image to the wall post, however, clicking on its corresponding link actually redirected users to YouTube. This happened because the destination page was able to identify Facebook's original request and served a JPEG file. Earlier this week, Facebook signed a partnership with Websense to use the security vendor's cloud-based, real-time Web scanner for malicious URL detection. Blackhat Academy has now provided proof-of-concept code, which, according to its advisory, can be used to bypass it."

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

34 comments

First Post (0)

Anonymous Coward | more than 2 years ago | (#37650414)

How's this for a malicious link?

Re:First Post (1)

crazypip666 (930562) | more than 2 years ago | (#37650464)

Maybe Facebook should ask Slashdot what system they use, it seems to be working pretty well on your post.

Wrong system... (-1, Troll)

dev732 (2480226) | more than 2 years ago | (#37650572)

Of course if they give the website their user-agent, that is going to happen. They (and slashdot) should try this [evenweb.com] system instead.

Wait? (-1, Troll)

dev733 (2480228) | more than 2 years ago | (#37650582)

Of course if they give the website their user-agent, that is going to happen. They (and slashdot) should try this [evenweb.com] system instead.

Its because.... (-1, Troll)

dev734 (2480230) | more than 2 years ago | (#37650600)

Of course if they give the website their user-agent, that is going to happen. They (and slashdot) should try this [evenweb.com] system instead.

Wait? (-1, Troll)

dev735 (2480234) | more than 2 years ago | (#37650616)

Of course if they give the website their user-agent, that is going to happen. They (and slashdot) should try this [evenweb.com] system instead.

Breaking! Water is wet. (0)

Anonymous Coward | more than 2 years ago | (#37650622)

We get it: Malice always trumps good intentions. Is anyone here actually surprised? Who hasn't seen hotlink detection in action? That was common 10 years ago. This isn't new. It's just a new form of malice.

Come on editors; it's like you're not even trying anymore. Tell us something we don't all already know.

Wait? (-1, Troll)

dev736 (2480236) | more than 2 years ago | (#37650626)

Of course if they give the website their user-agent, that is going to happen. They (and slashdot) should try this [evenweb.com] system instead.

Wait? (-1, Troll)

dev738 (2480238) | more than 2 years ago | (#37650650)

Of course if they give the website their user-agent, that is going to happen. They (and slashdot) should try this [evenweb.com] system instead.

Irrelevant (2)

Sqr(twg) (2126054) | more than 2 years ago | (#37650676)

Yes, they managed to get facebook to use their image for a thumbnail. That says absolutely nothing about their ability to detect malicious links. (Rickrolling is not considerered a malicious link in this context.) The request for the thumbnail probably originated from facebook's own servers. The malicious link detection is comes from other IP addresses. TFA explains this.

Re:Irrelevant (1)

icebike (68054) | more than 2 years ago | (#37650904)

Well I hope TFA explains it better than TFS.

This happened because the destination page was able to identify Facebook's original request and served a JPEG file.

Lets see, click a thumbnail, got to the third party server, which does whatever the hell it wants to with your request.
Welcome to the intertubes.

Re:Irrelevant - You can use META TAGS! (2)

duguk (589689) | more than 2 years ago | (#37651366)

Well I hope TFA explains it better than TFS.

This happened because the destination page was able to identify Facebook's original request and served a JPEG file.

Lets see, click a thumbnail, got to the third party server, which does whatever the hell it wants to with your request. Welcome to the intertubes.

I also fail to see why this is a problem.

You can set the thumbnail with the "link rel='image_src'" tags!
Along with the title and description...

No need for any server side code; its all documented on OpenGraph [facebook.com].

Breaking news!!! (-1, Troll)

dev739 (2480240) | more than 2 years ago | (#37650678)

Of course if they give the website their user-agent, that is going to happen. They (and slashdot) should try this [evenweb.com] system instead.

Malicious URLs? No ALL (0)

Anonymous Coward | more than 2 years ago | (#37650788)

All links are considered malicious! And it says that facebook recommends you not to follow it. Even the most serious Norwegian web sites, government included.

Raising money for security research company (2, Funny)

Anonymous Coward | more than 2 years ago | (#37650814)

Guys, I've discovered that if you do


if ($certainUserAgent) {
  print 'Something;
} else {
  print 'Something else';
}

I'm going to start a security company, is anybody interested in hiring researchers for their operations. Corporate contracts start at $100,000.

OMG! (2)

Kaz Kylheku (1484) | more than 2 years ago | (#37650938)

You mean URL's can be verified, and then later have the indecency to point to something else?

Say it isn't so!

Re:OMG! (0)

Anonymous Coward | more than 2 years ago | (#37651072)

No, not verified. It works like this.

Check HTTP Request
If header includes facebook crawler string display image
Else redirect to another site

Re:OMG! (1)

Kaz Kylheku (1484) | more than 2 years ago | (#37651734)

What, wait a minute. You mean a HTTP server can parse the request and serve up different content based on who or what is calling?

*whistle*

Oh the implications!

Never mind Crapbook. Damn, you know, that gives me an AWESOME little idea. You could serve up slightly different code to, say, Explorer and Firefox, to get things to work right for different browsers!

Or here is something evil; bet nobody has thought of this one! We could present a normal looking page to regular users, but a one which is stuffed full of keywords to the Google search engine.

Re:OMG! (0)

Anonymous Coward | more than 2 years ago | (#37653932)

You mean URL's can be verified, and then later have the indecency to point to something else?

Say it isn't so!

You beat me to it. My post was going to be "Nah. GET OUTTA HERE. You're joking. Really? Wow. How much can I hire these security experts for TODAY?" :)

I think you're missing the point (0)

Anonymous Coward | more than 2 years ago | (#37651132)

Of course this is nothing surprising, or even new. There are only a few reasons you'd implement something this lame and call it a security enhancement. Money is one, and that explains Websense's motives. Lack of a proper clue is another, which goes nicely with Facebook's history. In Facebook's case, it may even be willful neglect. It's hard to believe that among all the developers at Facebook, they are all this dumb. How about it, Facebook technical staff? Were you even consulted on this? There again, it's hard to imagine competent techincal staff going along with some of the other horrors that have already been rolled out by Facebook too.

Seriously, there's a lot of money to be made here. And if you can sell snake oil as a cure-all, you'll rake some in. That likely applies to both Facebook and Websense.

I can only hope that the unwashed masses (which includes a fair number of /. devotees) wake up to the privacy implications of Twitbook-like sites soon because I'm sick of seeing their icons on nearly every web page. And that includes yours, /. Be among the first and remove that crap, please?

Uh... everyone on /. knows this... Goatse trolls? (0)

Anonymous Coward | more than 2 years ago | (#37651274)

Find or generate useful content (blog post, infographic, anything) relevant to the article at hand, host it on your own server, linkn to it in a post made within the first 5 minutes so it gets modded +3 informative or better, then replace it with hello.jpg. Isn't this one of the oldest tricks in the book, with only minor modification (changing the criteria for deciding which content to show from strictly time-based to the source IP and/or request headers?

I mean, I guess another demonstration never hurts, especially considering many people on the internet have never seen a goatse troll, and might not even know what one is... but I sure hope it's not "news" to anyone on /.

Too slow (1)

Animats (122034) | more than 2 years ago | (#37652126)

The trouble with "malicious URL scanners" that look for malware is that unless they're real-time, they're too late. The lifetime of bad sites is now often measured in hours.

Still, continually detecting the bad guys and beating on them does have effect. Major services have to do it, or they get pwned.

We do some tracking of major sites being exploited by phishers, [sitetruth.com] There are only 29 sites on the list today, one of the shortest lists we've had in years. It's been as high as 140. The URL-shortening sites get hit daily, and kick most of the bad guys off within hours. The free-hosting sites get hit too, and most of them are good about kicking the phishers off. (Piczo and webs.com are not too good at this. t35 has gotten much better. Google has a big problem with people using documents and spreadsheets as phishing sites.)

Eh Wot? (1)

Whiteox (919863) | more than 2 years ago | (#37652312)

How do you do that? I mean

posting the URL to a JPEG file

What do you have to do (and how)?

Another proof of concept (1)

Anal Surprise (178723) | more than 2 years ago | (#37652426)

A while back I actually wrote a tool for Rickrolling people several months ago:
http://brokenthings.org/
based on poisoned link redirection. It works well enough. The only way to avoid redirector tricks is to follow redirectors all the way to The Actual Page and then use *that* as the reference. Then, at least if the link is poisoned, it'll be obvious.

Re:Another proof of concept (1)

poofmeisterp (650750) | more than 2 years ago | (#37653958)

A while back I actually wrote a tool for Rickrolling people several months ago:
http://brokenthings.org/ [brokenthings.org]
based on poisoned link redirection. It works well enough. The only way to avoid redirector tricks is to follow redirectors all the way to The Actual Page and then use *that* as the reference. Then, at least if the link is poisoned, it'll be obvious.

Very good point. I believe that the entire point of FB doing this in the first place was to remove responsibility from their end.

<humor>
Not to use an overused and tacky quote, but, "Mission Accomplished."
</humor>

Websense URL Blocking? (1)

rathaven (1253420) | more than 2 years ago | (#37654826)

Interesting....

I was at a conference last week where the Facebook's malicious URL detection engine, which was stated by a Websense supplier as sourced by Facebook from Websense, was discussed. I remember using Websense years back as a URL filtering engine (which I believe it still is but with an improvement in deep inspection) and can see how Facebook have probably bolted it in so that traffic using redirects from their site get a layer of filtering before redirection from Websense's URL database and from the on the fly categorisation features, however, I can also see why there is still vulnerability. URL blockers, DPI engines and the like, like Websense, are tools that are always in development and are rarely anywhere near 100% accurate, instead, being aimed at giving an acceptable level of accuracy.

To be honest, I can't see that this vulnerability will be anywhere near the top of the list of vulnerabilities in tools like these. I'd be surprised if an unclassified (by the filtering engine) proxy couldn't redirect to wherever was required
Check for New Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...