Open Stack

The OpenStack Vulnerability Management Team only requests CVE
assignments to track vulnerabilities corresponding to fixes they're
announcing via OpenStack Security Advisory publications, but anyone can
request a CVE assignment from MITRE for any issue they'd like to track
(or assign one themselves directly if they're a CNA). Please don't let
the ongoing conversation stop you from obtaining a CVE for this
particular bug if you want one, but please note within the bug report if
you do so in order that we might avoid future duplication.

Technically this concern is already disclosed to the public by nature of
being a public bug report (I just now noticed I failed to clean up the
embargo preamble in the description when making it public in October,
but have gone ahead and taken care of it just now). Further, as it's
tagged "security" all comments are also being copied to the public
openstack-security mailing list (I have no idea what "OpenStack
Maintainers" is in your last comment):
http://lists.openstack.org/pipermail/openstack-security/2018-December/

** Description changed:

- 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.

-- 
You received this bug notification because you are a member of OpenStack
Security SIG, which is subscribed to OpenStack.
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:
  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