| 2018-10-03 06:40:49 |
Andy Ngo |
bug |
|
|
added bug |
| 2018-10-03 07:07:33 |
Andy Ngo |
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 |
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. |
|
| 2018-10-03 12:19:29 |
Jeremy Stanley |
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. |
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. |
|
| 2018-10-03 12:19:39 |
Jeremy Stanley |
bug task added |
|
ossa |
|
| 2018-10-03 12:19:47 |
Jeremy Stanley |
ossa: status |
New |
Incomplete |
|
| 2018-10-03 12:20:10 |
Jeremy Stanley |
bug |
|
|
added subscriber Keystone Core security contacts |
| 2018-10-03 17:33:22 |
Jeremy Stanley |
cve linked |
|
2018-15473 |
|
| 2018-10-03 17:42:38 |
Jeremy Stanley |
cve unlinked |
2018-15473 |
|
|
| 2018-10-03 18:14:37 |
Jeremy Stanley |
information type |
Private Security |
Public |
|
| 2018-10-03 18:14:45 |
Jeremy Stanley |
ossa: status |
Incomplete |
Won't Fix |
|
| 2018-10-03 18:14:56 |
Jeremy Stanley |
tags |
|
security |
|
| 2018-10-24 18:00:40 |
Morgan Fainberg |
keystone: status |
New |
Won't Fix |
|
| 2018-10-25 14:20:03 |
Colleen Murphy |
keystone: status |
Won't Fix |
Triaged |
|
| 2018-10-25 14:20:08 |
Colleen Murphy |
keystone: importance |
Undecided |
Wishlist |
|
| 2018-12-10 02:19:10 |
Jeremy Stanley |
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. |
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. |
|
| 2018-12-17 08:10:27 |
Andy Ngo |
cve linked |
|
2018-20170 |
|
| 2018-12-17 14:07:43 |
Jeremy Stanley |
summary |
Username enumeration via response timing difference |
Timing oracle in core auth plugin simplifies brute-forcing usernames |
|
| 2018-12-17 19:53:39 |
OpenStack Infra |
keystone: status |
Triaged |
In Progress |
|
| 2018-12-17 19:53:39 |
OpenStack Infra |
keystone: assignee |
|
Gage Hugo (gagehugo) |
|
| 2018-12-17 19:58:56 |
Lance Bragstad |
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. |
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 recognizable with a good sample size. |
|
| 2020-03-18 14:42:29 |
Gage Hugo |
keystone: assignee |
Gage Hugo (gagehugo) |
|
|
| 2020-03-18 14:42:51 |
Gage Hugo |
keystone: status |
In Progress |
Triaged |
|
