With Facebook Privacy, Everyone Means Everyone

“Security through obscurity” refers to the idea that content can be kept safe by making it hard to find rather than inaccessible without authorization. Many photo hosting sites use complicated URIs for uploaded pictures, making it very unlikely anyone would simply stumble across a particular picture by entering a random address. End users may think such a setup is reliable enough to keep their content private.

However, security researchers routinely criticize the notion that obscurity provides much security at all. Hidden content is often more easily found than people may suspect. Even if finding the content may not seem obvious, tricks often exist to work around a system’s obscurity and gain even targeted access to resources.

Case in point: Facebook’s photo albums. For years, the default level of access on new albums has been “Everyone.” Up until this week, many Facebook users apparently paid little attention to their privacy settings, and while someone could theoretically access a public photo album, the likelihood of someone guessing a legitimate album ID for a particular user seemed remote. Although many people (including this blogger) had pointed out that albums could be accessed given the file name of one photo within the album, that still required more knowledge than most would-be photo hunters would have.

But as Facebook has rolled out their new privacy model (a story I’ve not covered here as it’s been well documented elsewhere, and I’ve been posting relevant links on my Twitter), users are suddenly taking note of who can access what on their profiles. In an ironic turn of events, Mark Zuckerberg’s personal photo albums became easily accessible after the privacy switch. It’s likely Zuckerberg had set his albums to “Everyone,” but until now the list of albums was not included on someone’s profile unless you were their friend.

In the past, developers used Facebook’s API to access public albums for non-friends, but Facebook shut off that functionality. After the Zuckerberg story, Facebook apparently removed users’ photo album lists from the profiles of non-friends, once again resorting to a security through obscurity approach.

Once again, though, the new behavior has a simple workaround. Create a new web page and insert an inline frame with this URI: http://www.facebook.com/ajax/profile/tab.php?id=USERID&v=photos&iframe=true Replace the “USERID” part with a Facebook user’s ID number. Load your page and view the source of the iframe. You’ll see a block of HTML encoded within some JavaScript, and embedded in that HTML are links to the user’s photo albums that you can access. Note that loading the Facebook URI directly will not work – you must use an iframe.

I have no problems posting this as I’m not foiling any of a user’s privacy settings or somehow working around Facebook’s access restrictions. This trick only exposes albums that you can access based on the albums’ privacy settings. Of course, many Facebook users may be surprised to see which of their albums can be accessed by non-friends this way.

The lesson here is that on Facebook, “Everyone” really does mean everyone. Take the time to check all of your privacy settings and make sure nothing is set to “Everyone” that you wouldn’t want the entire Internet to see.

In fact, many would argue that you shouldn’t post anything on Facebook that you don’t want the entire Internet to see, since despite Facebook’s many privacy settings, much of your content has long been accessible via Facebook applications – and security issues with applications are well-documented.

Does that mean you should never use Facebook? At some point, we have to live our lives, and that always includes risks. The key is awareness – think about what you’re posting, understand the ramifications of your privacy settings, and stay current with changes in online security and privacy. Those steps are some of the most important in protecting your identity.

Update: As with API access before, Facebook issued a patch some time in the last five hours that blocks the trick I described for accessing public albums. Honestly, this doesn’t make much sense, since the albums are marked for “everyone.” If anything, it trains users to rely on security through obscurity.

Amusingly enough, while Mark Zuckerberg’s albums are still accessible by URI (according to reports, he made them public on purpose), some of the other Facebook employee albums that I had previously accessed are now inaccessible – meaning the album owner may have been trusting in security through obscurity until now as well.

