Into the symmetry

In my previous blog post I mentioned a following post about some vulnerability I found in https://accounts.google.com/. As said, motivated from my little success that I got finding a vulnerability in some obsolete authorization service in Facebook I thought I might have the same luck with Google :) Well it turned out this was the case... Giving a look at the Older Protocols in the Google Accounts Authentication and Authorization page something that immediately caught my attention was the AuthSub (deprecated) flow. Now, I am not going to describe here the flow, it is enough saying that it is a pre-OAuth flow that Google used to give some access delegation using some sort of tokens... The problem was related with the scope parameter in www. google .com/accounts/ AuthSubRequest . It accepted concatenation of string after a valid scope.  E.g.  https://accounts.google.com/AuthSubRequest?next=https%3A%2F%2Ffd.xuwubk.eu.org%3A443%2Fhttp%2Flocalhost%3A8080%2Fa&scope=https%3A%2F%2Ffd.xuwubk.eu.org%3A443%2Fhttp%2Fwww.google.com%2...

One of the most important thing of anyone keen about security is to keep up to date with what is going on... Hence I have a good collection of rss feed security's related. One post that caught my attention a couple of months ago was this one from Stephen Sclafani. In a nutshell he was able to get a more than decent bounty of 20000$ exploiting some old Facebook API that is the precursor of Facebook's OAuth implementation. Since I am a curious person I decided to give a look at these old APIs just to see the evolution of security over time. I was not hoping to find anything interesting under the bounty point of view since Stephen had found them all (he even did a second blog post collecting another 20000$!!). Well, indeed I was right until some extent. I haven't found anything interesting under the security point of view (strictly speaking) nevertheless I was able to find a minor security issue ( Information disclosure) that got rewarded by Facebook with a bounty... :) ...

Sure they are , if you do not user Firefox (even the last  version) or if you do not use iOs 6.1 or some older version of IE they are really safe :) In the last few days I got the pleasure to be in touch with the github security guys . I must admit I am really impressed about how security is important for Github and how much serious they take it (they embrace and leverage all the new security features supported by modern browsers, Content Security Policy included ). Moreover they are really fast on reply and really friendly so kudos to them. From the other hand I was a bit surprised on how the "handled" a couple of issues I did report. Now the fact I did not get a bounty doesn't play any role on my opinion (apparently both issues I reported were well known by them). The thing that does surprise me instead is the fact that even that those are well known issues are not yet fixed (if ever). But no more words just fact... The first issue I reported is the following....

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%2...

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

Trying to continue the OAuth2 attacks saga started few months ago I am going to introduce a new kind of 'attack' named (by me, continuing the movie's name old tradition :D) 'The Postman Always Rings Twice'. I hope the reason of this name will be clear soon. In a nutshell the section 4.1.3 of the OAuth 2 core specification aka RFC 6749 says: The client MUST NOT use the authorization code  more than once.  If an authorization code is used more than once, the authorization server MUST deny the request and SHOULD revoke (when possible) all tokens previously issued based on that authorization code. Now this is a really simple claim, but it turned out that two major providers as Facebook and Google violated it, until I did report the 'violation'. For this Facebook decided to reward me with a bug bounty (a while ago) and Google (only) with an honorable mention :(. Now you might wonder what is so dangerous on violating section 4.1.3 of the spec? Hopeful...

As the OAuth 2 framework is becoming more and more used I thought it would be useful to share some of the most common attacks. It is important to highlight that the attacks I am going to introduce today are not issues in the specification per se but rather possible implementation issues. The first document to look at when you try to secure one OAuth 2 implementation is the OAuth 2.0 Threat Model but this is way not enough. In order to have a safe implementation it is important to understand what is OAuth about and to be involved in the "OAuthsphere" (OAuth mailing list, blogs, etc), In this blog post I will try to show two of the most common attacks that I have renamed  ' The Devil Wears Prada' and 'Lassie Come Home'. Let's see. Firstly the actors: The Actors The Devil Wears Prada The first time I read about this potential issue was in one of John Bradley's blog post . This issue is also known as " confused deputy problem ...