Into the symmetry

tl;dr I found an  XSRF in the OAuth implementation of Redhat Keycloak Gatekeeper . This would be a bit worse for people using Gatekeeper to protect their Kubernetes Dashboard (especially in Microsof Azure). The Issue in Keycloak Gatekeeper Keycloak Gatekeeper is an OpenID Proxy service for Keycloak , an Identity and Access Management solution developed and opensourced by RedHat (now IBM).  Solutions like this are often used to protect things like Kubernetes Dashboard (unless you want to do like Tesla and expose your Kubernetes Dashboard unauthenticated to the internet ) and this (for the record) is why I came across to the issue. I will postpone a deeper analysis of the Kubernetes Dashboard to a future post. The issue is dead simple and I already talked about this several times . This was also  defined by Egor Homakov as the the Most Common OAuth2 Vulnerability (and it looks he was right :p) . Basically the Keycloak Gatekeeper   developers forgot to...

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

tl;dr   Facebook Groups offers the option to upload files directly from the Dropbox account. This integration is done using the OAuth 2.0 protocol and suffered from a variant of the classic OAuth CSRF (defined by Egor Homakov as the the Most Common OAuth2 Vulnerability ),  see video below: Introduction  Facebook Groups offers the option to upload files directly from the Dropbox account: This will allow to surf via browser the Dropbox account  and post a specific file to the group.  This integration is done using a variant of the OAuth 2.0 protocol seen in this blog many many times . But once more, OAuth is an access delegation protocol standardized under the IETF umbrella . A typical OAuth flow would look like: From “OAuth 2 In Action” by Justin Richer and Antonio Sanso, Copyrights 2017 Usually the client initiates the OAuth flow in the following way: From “OAuth 2 In Action” by Justin Richer and Antonio Sa...

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

By Justin Richer and Antonio Sanso  This article was excerpted from the book OAuth 2 in Action . The OAuth core specification specifies four different grant types: Authorization Code , Implicit , Resource Owner Password Credentials and Client Credentials . Each grant type is designed with different security and deployment aspects in mind and should be used accordingly.  For example, the Implicit grant flow is to be used by OAuth clients where the client code executes within the user agent environment. Such clients are generally JavaScript-only applications, which have, of course, limited capability of hiding the client_secret in client-side code running in the browser. At the other side of the spectrum there are classic server-side applications that can use the authorization code grant type and can safely store the client_secret somewhere in the server. What about native applications then?  Native applications are those that run directly on the end user’s...

If you bought the book I have been writing with Justin Richer namely OAuth 2 in Action you might have noticed that we will never got tired to stress out how much important the redirect_uri is in the OAuth 2 universe. Failing to understand this (rather simple) concept might  lead to disasters. The redirect_uri is really central in the two most common OAuth flows ( authorization code and implicit grant ). I have blogged about redirect_uri related vulnerability several times and both in OAuth client and OAuth server context.  Developing an OAuth client is notoriously easier to develop compare to the server counter part. Said that the OAuth client implementer should still take care and master some concepts.  If I would be limited to give a single warning for OAuth client implementer this would be  If you are building an OAuth client,   Thou shall register a redirect_uri as much as specific as you can or simply less formally " The registe...

Some time ago I posted a blogpost abut  Top 5 OAuth 2 Implementation Vulnerabilities . This week I have extended the list while presenting Top X OAuth 2 Hacks at OWASP Switzerland. This blog post (like the presentation) is just a collection of interesting attack OAuth related. #10 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 ... :) #9 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...

In a previous blogpost we have already analyzed a token hijack on one OAuth integration between some Microsoft and Google service and seen what went wrong. Now it is time to see yet another integration between Microsoft and xxxx (unluckily I can't disclose the name of the other company due the fact the haven't still fixed a related issue...) and see some fallacy. But before to focus on the attack we might need a bit of introduction. HTTP referrer An HTTP referrer (misspelled as referer in the spec) is a special HTTP header field that browsers (and http clients in general) attach when surfing from a page to another. In this way the new webpage can see where the request originated. One extra thing to point out is that as per section 15.1.3 (Encoding Sensitive Information in URI's) of HTTP RFC [RFC 2616]: Clients SHOULD NOT include a Referer header field in a (non-secure) HTTP request if the referring page was transferred with a secure protocol. This is summarized ...

tl;dr Apple Safari for OS X was prone to URI spoofing vulnerability  (and more general a user interface spoofing). Apple released security updates for Safari 9 on OS X and assigned CVE-2015-5764. Accidentally this vulnerability was also present in iOS. Instant demo In Safari up to 8.0.8 : go to https://asanso.github.io/CVE-2015-5764/file0.html click "click me!" notice the address bar being "data:text/html,%3CH1%3EHi!!%3C/H1%3E" go back using the browser button click "click me!" notice the address bar being http://www.intothesymmetry.com/CVE-2015-5764/file0.php !!!!  Well this looks a clear caching problem to me, right :) ? The Introduction (Oldie but goldie) Several months ago (almost a year!!) I was reading the great book written by lcamtuf (aka Michal Zalewski) named The Tangled Web .  I know, I know I was a bit late for the party :) Said that, this book contained a really interesting Chapter (for the record Chapter 10) that is de...