Hakin9 EXTRA

BASIC FACEBOOK PRIVACY BREACHES

JOSE IGNACIO ORLICKI

This paper is an introduction to Facebook privacy settings and attacks. We survey historic and present aspects of Facebook privacy and security to introduce the reader into the privacy concepts and state of the most widely used social network.
Introduction
The Web paradigm is about web pages referring to other pages to form a network with URL as links and pages as nodes. The usual benefit of networks is that they deliver a positive netwok effect, that is, the more pages in the networks the more useful it is. This is an economical concept and is a central theme in discusions related to services gaining a monopoly (http:// en.wikipedia.org/wiki/Network_effect). Online social network services has discovered that using peoples profiles as nodes and virtual friendships as links we can disseminate information more rapidly. That is the Social paradigm on the Net. In particular, Facebook (FB) is the most used online social network and has a business model that involves privacy concerns and allows various degrees of public or private information. As the number of FB users aproaches 1 billion around these days everyone agrees that most of the users cannot keep up with privacy changes. That means that most of the users do not know if they information is private or public, and to what degree. FB privacy concerns are valid because users upload private photos and videos, publish personal tastes including religious and political opinions. These leads to cases of legal, job and academic compromise of many users. Even it has been reported that FB and other social networks are used by federal investigators to spy on suspects by using fake profiles or directly requesting cooperation with emergency private data requests (http://www.huffingtonpost.com/2010/03/16/fbi-uses-fake-facebook-pr_n_500776.html). Besides native privacy issues, as any web page FB has been a target of cross-site scripting (XSS), SQL code injection, phishing and any attack imaginable for the web vector. Most of the vulnerabilities are available not directly through FB but through the FB platform, the environment for developing third-party applications using FB data and social capabilities (https://developers.facebook.com/). In this article we will focus on native privacy and threats of FB but we will comment brieftly on the FB platform. Launched in 2007 the FB platform opens up the data with applications, external websites and devices. Before that FB grew on their own closed ground with no interconnectability except for some RSS feeds. As FB is moving target with privacy changes every year since 2004, we hope the examples will ilustrate more abstract concepts that will help you secure your social profile in FB and actively anticipate future threats. Defying curiosity and building a constructive paranoia is the main goal.

Facebook privacy settings

As we mentioned earlier FB helps users upload information that includes at least for each user a personal profile, a list of friends or contacts, photo albums and a personal wall with posts. Users are identified by an USERID identifier:

or optionally an unique custom name

Not by the complete name because is not unique. Check favorite search engine for public John Smith profiles

and find that all complete names are accompanied by an USERID

Present photo access is made using an URL such as

Basic Facebook Privacy Breaches

Photo URL history will be discussed in another section (Privacy through obscurity). Each user has some rights to govern the ability of other users to interact with their information. Given some flexibility in these settings the downfall is that most users choose to accept default privacy setting without modification. So the default configuration is often a topic of discussion between privacy defenders and socialmongers.

suck as people tastes (Likes). Present privacy setting include the following capabilities, as seen on Privacy Setting (https:// www.facebook.com/settings/?tab=privacy): Friends or Custom (FoFs, Only Me, etcetera). ryone, FoFs or Friends. or Friends. FoFs, Friends, Only Me or custom lists of contacts. On Privacy Setting > How Tags Work: Facebook): On or Off (Introduced around August 23, 2011! https://blog.facebook.com/blog.php?post=101502 51867797131). On or Off. custom lists of contacts. you: On or Off (face recognition!) es app: On or Off. On Privacy Setting > Apps and Websites:

Figure 1. Availability of personal date on Facebook (default settings)

As for 2010 Matt McKeon has compiled an infography of the evolution of FB default privacy settings (http://mattmckeon.com/ facebook-privacy/). On Figure 1 we can see for example default profile settings on November 2009. We comment on the privacy levels but remember that the graphic is only ilustrative, you will find that default privacy in practice is filled with nooks and crannies depending on obligatory versus optional settings, rollbacks and retroactive settings: mation without even being logged in FB. access de information. er Us information if it is a friend of some of Us friends. These levels are also calles Access Control Levels (ACLs) and are used in FB when users specify which users can access or operate on their profile or uploaded objects. Since April 2010 FB has a clear interface for automated interaction with third-party applicacions. Part of that effort includes posts to obtain data in JSON format:

tions you are using. Apparently most apps access more information the require for normal usage. allowing people who sees your data to use it on third-party applications. about your friends the moment you arrive on select partner websites: On or Off. As these settings suggest the privacy sourface is pretty big. At least your should notice that objects (profiles, photos, etc) can be of two different kinds: (such as 1779461858) are static and once you found an may change. Even in some case historic changes to photo URLs have proven possible for FB architects. As static and dynamic objects are combined also emerges the concept of visible versus non-visible. As you may suspect as

A capability is the ability to perform an action (http://en.wikipedia. org/wiki/Capability-based_security). FB maybe should enforce (or give the possibility to enforce) the principle of least privilege (http://en.wikipedia.org/wiki/Principle_of_least_privilege) that requires that every user must be able to access only the information and resources that are necessary for its legitimate purpose. As separating different social concerns is tedious most users accept default privacy settings that are guided by business decisions whose objective is to open up useful information,

Hakin9 EXTRA
soon as an object becames visible there is turning back, at least for the privacy hacker finding the information, as he/she can grab and mirror the information in another site. the entire Internet) the object is visible to the attacker. For can be found though a common friend. object. Remarkably, unless you use very basic privacy settings or you have a mathematical demostration, you do not know if an object if visible or not. Publication of FB information historically moved from privacy open/automated platform for applications. FB founder personal photos) appeared visible directly to all the Internet. After public notice and critisism FB rolled back the change everyone discovered that the difference for the Everyone-marked albums was only a client-side HTML JavaScript masquerade. So many JavaScript bookmarklets proliferate to continue accessing the albums, such as those included on Listing 1. Even someone discovered that album identificators at some point during early 2009 were also publicly available through FQL (see section FQL and OpenGraph) (Listing 1). These tricks were subsequently patched or client-side web code obfuscated beyond human comprehension. These trick worked for old, shorter, user ids (ranges from 500090001 to 1777798795 and also ids smaller than 5000 correspond to FB employees). On newer ids, ranging from 100000000000004 to present, newest user photos marked for Everyone appear directly on the user profile. As user identificators are assigned incremenes to compute what fraction of users are actually active. There is also the question of guessing or predicting photo ids.

Privacy through obscurity

FB HTML/JavaScript is a highly convoluted salad of ofuscated vegetables. That is a problem because many exposed privacy backtracks has led to situations of security through obscurity, mainly during 2009. For example friend lists where made public and then after users and lawmakers complaints those lists where remove from the front-end profile but remain technical publicly available information (PAI): Now when you uncheck the Show my friends on my profile option in the Friends box on your profile, your Friend List wont appear on your profile regardless of whether people are viewing it while logged into Facebook or logged out. This information is still publicly available, however, and can be accessed by applications. (source: CNET http://news.cnet.com/8301-13577_310413835-36.html) Trick (at this moment fixed) was accesing directly the AJAX data dictionary:

Photo URL Prediction

As we discused in the previous section back and forth modifi where accesible by anyone. After researchers versus FB engineers practical debate developed others questioned the robustness of FB photo URLs. A clarifying article was written by Joseph Bonneau (http://www.lightbluetouchpaper.org/2009/02/11/ new-facebook-photo-hacks/). As later as February 2008, privacy controls were enforced unless you have the user identificator of the target. Not very private may sound as ids are available on public search engines.

Another famous breach was related to photo albums (source: theharmonyguy). As for many years default privacy level for new albums was Everyone no one cared because in practice only Friends or FoFs can access those albums (i.e. seen them included in the HTML) and the chance that other users guess the ALBUMID seemed remote. But as FB rolled out a less private default policy these Everyone-marked albums (including

On March 2008, this issue reached mass media and photo URLs were obfuscated and controls really enforced, at least on the FB web domain. What Joseph Bonneau pointed later in February 2009 was that photo data itself is served from other domains than facebook.com (for example bulk data provider Akamais ak.fbcdn.net domain). Apparently fbcdn.net stands for Facebook Content Delivery Network and opens the door to a high performance photo server whose performance does not allow cookies at all. So guessing high-performance URLs leads to direct photo access. At that time we show you an URL example :

Listing 1. Hacks

Basic Facebook Privacy Breaches

Joseph documented the following schema for these URLs:

previously was checked only albumwise, and enforced FB photo URLs include incremental identifiers for albums and photos. It could possibly be predicted with massive brute-forcing because they include a FB-global incremental number plus small sequential offsets around 2^17.

Quoting his blog: the resolution of the image, uid is the user ID of the user who uploaded the photo, pid is a photo ID, and PIN is a four-digit random number. Im calling it a PIN because it was chosen to be four decimal digits, which can only be assumed to have been done in a foolish analogy to bank card security. Its easy to learn everything but the PIN given a public link to the photo. Brute-forcing the PIN is also fairly easy: its a space of 9000, which can be searched in about 45 minutes using one script. This is also easily parallelisable, given that we can query any down to under 2 minutes. This is still a lot of work for one photo, but it gets better. Incrementing the photo ID by one reliably gives the next photo that was uploaded as part of the same album. Looking at the next few photos in sequence from the one posted above, the certainly created by timestamping as the photos are received. So, given the public link to one photo, and doing one brute-force, we can pretty easily get the rest of the album with 10-20 queries per photo. Ive coded this up and it works splendidlythe photo servers dont appear to do any rate-limiting or blocking. Things changed for new photos on March 2009. But older photos remain available and brute-forceable with JBs script (http://code.google.com/p/fbcdngen/). One programmer pointed some modern examples (http://brunetton.tuxfamily.org/):

A recent attack related to external URLs was notice by people at BlackHatAcademy (http://blackhatacademy.org/). They observed that when someone posts something on Facebook or Google+ theses sites sent an initial request to store a mirror thumbnail of the video or snapshot or the site being shared. These online social networks use custom user agents for these early requests. So a legitimate thumbnail can be provided, but later when users click on the link malicious content can be delivered. They named this kind of attack Cross-site Content Forgery. A proof of concept in PHP was published (See Listing 2).
Listing 2. Proof of concept for Cross-site Content Forgery

and so on
...

PIN now looks like a random 7-digit number but [uid] is still constant, and [pid] are still sequential so brute-force attack only became 10000 times harder. On 2011 the complexity of the high-performance URLs continue to grow to look something like this:

Platform mayhem
To support third-party applications FB has the idea of developing FBJS, their own propietary version of JavaScript, developing FBML, their version of HTML, and FQL, similar to SQL. Basic criptography and security expertise recommends to never reimplement standars, instead use known and tested implementations. That platform was launched on May, 2007. At this moment FBML has been announced to be deprecated and unsupported on January 1st, 2012. Will be completely replaced by the JavaScript libraries plus HTML and CSS.

Following a pattern like ID1_ID2_ID3_ID4_ID5_SIZE.jpg with much more larger partial identifiers. And also on the FB side since August 2011 control is enforced to each single-photo level,

Hakin9 EXTRA
See Figure 2 for a diagram of the FB platform. FB seats in the middle between the app provider and the user, proccesing code and serving as a proxy of user data the app requires. Actually the value of FB apps comes from the use of social network data, such as lists of friends, for example in social gaming. In the next section we will discuss various basic theats to privacy related to FQL.

FQL and OpenGraph

Facebook own query language, known as FQL, gives any user access to partial FB data. Since 2009 all FB data has been restructured for third-party access on a new platform called OpenGraph, but FQL remains as one of the ways of requesting OpenGraph data. OpenGraph core design goal is to help interact with external websites, for example IMDb. By default only public FB data can be accessed.

Figure 2. Diagram of FB platform

Apps are known for security and privacy problems as FB do not has the abilitity to push good practices on application developers, specially regarding privacy. According to social networks security expert Joey Tyson (also known as theharmonyguy): [FB] does notify applications when a user uninstalls them, but its up to the developer to actually do something about the data left behind. (source: theharmonyguy.com)

Also you can access user OpenGraph data without FQL.

Figure 3. Diagram of testing setup

Many web security problems have plagued the FB platform, including Cross-site scripting bugs (XSS). This kind of JavaScript code-injection bug allows attackers to collect private user information accessed by the applications. Alex Sotirov has developed a novel testing setup (see Figure 3) to find XSS by closing the proxy loop and testing XSS filters with a set of tools (http://www.phreedom.org/research/blackbox-reversing-of-xssfilters/). LeonBlade has reported to FB in May 2011 a XSS and a worm prototype, as you can see on Listing 3 (watch tutorial online at http://www.youtube.com/watch?v=QcSAU16wjHQ). The worm injects itself to replicate affecting the friends of the victim. Notice the request to FBML using the application id.

Figure 4. JavaScript Test Console

Also FB platform developers can use FQL to access data of applications users that has given permission by registering to the application. For example, in the JavaScript test console (Fig

Listing 3. Worm prototype using Facebook XSS.

Basic Facebook Privacy Breaches

As observed in a previous section standard web programming such as JS and PHP will replace the more custom languages FBML and FBJS, but all data queries can be translated to FBL queries (https://developers.facebook.com/docs/reference/api/). If you request your own FB application and get some users to use it. Then data collected from the users can be queried for example from Python. Access token key to access public data can be requested manually from the Graph API Explorer (https://developers.facebook.com/tools/explorer see Figure 5). Otherwise you can request an Access Token for you application choosing it in the Graph API Explorer Combo and then selecting Get Access Token.

Paul Carduner made a simple library called fbconsole for accessing present-day OpenGraph (https://github.com/facebook/ fbconsole). After requesting an Access Token and completing .fb_access_token file you can run scripts such as seen on Listing 4.

Conclusion
As Facebook privacy settings and interaction with third-party applications became more open, many issues has emerged. It is up to the users and researchers to continue pointing out obscure designs details and basic bugs. A trend in the past showed us tures and interaction fronts lead to unexpected new flows of

Figure 5. Graph API Explorer

private information. Present and future privacy breaches are heading towards mobile (http://m.facebook.com), external web sites interaction (OpenGraph) and standard JavaScript integration (custom FBML or FBJS is considered legacy code at this moment).

JOS IGNACIO ORLICKI

Listing 4. Accessing FQL from Python using fbconsole. Graduate student at ITBA, Buenos Aires, Argentina. He is currently researching on social network privacy and web mining. Website: http://www. mechpoet.net