Update 2 (12/15): At present, a slight adjustment to my previously posted trick once again enables access to a user’s public albums. Adding the parameter &__a=1 to the end of the old URI once again loads the album links (e.g. http://www.facebook.com/ajax/profile/tab.php?id=4&v=photos&iframe=true&__a=1 for Mark Zuckerberg’s albums). The parameter &sb= can be used to access multiple pages of albums (“sb” seems to be set to multiples of 4 or 5). Please note that you still need to use the iframe setup I described earlier. Anyone interested in further details or a demonstration can e-mail theharmonyguy via Gmail.

Keep in mind Facebook may block this version of the trick at any time. However, as I noted before, this only provides access to albums which users have marked as being for “everyone,” and thus should not even be required in the first place. If Facebook truly wants to make sharing content easier, why not simply provide a list of public photo albums on a user’s profile? The issue here is not a problem of privacy, but user expectations. Facebook has trained users to accept default settings on photo albums while thinking they’re not easily accessible. Making the albums hard to find gives an illusion of privacy and only delays any rude awakenings that may come from users who have inadvertently shared private photos.

Update 3: I may have spoken too soon last week; I just tried using the URI without &__a=1 and it still worked. Perhaps there was simply a glitch before when I thought the trick had been blocked.

Facebook Instapaper Twitter Digg FriendFeed Delicious Google Bookmarks Yahoo Bookmarks Share/Bookmark

Facebook Privacy & Security Guide v2.0: Updated with New Privacy Changes

I have updated and released version 2.0 of the popular Facebook Privacy & Security Guide.  Version 2.0 reflects the recent changes that Facebook made to it’s privacy settings.  In addition, I added a new section titled “Blocking and Creating Friend Lists” and expanded on how your Name, Profile Picture, Gender, Current City, Networks, Friend List, and Pages are now publicly available information.

Download the new version of the Facebook Privacy & Security Guide here.
You can also get to the guide from: socialmediasecurit… and from the top of Socialmediasecurity.com under “Guides”.

Can you remove public access to your friend list?
One tip I didn’t have room for in the guide around these new changes is the following.  You can remove the ability for your “Friend List” to be viewed in public searches by selecting the Edit “pencil” in the Friends box on your profile page and unchecking the box.  Here is a screen shot of this.  Unfortunately, this control is all or nothing but the good news is your Friends can still see your friends list.  You may also want review your application settings so application “boxes” are not showing on your public profile as well.  More information can be found on Facebook’s blog post about these issues (hat tip to @mubix for pointing this out).

Like before please send any feedback on the guide to feedback[ aT ]socialmediasecurity.com.  The companion video is being worked and should be up shortly as well.

New Facebook Privacy Settings: For Better or For Worse?

Everyone has probably already heard that Facebook rolled out new privacy settings today.  If you haven’t seen them or gotten the following pop-up box on login…you will soon:

message1

There are a great deal of articles already out about how this is such a great improvement and how these new settings give you more control over your privacy.  However, I would argue that these settings may possibly open up more issues then they are trying to prevent.  The best article on the new settings and the privacy implications is the one that the Electronic Frontier Foundation (EFF) released today titled: Facebook’s New Privacy Changes: The Good, The Bad, and The Ugly.  I recommend everyone (no pun intended) read this article as it provides much more detail then I will provide in this post.

What I want to do is provide you with a summary of the good and the bad of the new privacy settings.  I also want to give a security professional’s point of view on these settings.  As a penetration tester I can tell you that my job just got way easier!  You may have read my series on Enterprise Open Source Intelligence Gathering in which I tell you how you can find information on social networks about your company and employees.  Well, searching for information on Facebook just got easier thanks to status updates being available using new technology like Google Real-time Search!  Ok, on to the better and the worse!

The Better?

  • The new way privacy settings are “managed” is a good thing.  It’s easier to find and navigate through the settings.
  • I like that they ask you for your password to change privacy settings.  It’s just another layer.  Now, this doesn’t help much if you have a keylogger installed but it seems they put this in to prevent bots that may have taken over your account access to your settings.  Again, not fool proof but another layer.
  • The ability to fully customize privacy settings on all the content you post.  So for example, you can specify if you want everyone on the Internet to view your status updates (more on that in a minute) or Friends, Friends of Friends and Custom.
  • Users are now somewhat “forced” to check out their privacy settings.  It’s more accessible that’s for sure.

The Worse?

  • Your Name, Profile Picture, Gender, Current City, Networks, Friend List, and Pages are all available to be viewed by EVERYONE on Facebook! You cannot change these settings at all.  Note, there is a way to remove your entire Friends List from your profile but it’s all or nothing!  Here is a screen shot of this. You have to set it in your profile page using the “edit” button and check the box.These changes are quite disturbing considering that you used to be able to restrict this type of information.  I really believe that Facebook has done this on purpose so *more* information is being shared about you while stating “enhanced” more granular privacy settings.  If you have been to one of my talks in the past I always mention that social networks need to find ways to make money.  The way they make money is off of the information you share!  If you don’t get a choice about the basic information anymore…that’s more money in their pocket at the expense of your privacy.
  • What about the security ramifications of this? It opens up a whole new world for cyberstalking, predators and other attackers.  If you were someone that didn’t feel comfortable sharing this information in the first place, your choice is gone.  Sure, you can lock down your profile so no one can search for you but if you do that…why are you on Facebook to begin with?  You *have* to let your real friends search for you at some point!
  • By default Facebook “suggests” that you set your status updates to “Everyone”.  Here is the thing with status updates….Everyone means everyone on the Internet!  This is where new technology like Google RTS comes into play.  Imagine how easy it will be to find the latest information on “Tiger Woods” or now everything YOU are saying on Facebook, Twitter and other social networks.  Enter in some social engineering and things just got easier for attackers looking to use you or your information (which is easy to figure out now that I can see your friends, and things that interest you via the pages your a fan of).
  • Lastly, Facebook removed the ability to prevent Facebook applications your friends installed from pulling your “public” information.  That option is now gone and applications that your friends install can now view your “public” info.  Remember kids, “public” info is now: Your Name, Profile Picture, Gender, Current City, Networks, Friend List, and Pages.

One final note…be sure to double check all your privacy settings after you run the wizard.  I found a few settings that reverted back to settings I never had.  So what are your thoughts?  Will this make you lock your profile down more?  Do you care?  Is privacy dead anyway? Will Zombies destroy us all? :-)

