Into the symmetry

Heya, back to my favourite topics namely OAuth . I have previously discussed about common  OAuth 2 Implementation Vulnerabilities but now it is time (maybe) to list those and order them based on their criticality. #5 The Postman Always Rings Twice  I have introduced this 'attack' in last year post . This is for provider implementer , it is not extremely severe but, hey, is better to follow the spec. Specifically 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. It turned out that even Facebook and Google did it wrong ... :) #4 Match Point To all OAuth Providers be sure to follow section 4.1.3 of the spec in particular ...if the "redirect_uri" parameter was included in the initial authorization request as described in Section 4.1.1, and if...

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