yahoo-eng-team team mailing list archive

[Jeremy Stanley <2111402@xxxxxxxxxxxxxxxxxx>]

Hearing no objections, I've switched this bug from Private Security to
Public with the security bugtag and am for now treating it as a class D
(security hardening) report per our taxonomy:
https://security.openstack.org/vmt-process.html#report-taxonomy

As previously mentioned, I've added horizon back as possibly affected
but I'll leave it to the keystone and horizon maintainers to determine
if this is actually a duplicate or something subtly different.

** 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. This
- embargo shall not extend past 2025-08-25 and will be made
- public by or on that date even if no fix is identified.
- 
  == Description ==
  An attacker is able to identify local user accounts to OpenStack by performing continuous POST requests to the endpoint /auth/login and comparing the response times. Valid users have about the double or more in terms of response time, making it easier to accomplish account compromise via password guessing or bruteforce.
  
  The request I've sent also had the following POST data:
  
  csrfmiddlewaretoken=jEk6xHFxFoKHZ1OpPTZBGf0ZIAXkh6EJuRveiaL11Ho8E2uOiR0PXRrETkhPW28c&fake_email=&fake_password=&region=default&username=<GUESSED_USERNAME>&password=bogus
  
  == Testing and validation ==
  This issue has been tested against the older OpenStack Victoria release and the newer Xena release. I've also reviewed existing CVE's to identify if this issue has previously been reported. However, I've only come across https://www.cve.org/CVERecord?id=CVE-2018-20170 which refers to the time based user account enumeration of the API endpoint for tokens.
  
  == Recommendation ==
  I've tried to find the issue in the source code but I was unable to find the library 'Django.contrib.auth' that has the 'authenticate' function. Link -> https://github.com/openstack/horizon/blob/a95d703c98484bda8588aa2eeb89fff1f52dc81e/openstack_auth/forms.py#L140
  
  I've encountered this sort of security vulnerability before, and culprit
  is often the pseudo logic:
  
  - query the provided username.
  - if username exists in database, hash the password and compare the hashes
  - if not, return
  
  This adds the computational functionality only when a correctly guessed
  user account is queried, in which it's better to always perform a hash
  of the password to mimic real requests - and if it's not possible to
  retrieve a hash salt for the user since there's no valid lookup of a
  user, a fake and random could be used instead.
  
  Adding random or fixed asynchronous "sleeps" for each login is also
  possible, but I personally recommend just mimicing valid calls (as
  described above) instead.
  
  I also recommend publishing this as a CVE, especially since this has
  been confirmed to be applicable in a very old version and a newer one. I
  would classify the severity as low, since it's a user account
  enumeration vulnerability.
  
  If you're willing to add credits for the finding and reporting I'd
  appreciate if you said it was found by Hannes Michel at Basalt IT-
  security team.
  
  Best regards and I appreciate the work by you guys with maintaining
  OpenStack!

** Information type changed from Private Security to Public

** Tags added: security

** Changed in: ossa
       Status: Incomplete => Won't Fix

** Also affects: horizon
   Importance: Undecided
       Status: New

-- 
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/2111402

Title:
  Time based user account enumeration with POST to /auth/login

Status in OpenStack Dashboard (Horizon):
  New
Status in OpenStack Identity (keystone):
  New
Status in OpenStack Security Advisory:
  Won't Fix

Bug description:
  == Description ==
  An attacker is able to identify local user accounts to OpenStack by performing continuous POST requests to the endpoint /auth/login and comparing the response times. Valid users have about the double or more in terms of response time, making it easier to accomplish account compromise via password guessing or bruteforce.

  The request I've sent also had the following POST data:

  csrfmiddlewaretoken=jEk6xHFxFoKHZ1OpPTZBGf0ZIAXkh6EJuRveiaL11Ho8E2uOiR0PXRrETkhPW28c&fake_email=&fake_password=&region=default&username=<GUESSED_USERNAME>&password=bogus

  == Testing and validation ==
  This issue has been tested against the older OpenStack Victoria release and the newer Xena release. I've also reviewed existing CVE's to identify if this issue has previously been reported. However, I've only come across https://www.cve.org/CVERecord?id=CVE-2018-20170 which refers to the time based user account enumeration of the API endpoint for tokens.

  == Recommendation ==
  I've tried to find the issue in the source code but I was unable to find the library 'Django.contrib.auth' that has the 'authenticate' function. Link -> https://github.com/openstack/horizon/blob/a95d703c98484bda8588aa2eeb89fff1f52dc81e/openstack_auth/forms.py#L140

  I've encountered this sort of security vulnerability before, and
  culprit is often the pseudo logic:

  - query the provided username.
  - if username exists in database, hash the password and compare the hashes
  - if not, return

  This adds the computational functionality only when a correctly
  guessed user account is queried, in which it's better to always
  perform a hash of the password to mimic real requests - and if it's
  not possible to retrieve a hash salt for the user since there's no
  valid lookup of a user, a fake and random could be used instead.

  Adding random or fixed asynchronous "sleeps" for each login is also
  possible, but I personally recommend just mimicing valid calls (as
  described above) instead.

  I also recommend publishing this as a CVE, especially since this has
  been confirmed to be applicable in a very old version and a newer one.
  I would classify the severity as low, since it's a user account
  enumeration vulnerability.

  If you're willing to add credits for the finding and reporting I'd
  appreciate if you said it was found by Hannes Michel at Basalt IT-
  security team.

  Best regards and I appreciate the work by you guys with maintaining
  OpenStack!

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