Security Thoughts

Wednesday, April 21, 2010, 16:16

Facebook application hole. A neverending story?

It was April 11th @ 9:00 AM,some days before my Campusparty talk, and I decided to have a quick look at Facebook apps howto implementations.

After some hours of trial and error I understood that an application has almost full access to user data by using REST-Ful APIs.

It seems that an application just needs a key called session_key representing the user.
How to get that? Redirecting the user to the facebook page (FacebookWiki):

http://www.facebook.com/tos.php?api_key=[AppKey]&moreParameters

Which, if user has already subscribed to the application, then it redirects to :

http://apps.facebook.com/appPage/?session={"session_key":"2.XXXXXXXXZzHYZaBMEA__.3600.XXXX-XXXXX","uid":XXXXXX,"expires":1271016000,"secret":"XXXXXX","base_domain":"domain.com","sig":"XXXXX"}

The url where the user is redirected can be set in the 'next' parameter (implied in moreParameters).
Now I had to better understand what I can do and went to my favourite FaceBook hacker-superhero The Harmony Guy.
Found this:

It seems he already found something...and very big! :( Even if I don't know a thing about FBK, I was sooo near!

The good^N^N^N^NBad thing is that it took me a few hours to study the environment and think about that.

That's the explaination (from harmony guy link):

"...
But the first main component of the attack involved a slight modification to
the login page URI. By adding a 'next' parameter, once can specify an
alternate landing page for authorized users. Not all applications take
advantage of this parameter, but many do. The parameter would not work
for an arbitrary site, but Facebook previously did allow any URI that began
with apps.facebook.com. Thus one could craft a login page URI that
checked whether the user had authorized one application and then
forward the user to a second application. The next part of the attack came
from adding 'return_session=1' to the login page URI. This parameter
causes Facebook to append particular session variables for the authorized
application onto the URI of the landing page - in our case, the second
application given by the 'next' parameter. That application merely has to
check its address for the session data, which provides enough information
to execute API requests using the credentials of the already authorized
application.
..."

Now there's something I don't understand, and that's because I'm not a Facebook hacker and because the description is not technical.
They say it's fixed but if I try this request:

http://www.facebook.com/tos.php?api_key=80c6ec6628efd9a465dd223190a65bbc&connect_display=popup&v=1.0&next=../wisectest/&v=1.0&&return_session=true&session_key_only=true&canvas

using farmville api_key with next parameter set to my test application home page on apps.facebook.com, I get a redirect to:

http://apps.facebook.com/wisectest/?session={"session_key":"2.XXXXXXXXZzHYZaBMEA__.3600.XXXX-XXXXX","uid":XXXXXX,"expires":1271016000,"secret":"XXXXXX","base_domain":"farmville.com","sig":"XXXXX"}

After that the victim seems to be also added my fake test app transparently...

Maybe they fixed on login.php but missed some page?...:o
As usual the infamous question I asked myself a lot of times when a vuln is fixed but the technique has not been understood.
How come that after the "theharmonyguy" post no one @facebook got a deep analysis?
Maybe complexity is a bad dwarf when dealing with security, but what about applying Secure-SLDC, I mean, really.

Just for sake of user privacy protection, I'd suggest to use different Browsers or Firefox Plugins.

Use Chrome for your every day browsing
Use (at least) multiple profiles on Firefox for your favorite categories
- Firefox -P private
- Firefox -P banking
- Firefox -P pr0n
- Firefox -P whatever
and, of course use NoScript! ;)

Nota Bene:
I also found some site publishing Xss on facebook applications by simply searching on google...and they still work!
Hey Mr. Facebook would you care doing a Google search?
A hint: "facebook applications security bugs" on bigG.

Comments:

theharmonyguy, Wednesday, April 21, 2010, 17:07

Wow great find - they fixed the "next" parameter for an absolute URI, but not the relative URI you put in. I just confirmed the bug and will report it to my contact at Facebook, giving you full credit of course.

Your test app was not actually added for the victim - the "Recently Used" list of apps includes ones you've only viewed but not added. The problem is that your app could have harvested the FarmVille session data and executed API requests using FarmVille's API key.

Thanks for sending me the link on Twitter!

Stefano, Wednesday, April 21, 2010, 17:21

theharmonyguy,
ahh I see that's not added!
Good to know.
Next time I'll ask directly you some more details before publishing.
I'm just a n00b on Facebook hacking :P

Yes, the data harvesting is the first thing I thought, and also you can use an Xss to redirect to an app with a Xss without owning any app on Facebook. In that way you got the session data as well using an img src="...

theharmonyguy, Wednesday, April 21, 2010, 17:59

True, though it would need to be XSS in an app page that does not require you to be authenticated for *that* app also. Executing the API requests immediately would also ensure the session data doesn't expire before you use it.

Security Thoughts

Wisec is brought to you by...