← Back to team overview

yahoo-eng-team team mailing list archive

[Bug 1795800] Re: Username enumeration via response timing difference

 

I disagree that this is too hard to fix. In fact I'm fairly sure I found
it already:

http://git.openstack.org/cgit/openstack/keystone/tree/keystone/auth/plugins/core.py?h=stable/pike#n174

We do a user lookup long before bothering to try to validate the
password. The fix is to continue to go through the motions of trying to
validate the password while keeping track of the fact that the user is
already unauthorized. This is independent of hardware and caching
mechanisms.

The performance slowdown would only occur for invalid authentication,
not for valid ones, so I think it's an acceptable hit.

** Changed in: keystone
       Status: Won't Fix => Triaged

** Changed in: keystone
   Importance: Undecided => Wishlist

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1795800

Title:
  Username enumeration via response timing difference

Status in OpenStack Identity (keystone):
  Triaged
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  This issue is being treated as a potential security risk under
  embargo. Please do not make any public mention of embargoed (private)
  security vulnerabilities before their coordinated publication by the
  OpenStack Vulnerability Management Team in the form of an official
  OpenStack Security Advisory. This includes discussion of the bug or
  associated fixes in public forums such as mailing lists, code review
  systems and bug trackers. Please also avoid private disclosure to
  other individuals not already approved for access to this information,
  and provide this same reminder to those who are made aware of the
  issue prior to publication. All discussion should remain confined to
  this private bug report, and any proposed fixes should be added to the
  bug as attachments.

  The response times for POST /v3/auth/tokens are significantly higher
  for valid usernames compared to those of invalid ones, making it
  possible to enumerate users on the system.

  Examples:

  # For invalid username
  + Request
  POST /v3/auth/tokens HTTP/1.1
  Host: hostname:5000
  Connection: close
  Content-Length: 141
  Content-Type: application/json

  {"auth":{"identity":{"methods":
  ["password"],"password":{"user":{"name":
  "nonexisting","domain":{"name": "Default"},"password":
  "devstacker"}}}}}

  + Response Time: <150ms

  # For valid username ('admin' in this case)
  + Request
  POST /v3/auth/tokens HTTP/1.1
  Host: hostname:5000
  Connection: close
  Content-Length: 139
  Content-Type: application/json

  {"auth":{"identity":{"methods":
  ["password"],"password":{"user":{"name": "admin","domain":{"name":
  "Default"},"password": "devstacker"}}}}}

  + Response time: >600ms

  # Tested version
  v3.8

  [UPDATE 3 Oct 2018 5:01 AEST]
  Looks like it's also possible to enumerate for valid "domain" too. There're 2 ways that I can see:
  * With valid username: use the above user enum bug to guess the valid username, then brute the "domain" parameter. Response times are significantly higher for valid compared to invalid domains.
  * Without valid username: get a baseline response time using invalid username AND invalid domain name. Bruteforce the "domain" param until the response time hits an average high. For me invalid domain falls in the 90-100ms range whereas valid ones show 100+ms. This one looks a bit more obscure i.e. timing difference is not as distinguishable, but should still be recognisable with a good sample size.

To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1795800/+subscriptions