exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

Doorkeeper 4.1.0 Token Revocation

Doorkeeper 4.1.0 Token Revocation
Posted Aug 19, 2016
Authored by Justin Bull, Jonathan Clem

Doorkeeper version 4.1.0 failed to implement OAuth version 2.0 token revocation correctly.

tags | advisory
advisories | CVE-2016-6582
SHA-256 | e5400f0adaf19e6cdbfd6429e1d23cd733abae609b0b8e7f6924122f5a7731f2

Doorkeeper 4.1.0 Token Revocation

Change Mirror Download
Software:
--------
Doorkeeper (https://github.com/doorkeeper-gem/doorkeeper)

Description:
----------
Doorkeeper is an OAuth 2 provider for Rails written in Ruby.

Affected Versions:
---------------
1.2.0 - 4.1.0 (all versions but latest patch supporting token revocation)

Fixed Versions:
-------------
4.2.0 or apply this commit[0]

Problem:
--------
Doorkeeper failed to implement OAuth 2.0 Token Revocation[1] (RFC
7009[2]) in the following ways:

1. Public clients making valid, unauthenticated calls to revoke a token
would not have their token revoked
2. Requests were not properly authenticating the *client credentials*
but were, instead, looking at the access token in a second location
3. Because of 2, the requests were also not authorizing confidential
clients' ability to revoke a given token. It should only revoke tokens
that belong to it.

(see [3][4][5][6] for above statements)

The security implication is: OAuth 2.0 clients who "log out" a user
expect to have the corresponding access & refresh tokens revoked,
preventing an attacker who may have already hijacked the session from
continuing to impersonate the victim. Because of the bug described
above, this is not the case. As far as OWASP is concerned, this counts
as broken authentication design[7].

MITRE has assigned CVE-2016-6582 due to the security issues raised. An
attacker, thanks to 1, can replay a hijacked session after a victim logs
out/revokes their token. Additionally, thanks to 2 & 3, an attacker via
a compromised confidential client could "grief" other clients by
revoking their tokens (albeit this is an exceptionally narrow attack
with little value).

Unless I'm mistaken, all clients (public or confidential) that send
well-formed, RFC 7009 compliant requests are affected by this bug.

Solution:
-------

Modify the controller so if the request comes from a public client
revoke the token without auth/auth. If the client is confidential,
authenticate the client per RFC 6749 Sec. 2.3[8] and authorize its
ownership of the provided token. As per [0].

Timeline:
--------
2016-08-03: Bug discovered
2016-08-03: CVE requested, assigned, privately disclosed to maintainer,
bugfix/patch authored
2016-08-08: Maintainer tweaked patch
2016-08-12: Jonathan Clem ( jclem) also discovered bug and publicly
disclosed[6]
2016-08-18: Patched version 4.2.0 is released

Acknowledgements:
-----------------
Special thanks to the maintainer, Tute Costa (https://github.com/tute),
for quickly collaborating with me to prepare & apply a patch.

References:
----------
[0]:
https://github.com/doorkeeper-gem/doorkeeper/commit/fb938051777a3c9cb071e96fc66458f8f615bd53
[1]: https://github.com/doorkeeper-gem/doorkeeper/pull/374
[2]: https://tools.ietf.org/html/rfc7009#section-2.1
[3]:
https://github.com/doorkeeper-gem/doorkeeper/blob/v4.1.0/app/controllers/doorkeeper/tokens_controller.rb#L13-L35
[4]:
https://github.com/doorkeeper-gem/doorkeeper/blob/master/lib/doorkeeper/helpers/controller.rb#L28-L30
[5]:
https://github.com/doorkeeper-gem/doorkeeper/blob/master/lib/doorkeeper/oauth/token.rb#L5-L23
[6]: https://github.com/doorkeeper-gem/doorkeeper/issues/875
[7]:
https://www.owasp.org/index.php/Top_10_2013-A2-Broken_Authentication_and_Session_Management
[8]: https://tools.ietf.org/html/rfc6749#section-2.3

Login or Register to add favorites

File Archive:

March 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Mar 1st
    16 Files
  • 2
    Mar 2nd
    0 Files
  • 3
    Mar 3rd
    0 Files
  • 4
    Mar 4th
    32 Files
  • 5
    Mar 5th
    28 Files
  • 6
    Mar 6th
    42 Files
  • 7
    Mar 7th
    17 Files
  • 8
    Mar 8th
    13 Files
  • 9
    Mar 9th
    0 Files
  • 10
    Mar 10th
    0 Files
  • 11
    Mar 11th
    15 Files
  • 12
    Mar 12th
    19 Files
  • 13
    Mar 13th
    21 Files
  • 14
    Mar 14th
    38 Files
  • 15
    Mar 15th
    15 Files
  • 16
    Mar 16th
    0 Files
  • 17
    Mar 17th
    0 Files
  • 18
    Mar 18th
    10 Files
  • 19
    Mar 19th
    32 Files
  • 20
    Mar 20th
    46 Files
  • 21
    Mar 21st
    16 Files
  • 22
    Mar 22nd
    13 Files
  • 23
    Mar 23rd
    0 Files
  • 24
    Mar 24th
    0 Files
  • 25
    Mar 25th
    12 Files
  • 26
    Mar 26th
    31 Files
  • 27
    Mar 27th
    19 Files
  • 28
    Mar 28th
    42 Files
  • 29
    Mar 29th
    0 Files
  • 30
    Mar 30th
    0 Files
  • 31
    Mar 31st
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close