tl;dr in this blog post I am going to talk about some bug bounty left over with a little rant. Here you can find bug bounty left over part I and II Here you can find bug bounty rant part I and II Introduction In one of my previous post I was saying that: "The rule #1 of any bug hunter... is to have a good RSS feed list." Well well well allow me in this post to state rule #2 (IMHO) "The rule #2 of any bug hunter is to DO NOT be to fussy with 'food' specifically with left over" aka even if the most experience bug hunter was there (and it definitely was my case here, given the fact we are talking about no one less than filedescriptor ) do not assume that all the vulnerabilities have been found! So if you want some examples here we go. Part I - Google I have the privilege to receive from time to time Google Vulnerability Research Grant . One of the last I received had many target options to choose from, but one in particular caught my...
Posts
tl;dr I was able to hijack the OAuth tokens of EVERY Paypal OAuth application with a really simple trick. Introduction If you have been following this blog you might have got tired of how many times I have stressed out the importance of the redirect_uri parameter in the OAuth flow. This simple parameter might be source of many headaches for any maintainer of OAuth installations being it a client or a server. Accepting the risk of repeating myself here is two simple suggestions that may help you stay away from troubles (you can always skip this part and going directly to the Paypal Vulnerability section): If you are building an OAuth client, Thou shall register a redirect_uri as much as specific as you can i.e. if your OAuth client callback is https://yourouauthclient.com/oauth/oauthprovider/callback then DO register https://yourouauthclient.com/oauth/oauthprovider/callback NOT JUST h ttps://yourouauthclient.com/ or https://yourouau...
tl;dr The Internet Bug Bounty rewarded me with a bounty for an Open Redirect in rfc6749 aka 'The OAuth 2.0 Authorization Framework' . Here the long version. The Introduction Several months ago I did realize that if you want to implement an OAuth Authorization Server and follow verbatim the OAuth core spec you might end up having an Open Redirect. Now there is still some debate about this class of vulnerability since often they are relatively benign but not always (as we can see later). Despite all at that point I notified the OAuth working group . There was some longish discussion but eventually (almost) all in the list agreed that this was somehow an issue (no where near the end of the world :)). The Issue Section 4.1.2.1 of the OAuth specification says: If the request fails due to a missing, invalid, or mismatching redirection URI, or if the client identifier is missing or invalid, the authorization server SHO...
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.
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...
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 ...