Share and Enjoy


FacebookTwitterDeliciousDiggStumbleUponAdd to favoritesEmailRSS


Security in Syndicated and Federated Systems

In an amusing story earlier this year, a technology news reporter writing on a particular security problem unwittingly demonstrated the issue by publishing an article. ReadWriteWeb posted a story on cross-site scripting holes on McAfee’s web site, and the article included some sample code that could be used in an attack. Unfortunately, the New York Times syndicates some articles from RWW, including this one on XSS, and at the time did not filter code in RWW reports. Consequently, the sample code actually rendered in the New York Times version of the article, producing another example of cross-site scripting.

In broad strokes, a syndicated system occurs when one application or network loads content from another (one-way) while a federated system involves two applications or networks exchanging content in a fully interoperable fashion (two-way). RSS is a syndicated setup – your reader simply loads an XML feed from the site you subscribe to. E-mail is a federated system – many SMTP servers exchange messages with each other.

Both syndicated and federated systems have to deal with a potential security problem: outside content. Any time you load data (particualrly in a web application) that’s not under your control, you need to put in filters to avoid such issues as cross-site scripting. The problem here is not a matter of trust – I’m sure the New York Times considered ReadWriteWeb a trusted source. The problem is that other sources of content may not always provide what your application is expecting. Rather than assume the data’s formatted and encoded correctly, assume it’s not and take appropriate action. This is merely one example of the type of thinking security researchers routinely employ – and a mindset developers need to use more often.

I recently came across another minor example of syndication leading to XSS. The search engine Cuil recently announced that they were launching an opt-in feature to index the posts of your friends on Facebook and include those posts in your search results. Aside from the privacy ramifications (you may be surprised to learn that settings for uninstalled apps and Facebook Connect sites don’t seem to apply to Cuil’s search results), I wondered how secure Cuil’s implementation would be in practice.

Overall, the feature seems to work like most Facebook Connect sites, and thus poses no inherent security problems. However, I did find quickly that Cuil was not encoding the results from Facebook. That is, a friend could post a status saying, “testing <script>alert(document.cookie)</script>” and searching for “testing” in Cuil would load the alert dialog. Obviously the impact of such an attack would be minimal, as it requires jumping through a few hoops first, but it again illustrates accidental XSS via syndicated content. Note that XSS in a Facebook Connect application would open the door to a FAXX-style attack.

