What Makes Up Facebook Data?

This is the first post in our  Social Networking series.

My guess is that you would not simply give a person that knocked on your front door or approached you in the street most of the data Facebook collects in your profile. Facebook profile data consists of many things, including your birth date, email, physical address, current location, work history, education history and additional information you input for activities, interests and music (interestingly much of this can be used for identity theft…) In addition to your profile data, any installed or authenticated Facebook applications have access to your wall posts and list of friends as well as any other data that is shared with “Everyone”.

As Facebook adds new features, the data included in your face book profile has probably crept to include other data of uploaded pictures, application usage and history, tags in posts or pictures. Facebook will always be looking for ways to collect more of your data as YOU are their product. Your data, data of friends and data of everyone else on Facebook is where Facebook collects their profit and, as with most businesses, profits need to increase through expanding markets and giving access to their product.

The data collected by Facebook on you can also include cookie tracking by Facebook even when you are not explicitly on their website.  Facebook heard much uproar from the user community when a security researcher in September 2011 [link] discovered Facebook was even tracking users that had gone as far as deactivating their accounts! Facebook could then track all web history even through web sites that are not related to Facebook activities in any way.

You do have the ability to limit data on Facebook and make sound decisions on what personal data you do decide to submit to Facebook (friends are another matter). Inherently by using Facebook for the ‘free’ services, you are going to lose some control of your information you share with friends. There are a few important factors that you should think about in dealing with social media and my next post will shine some light on who actually owns and regulates your data within Facebook; stayed tuned and feed back is always welcome.

Facebook Applications Have Nagging Vulnerabilities

By Neohapsis Researchers Andy Hoernecke and Scott Behrens

This is the second post in our Social Networking series. (Read the first one here.)

As Facebook’s application platform has become more popular, the composition of applications has evolved. While early applications seemed to focus on either social gaming or extending the capabilities of Facebook, now Facebook is being utilized as a platform by major companies to foster interaction with their customers in a variety forms such as sweepstakes, promotions, shopping, and more.

And why not?  We’ve all heard the numbers: Facebook has 800 million active users, 50% of whom log on everyday. On average, more than 20 million Facebook applications are installed by users every day, while more than 7 million applications and websites remain integrated with Facebook. (1)  Additionally, Facebook is seen as a treasure trove of valuable data accessible to anyone who can get enough “Likes” on their page or application.

As corporate investments in social applications have grown, Neohapsis Labs researchers have been requested to help clients assess these applications and help determine what type of risk exposure their release may pose. We took a sample of the applications we have assessed and pulled together some interesting trends. For context, most of these applications are very small in size (2-4 dynamic pages.)  The functionality contained in these applications ranged from simple sweepstakes entry forms and contests with content submission (photos, essays, videos, etc.) to gaming and shopping applications.

From our sample, we found that on average the applications assessed had vulnerabilities in 2.5 vulnerability classes (e.g. Cross Site Scripting or SQL Injection,) and none of the applications were completely free of vulnerabilities. Given the attack surface of these applications is so small, this is a somewhat surprising statistic.

The most commonly identified findings in our sample group of applications included Cross-Site Scripting, Insufficient Transport Layer Protection, and Insecure File Upload vulnerabilities. Each of these vulnerabilities classes will be discussed below, along with how the social networking aspect of the applications affects their potential impact.

Facebook applications suffer the most from Cross-Site Scripting. This type of vulnerability was identified on 46% of the applications sampled.  This is not surprising, since this age old problem still creeps up into many corporate and personal applications today.  An application discovered to be vulnerable to XSS could be used to attempt browser based exploits or to steal session cookies (but only in the context of the application’s domain.)

These types of applications are generally framed inline [inling framing, or iframing, is a common HTML technique for framing media content] on a Facebook page from the developer’s own servers/domain. This alleviates some of the risk to the user’s Facebook account since the JavaScript can’t access Facebook’s session cookies.  And even if it could, Facebook does use HttpOnly flags to prevent JavaScript from accessing session cookies values.  But, we have found that companies have a tendency to utilize the same domain name repeatedly for these applications since generally the real URL is never really visible to the end user. This means that if one application has a XSS vulnerability, it could present a risk to any other applications hosted at the same domain.

When third-party developers enter the picture all this becomes even more of a concern, since two clients’ applications may be sharing the same domain and thus be in some ways reliant on the security of the other client’s application.

The second most commonly identified vulnerability, affecting 37% of the sample, was Insufficient Transport Layer Protection While it is a common myth that conducting a man-in-the-middle attack against cleartext protocols is impossibly difficult, the truth is it’s relatively simple.  Tools such as Firesheep aid in this process, allowing an attacker to create custom JavaScript handlers to capture and replay the right session cookies.  About an hour after downloading Firesheep and looking at examples, we wrote a custom handler for an application that was being assessed that only used SSL when submitting login information.   On an unprotected WIFI network, as soon as the application sent any information over HTTP we had valid session cookies, which were easily replayed to compromise that victim’s session.

