CVE-2018-1000211: Public apps can't revoke tokens in Doorkeeper

by Justin Bull

TL;DR: If a public client respects the RFC 7009 spec and does not authenticate the revocation request, then Doorkeeper does not actually revoke the access token. Upgrade to versions 4.4.0, 5.0.0.rc2 or later

The Problem

Any OAuth application that uses public/non-confidential authentication when interacting with Doorkeeper is unable to revoke its tokens when calling the revocation endpoint.

A bug in the token revocation API would cause it to attempt to authenticate the public OAuth client as if it was a confidential app. Because of this, the token is never revoked.

The impact of this is the access or refresh token is not revoked, leaking access to protected resources for the remainder of that token's lifetime.

If Doorkeeper is used to facilitate public OAuth apps and leverage token revocation functionality, upgrade to the patched versions immediately.

Vulnerable Versions

4.2.0 – 4.3.2

5.0.0.rc1

Impact

All public, non-confidential clients respecting the RFC will not have their access or refresh tokens revoked when sending a valid, well-formed & unauthenticated revocation request to doorkeeper.

Any such clients relying on Doorkeeper's revocation functionality are susceptible to a session replay attack, even after the victim terminates their session via a revocation/log out.

  1. Attacker gains access token via any acceptable means (MiTM, physical computer access, bug in client code, etc.)
  2. Victim logs out/attempts to revoke the access token
  3. Attacker is not affected, as the token is still valid for the duration of its lifespan. Furthermore, the refresh token can be used to extend the attacker's privileged access.

This scenario is captured under the OWASP Top 10 (2013)'s A2: Broken

Authentication and Session Management as a vulnerability.

Now obviously the attacker must already be able to obtain the access token, but without revocation the victim has a false sense of security & cannot limit damage to their account. Additionally, clients relying on the Doorkeeper revocation endpoint to revoke all other issued tokens on password change, password reset, etc. would also be impacted by this problem.

The Fix

Doorkeeper needed a structural update so it is able to define which OAuth client application is intended to be public or confidential.

With that now available, the tokens revocation API knows to either enforce authentication (as required for confidential clients) or accept just the client ID (as is the case for a public client).

See the following PRs for more info:

Credit

All credit to Roberto Ostinelli for discovery.

Thanks to the Distributed Weakness Filing Project for a swift assignment of a CVE identifier.

References

Header image is by Kevin King under the Creative Commons license CC BY 2.0