Date: Tue, 17 Jul 2018 10:16:06 -0400
From: Justin Bull <me@...tinbull.ca>
To: oss-security@...ts.openwall.com, bugtraq@...urityfocus.com,
fulldisclosure@...lists.org
Subject: [FD] [CVE-2018-1000211] Public apps can't revoke OAuth access &
refresh tokens in Doorkeeper
Good morning everyone,
A security bulletin for all of you.
Software:
--------
Doorkeeper (https://github.com/doorkeeper-gem/doorkeeper)
Description:
----------
Doorkeeper is an OAuth 2 provider for Rails written in Ruby.
Affected Versions:
---------------
4.2.0 - 4.3.2
5.0.0.rc1
Fixed Versions:
-------------
4.4.0
5.0.0.rc2
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 causes it to try to authenticate the public
OAuth client as if it was a confidential app. Because of this, the token is
never revoked.
If Doorkeeper is used to facilitate public OAuth apps and leverage token
revocation functionality (RFC 7009[1]), upgrade to the patched versions
immediately.
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[2].
Solution:
---------
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)[1].
See the following PRs for more info:
* https://github.com/doorkeeper-gem/doorkeeper/pull/1119
* https://github.com/doorkeeper-gem/doorkeeper/pull/1031
* https://github.com/doorkeeper-gem/doorkeeper/issues/891
Credit:
-------
All credit to Roberto Ostinelli[3] for discovery.
Thanks to the Distributed Weakness Filing Project for a swift assignment of a
CVE identifier (CVE-2018-1000211).
References:
-----------
[1]: https://tools.ietf.org/html/rfc7009
[2]: https://www.owasp.org/index.php/Top_10_2013-A2-Broken_Authentication_and_Session_Management
[3]: https://github.com/ostinelli
_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/