An example of a federated system that causes me some concern is Google Wave. When I first started looking at Google Wave from a security standpoint, I admit that I did not fully understand the architecture of the product. In essence, Wave includes two distinct components – a server and a client. On the server end, Wave is an XMPP service that can communicate with any compatible setup. On the client side, Wave is the web interface hosted at wave.google.com for loading messages from servers.

Once I understood this division, I thought it even more important to discuss the security implications of gadgets within waves. I fully expect Google to address most, if not all, of the issues I raised regarding gadgets. (In fact, last time I checked, it appeared they had changed the domains of container iframes, stopping cross-gadget access). But if Wave really does catch on, Google’s client interface will not be the only one on the market. Since gadgets render as HTML/CSS/JavaScript, Wave clients will almost assuredly have some sort of web browser component. If the company that invented Wave did not factor in some of the security considerations I and others have noted in their original client, there’s a good chance other developers will not take into account similar issues unless people raise awareness.

However, security in Wave clients deals with only one direction of a federated system. I’m still wondering how certain aspects of federated waves will work in practice. For instance, from what I understand, each thread of messages in Wave will be stored on the server hosting the thread. What will happen if that server becomes suddenly unavailable? How will corporate record-keeping and e-discovery And while Google’s Wave servers will likely be quite secure, what about other servers?

Granted, some questions about Wave servers could be raised about similar systems, such as e-mail. But several of the decentralized aspects of Wave distinguish it from a typical e-mail setup, and could prove to be good experiments in light of proposals for decentralized social networking. I’ve long supported the idea of distributed social networking, but also felt it could lead to many performance and usability problems not found in a walled garden (I’ve been meaning to write a blog post entitled “In Defense of Walled Gardens” for at least a year). Wave may be one of the first large-scale attempts at building a distributed application somewhat akin to social networking.

Facebook Instapaper Twitter Digg FriendFeed Delicious Google Bookmarks Yahoo Bookmarks Share/Bookmark

Social Media Security Podcast 6 – Privacy, Photo Tagging, Facebook Police, What is Clickjacking

skullThis is the 6th episode of the Social Media Security Podcast recorded December 3, 2009.  This episode was hosted by Tom Eston and Kevin JohnsonScott Wright joins in as “god” during post-edit.  Below are the show notes, links to articles and news mentioned in the podcast:

  • New privacy settings in Facebook are rolling out, regional networks are being removed.  Be sure to check out the comments under Mark Zuckerberg’s blog post…all spam!
  • Is Facebook photo tagging still a big fail?
    Scott clarifies this for us.  The solution to this is to adjust your privacy settings to allow only you to see tagged photos of yourself and ensure email alerting is on to alert you when a new photo is tagged of you.  That way you can easily remove any tagged photo of you.  There is also no way to “prevent” a photo of you being tagged.  However, to tag someone they need to be in your friends list.  How about false tagging?  Someone tagging you in a naughty picture…reputation issue?  What if you don’t have a Facebook account and friends make comments regardless?
  • Police create fake Facebook account to bust a college student for underage drinking.  Did the police go too far or this is acceptable practice in this day and age?
  • Kevin talks about Clickjacking.  What is it and what do users of social networks need to be aware of?

Please send any show feedback to feedback [aT] socialmediasecurity.com or comment below.  You can also call our voice mail box at 1-613-693-0997 if you have a question for our Q&A section on the next episode.  You can also subscribe to the podcast in iTunes! Thanks for listening!

Social Media Security Podcast 5 – Google Reader, Privacy, Wave, ChromeOS and Foursquare

skullThis is the 5th episode of the Social Media Security Podcast recorded November 20, 2009.  This episode was hosted by Scott Wright and Tom Eston. Kevin Johnson will be joining us for the next podcast.  Below are the show notes, links to articles and news mentioned in the podcast:

Please send any show feedback to feedback [aT] socialmediasecurity.com or comment below.  You can also call our voice mail box at 1-613-693-0997 if you have a question for our Q&A section on the next episode.  You can also subscribe to the podcast in iTunes! Thanks for listening!

Facebook Worm Uses Clickjacking in the Wild

Reports have been spreading today of a new Facebook worm that posts a link to the infection page on people’s profiles. The infection page itself includes a button that users are told to click, with the promise of seeing “something hot” or dominating FarmVille. Nick FitzGerald at AVG posted a walkthrough of the worm (warning: slightly NSFW image), and when explaining how the worm operated, gave an explanation similar to that of other articles I saw:

