iGoogle Facebook gadget security flaw fixed & explained

I just received confirmation from the Google Security Team that the bug I discovered in the iGoogle Facebook Gadget which allowed attackers to log into an other user’s Facebook account bypassing all authentication, has been fixed. So now that the hole has been closed, let’s look at what was happening, shall we?

The gadget uses the Facebook’s Javascript API to the connect with Facebook, asking you for permission to access your FB data. In the process of getting that authorization, the gadget exchanges tokens with Facebook, some of which should absolutely be kept safe from prying eyes. And that’s where things went wrong: the gadget had the authentication info in the URL. So if a user of the iGoogle Facebook gadget clicked a link to an external site in the news feed, the request for that page had a referrer that contained all authentication-info.

And that’s exactly what happened on last week, when I spotted this referrer in my blog stats:

http://facebookiggadget.appspot.com/?exp_rpc_js=1&exp_track_js=1&st=c%3Dig%26e%3DAPu7icpJzJJhOouS8TuGegSqFHHI8XHU1r55OllrNbk0ey/aTpkUFx9jPKB/cwgcEZoGfcBuc43x/CuzuEL2cQinYglFvhFWKtlXg6j/JtKC0%252BWsAu3vo/3ZR/WA64J/Fmw1YuUFgT7q&v=fdb2b406636e1f3cff1c5d7e660f59eb&container=ig&view=home&lang=nl&country=BE&up_session=%7B%22uid%22:%221165373488%22, %22session_key%22:%2291d52d2ed5a130fd941b11f1-1175373488%22, %22secret%22:%22fdee68961b3cdee5b51390a4bdeac7a0%22,%22expires%22:0, %22access_token%22:%2283101558C90fd9KfA9KJQh5uT98TqIjxQpzUi4.%22,
%22sig%22:%22dd635ef67af1f59c1c671215076cce10%22%7D
&parent=http://google.be&libs=7ndonz73vUA/lib/liberror_tracker.js,iHKb-4mKuMY/lib/librpc.js,vrFMICQBNJo/lib/libcore.js,a5j4V1JuNVE/lib/libsetprefs.js&is_signedin=1&synd=ig&view=home

You can guess what happened when I opened that URL; the iGoogle Facebook gadget initialized using the embedded credentials, automatically logging me in as the guy that was unlucky enough to have clicked the link to my blog.

But how could this vulnerability have been exploited, you may ask? Well, easy enough; create a page that is viral enough for people to share or like  (likespam or even likejacking) and wait for users of the iGoolge Facebook-gadget (there’s over 1 million of them after all) to follow the links, feeding your webserver logfiles with credential-rich referrers.

As Google confirmed this bug indeed has been fixed. The new version of the gadget, which was deployed late last week, does not leak credentials in the referrer-URL any more:

http://facebookiggadget.appspot.com/?lang=en&country=us&.lang=en&.country=us&synd=ig&mid=101&ifpctok=6472409229927695377&exp_rpc_js=1&exp_track_js=1&exp_ids=17259&parent=http://www.google.com&libs=7ndonz73vUA/lib/liberror_tracker.js,iHKb-4mKuMY/lib/librpc.js,vrFMICQBNJo/lib/libcore.js,a5j4V1JuNVE/lib/libsetprefs.js

So if anyone asks me what my good deed for this year was; I helped protect 1 million people’s Facebook accounts from being hacked.

Sounds swell, no? ;-)

6 thoughts on “iGoogle Facebook gadget security flaw fixed & explained

    1. frank Post author

      And Google Security Team’s answer:

      That’s a great question. Fortunately, the auth tokens are only short
      lived, so any tokens that currently exist in web server logs are expired.

      Reply
  1. Philip Paeps

    Aside: facebook users have no expectation of privacy in the first place, so… yeah.

    But this is a pretty good example of all that’s wrong with in-band signalling. The WWW crowd has almost caught up with the 1980s of telephony. Good job!

    Reply
    1. frank Post author

      Not sure about the in-band signalling analogy, but I see 2 problems with the igoogle facebook gadget; the least important being that credentials (be it username/pwd or token/secret) should never be in a URL, ever.

      but more importantly; the normal oauth setup seems pretty safe (although I can’t say I know OAuth well enough to make a formal assessment), with the oauth provider (e.g. facebook or google) knowing which application (oauth consumer with unique consumer id & secret) can access user data with an access token & access token secret. in this setup, the browser (user) does not know consumer id, consumer secret and access token secret.

      in the javascript implementation however (e.g. the facebook-one), a lot of the info that normally resides on the consumer server (consumer key + secret and access token secret) has to be kept client-side, in the browser, accessible by (other) javascript. as far as I can tell, that means a javascript-based OAuth implementation can never be really safe.

      Reply
  2. Timothy

    I tried to insert the gadget in my gmail and it wouldn’t work.
    “Invalid gadget specification. Ensure URL is correct and the gadget does not contain errors.”
    Any suggestions?

    Reply

Leave a Reply

Your email address will not be published. Required fields are marked *