Into the symmetry

As usually I always try to blog about my "security finding" . The main reasons are basically two: I think is really good to share knowledge in this area.  Sometimes I do use my blog posts as a place to store information that I can always access in the future. Unluckily though I am a really lazy blogger and sometimes I just do not blog :S The really good news is that the last vulnerability I found is in github . I already blogged about how good and responsive is the Github security team. And I am now even more impressed by their efficency. The reason why this is a really good news is that in this case I can do both : 1) find a vulnerability 2) being lazy and not trying to describe the vulnerability I found, this because the github team is already describing the vulnerability in their wall of fame :) Hurray.

Usually my (not too many :( ) posts are written for a technical audience (not t o o big :( ). This time, given the fact October is Cyber Security Month I will try to put some effort to try to explain how you can keep yourself away from annoyances. Well the rule of thumb is actually extremely simple and can be resumed with a simple sentence:  Beware what you click Let me repeate it: "beware what you click" :) Just following this simple rule you can avoid 90% of scam/viruses and phishing attacks . But lets do a step back. Assuming you know already what is a computer's virus let me explain what is a phishing attack. Phishing scam uses legitimate-looking websites to trick a victim into sharing their username, password or other  sensitive information. Pishers will design their sites to look exactly like e.g. the website of your mail provider, your bank, credit card issuer, or another financial institution. The hope is that you won't realize you

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=http%3A%2F%2Flocalhost%3A8080%2Fa&scope=http%3A%2F%2Fwww.google.com%2Fcalendar

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