tl;dr I found an XSRF in the OAuth implementation of Redhat 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

an OpenID Proxy service for

Keycloak

, an Identity and Access Management solution developed and opensourced by RedHat (now IBM).

really important piece (in OAuthland) namely the state parameter. This parameter is, according to the OAuth core specification: Basically the Keycloak Gatekeeper developers forgot to implement a



An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client. The parameter SHOULD be used for preventing cross-site request forgery (CSRF).

The best way to see this XSRF account in action is through a picture:

.

The Issue in Microsoft Azure

And what about Microsoft Azure? Well as you know many deployments of Kubernetes cluster are not home brewed. What people do is to leverage AWS/Azure or Google cloud to host their Kubernetes cluster. The connection whit this bug here is that the OAuth implementation of Microsoft Azure suffered from a different OAuth issue that in combination with this would have make the issue way easier to be exploited (making it Persistent as in the title of this blog post).So what's the bug?

the section 4.1.3 of the OAuth 2 core specification aka RFC 6749:



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. Basically the Mictosoft Azure's OAuth server implementation was violating another part of the OAth spec namely

As you might imagine they were not the only one and I already talked about it in the past

Conclusion

Is always really surprising that different implementations make the same mistake again and again. In this case two different parts of the stack made 2 different mistakes making the attack much easier to exploit. To conclude this short post Keycloak Gatekeeper fixed the issue in this commit and you can download the fixed version here and Microsoft Azure fixed the issue already.





P.s. little rant I ended up this little journey with no CVE assigned by little rant I ended up this little journey with no CVE assigned by Keycloak Gatekeeper or any mention whatsoever and no bounty from Microsoft. This doesn't make a big difference to someone like me that is in this dirty business for many years but it for sure could have been a killer motivation for a young researcher. To be completely honest both teams Keycloak Gatekeeper and MSRC where super nice though.





For more OAuth trickery follow me on Twitter.