A sequence of iframes on the exploit page call a sequence of other pages and scripts, eventually resulting in a form submission to Facebook “as if” the victim had submitted a URL for a wall post and clicked on the “Share” button to confirm the post.

With all due respect to FitzGerald and others, I was suspicious. First, I know from experience what sort of CSRF protections Facebook has put in place. Second, if this were truly just CSRF, why not execute the attack on loading the page instead of requiring a second click?

I do know of one relative of CSRF attacks (some classify it as simply CSRF, but I do see a distinction) that requires another click, and that’s clickjacking. I decided to check out an infection page to see exactly what was going on.

Sure enough, both the “hot” and “dominate FarmVille” pages load in invisible iframe, which calls for another local page, which in turn loads another invisible iframe. The actual source of the second local page looks like this (URI edited):

<html><head></head><body><div style=”overflow: hidden; width: 56px; height: 24px; position: relative;” id=”div”>
<iframe name=”iframe” src=”http://EVILURI/index.php?n=632″ style=”border: 0pt none ; left: -985px; top: -393px; position: absolute; width: 1618px; height: 978px;” scrolling=”no”></iframe></div></body></html>

The address that the iframe loads simply redirects to a Facebook share page with the infection page specified as the share link. Note that the style attribute on the iframe includes negative values for “left” and “top” – this ensures that when the page loads, the “Share” button for the Facebook page is at the top-left corner of the iframe, and thus positioned right underneath the button users think they are clicking.

It’s perhaps worth noting that the possibility of such a worm has been pointed out before, including on this blog:

All of the following actions can be mistakenly performed by a user simply clicking a link or button on an innocent-looking page via clickjacking:

Post a link to your profile. This is possible by applying clickjacking to several Facebook pages used for sharing content. A custom title and description can be set for the link. Other content, such as a Flash video, can also be posted this way.

I also encouraged Facebook in my Month of Facebook Bugs Report to take clickjacking seriously. The behavior of this worm is only the beginning – as I’ve pointed out for months, a similar attack could authorize a Facebook application (malicious or hijacked) and steal user information while spreading links even more virally. This new worm may be one of the first examples of clickjacking used in the wild, but it certainly won’t be the last.

Facebook Instapaper Twitter Digg FriendFeed Delicious Google Bookmarks Yahoo Bookmarks Share/Bookmark

XSS in Engadget’s New Site

I’m noticing a trend of sites patching the more obvious cross-site scripting vectors, such as search fields, but ignoring parameters in secondary pages, such as Ajax interfaces. Several applications in the Month of Facebook Bugs had pages for making Ajax calls or loading advertisements that were never meant to be loaded directly, yet doing so opened the door to XSS attacks. Keep in mind that any page on a given domain can access that domain’s cookies.

Yet another case in point came to my attention this week. I noticed that the technology news site Engadget had launched a redesign, and I began poking around the new site. After a little while, I came across four XSS vulnerabilities, all on the main www.engadget.com domain. I promptly reported the holes and they were silently patched in less than a day or two. Since they’ve all been fixed, I’ll list the example URIs I sent here for the record:

  • http://www.engadget.com/?a=ajax-comment-vote&commentid=%3Cscript%3Ealert(document.cookie)%3C/script%3E
  • http://www.engadget.com/?a=ajax-comment-show-replies&commentid=%3Cscript%3Ealert(document.cookie)%3C/script%3E
  • http://www.engadget.com/?a=ajax-comment-report&commentid=%3Cscript%3Ealert(document.cookie)%3C/script%3E
  • http://www.engadget.com/mm_track/Engadget/media/?title=%3Cscript%3Ealert(document.cookie)%3C/script%3E

Previously, each one of these pages loaded the inserted script, which brings up an alert dialog containing the user’s cookies for Engadget. Kudos to the team behind Engadget for the quick fixes, and hopefully this will serve as another reminder to all developers to leave no page unchecked when evaluating security issues.

Facebook Instapaper Twitter Digg FriendFeed Delicious Google Bookmarks Yahoo Bookmarks Share/Bookmark

1 13 14 15 16 17 35