Once again, the impact of this finding really depends on the functionality of the application, but the wide variety of applications on Facebook does provide a interesting and varied landscape for the attacker to choose from.  We only flagged this vulnerability under specific circumstance where either the application cookies were somehow important (for example being used to identify a logged in session) or the application included functionality where sensitive data (such as PII or credit card data) was transmitted.

The third most commonly identified finding was Insecure File Upload. To us, this was surprising, since it’s generally not considered to be one of the most commonly identified vulnerabilities across all web applications. Nevertheless 27% of our sample included this type of vulnerability. We attribute its identification rate to the prevalence of social applications that include some type of file upload functionality (to share an avatar, photo, document, movie, etc.)

We found that many of the applications we assessed have their file upload functionality implemented in an insecure way.  Most of the applications did not check content type headers or even file extensions.  Although none of the vulnerabilities discovered led to command injection flaws, almost every vulnerability exploited allowed the attacker to upload JavaScript, HTML or other potentially malicious files such as PDF and executables.  Depending on the domain name affected by this vulnerability, this flaw would aid in the attacker’s social engineering effort as the attacker now has malicious files on a trusted domain.

Our assessment also identified a wide range of other types of vulnerabilities. For example, we found several of these applications to be utilizing publicly available admin interfaces with guessable credentials. Furthermore, at least one of the admin interfaces was riddled with stored XSS vulnerabilities. Sever configurations were also a frequent problem with unnecessary exposed services and insecure configuration being repeatedly identified.

Finally, we also found that many of these web applications had some interesting issues that are generally unlikely to affect a standard web application. For example, social applications with a contest component may need to worry about the integrity of the contest. If it is possible for a malicious user to game the contest (for example by cheating at a social game and placing a fake high score) this could reflect badly on the application, the contest, and the sponsoring brand.

Even though development of applications integrated with Facebook and other social network sites in increasing, we’ve found companies still tend to handle these outside of their normal security processes. It is important to realize that these applications can present a risk and should be thoroughly examined just like traditional stand alone web applications.

Bad Plugins, Vulnerabilities, and Facebook for a Triage of Social Engineering Win

Over the course of the last few months I have worked with clients that are tightly intertwined with Facebook through the use of third party plugins.  These plugins are used by the clients’ customer base for sharing links on their walls, entering promotions, and extending the functionality of the Facebook experience.   These third party applications are just as vulnerable as any other web application, but they have a different platform than a traditional web application, as they are tied directly into Facebook.

This leads to a few interesting opportunities for the attacker who may discover a flaw in one of these applications.  For one, there is an inherent trust in the applications on a Facebook page.  When a user on Facebook adds an application to their profile and it is a company that they view favorably, the thought of security might not cross their mind.  An attacker can use this to their advantage, especially in the context of social engineering, to potentially exploit a weakness in this plugin and have a higher success rate of exploitation.   In addition, many websites make use of Facebook’s share.php function, which parses a website and allows a user to share a link on their wall to the material.   This sharing function can also uniquely be exploited in the event that the third party plugin or site has an open redirect vulnerability.

Open redirection is an interesting vulnerability that simply redirects a user from a seemingly trusted site to an un-trusted site.   As a client side attack, Facebook would be an excellent medium for conducting this type of attack.  On a recent engagement, I came across a mobile website that was tightly integrated into Facebook.  Products and services offered by this company could be shared to Facebook, the non-mobile site had 50,000 or so “likes” on Facebook and even had an associated plugin.  The mobile site was vulnerable to open redirection on every single request.  The website took a base64 encoded URL of the non-mobile site and redirected every request to that URL (reformatted with some JavaScript).   I pulled the HTML and Stylesheets for the product I was interested in sharing, base64 encoded my malicious webserver hosting this content, and let the Facebook share.php function parse the site.  The link pasted to Facebook looked identical to the original and also contained the URL of the trusted site.  After a user clicks the product link shared on Facebook, they are redirected to my site, and client side JavaScript exploits are run.

Why is this particularly interesting?  I could send the same link to users over email.  The interesting part is that the link looks legitimate and Facebook even parses the link’s content to add to its legitimacy.  In addition, if I have already built rapport with people who like this particular client’s products and services, this also assists in the potential effectiveness of this attack.

So to help mitigate this risk, ensure your third party plugins are assessed in the same degree as your web applications.  If you are a company that allows employees to use Facebook, ensure users are educated on the risk of using Facebook and the plugins that tie into the site.

Facebook in the last few months has really ramped up their security efforts by offering a Bug Bounty program.  The program adheres to the principle of responsible disclosure and has been relatively successful as numerous bugs and fixes have been implemented.  Unfortunately, third-party plugins are excluded from this program, and since tens of thousands of third party applications integrate into Facebook, this presents many opportunities for the curious attacker.   It would be nice to see Facebook allow third-party developers to opt into this bug bounty program, but in the mean time it is a step in the right direction.