Potential information disclosure in EC2 "credentials"
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Identity (keystone) |
Triaged
|
Low
|
Unassigned | ||
OpenStack Security Advisory |
Won't Fix
|
Undecided
|
Unassigned | ||
OpenStack Security Notes |
Won't Fix
|
Undecided
|
Unassigned |
Bug Description
When creating a "credential" in Keystone, instead of using uuid.uuid4() like in most places to generate a unique identifier, the id is created from the SHA256 hash value of whatever is passed in as the "access" key in the POST request (Code here: https:/
===== EXAMPLE REQUEST =====
POST /v3/credentials HTTP/1.1
Host: [ENDPOINT]
X-Auth-Token: [ADMIN TOKEN]
Content-Length: 231
Content-Type: application/json
{
"blob": "{\"access\
"type": "ec2",
}
}
HTTP/1.1 201 Created
Date: Tue, 30 Aug 2016 19:14:54 GMT
Server: Apache/2.4.7 (Ubuntu)
Vary: X-Auth-Token
Content-Length: 383
Content-Type: application/json
{"credential": {"user_id": "12345", "links": {"self": "[ENDPOINT]
===== /EXAMPLE =====
The id from the example above is "141ce7a938b597
The documentation here seems to show MD5s and possibly tenant IDs used as "access" values: http://
Bruteforcing an actual MD5 isn't a huge security risk (i.e. trying to predict all 32 characters from thin air), but if the MD5 is a hash of a known value (i.e. the string "admin"), it would be trivial to test for common values:
md5(admin) = 21232f297a57a5a
sha256(
If tenant IDs are used, this task becomes even easier: just generate SHA256 hashes for 0 - 999999
A non-admin user can determine whether there are credentials using a given access key by attempting to access the resource from its sha256 url identifier:
===== EXAMPLE REQUESTS =====
Existing credential
GET /v3/credentials
Host: [ENDPOINT]
X-Auth-Token: [NON-ADMIN TOKEN]
Content-Type: application/json
Connection: close
HTTP/1.1 403 Forbidden
Date: Tue, 30 Aug 2016 19:55:24 GMT
Server: Apache/2.4.7 (Ubuntu)
Vary: X-Auth-Token
Content-Length: 140
Content-Type: application/json
{"error": {"message": "You are not authorized to perform the requested action: identity:
Non-existent credential
GET /v3/credentials
Host: [ENDPOINT]
X-Auth-Token: [NON-ADMIN TOKEN]
Content-Type: application/json
HTTP/1.1 404 Not Found
Date: Tue, 30 Aug 2016 20:03:38 GMT
Server: Apache/2.4.7 (Ubuntu)
Vary: X-Auth-Token
Content-Length: 96
Content-Type: application/json
{"error": {"message": "Could not find credential: deadbeef", "code": 404, "title": "Not Found"}}
===== /EXAMPLE =====
It is also possible to get a 500 error by creating a credential with an invalid character in the "access" key:
===== EXAMPLE REQUEST =====
POST /v3/credentials HTTP/1.1
Host: [ENDPOINT]
X-Auth-Token: [ADMIN TOKEN]
Content-Length: 212
Content-Type: application/json
{
"blob": "{\"access\
"type": "ec2",
}
}
HTTP/1.1 500 Internal Server Error
Date: Tue, 30 Aug 2016 20:06:16 GMT
Server: Apache/2.4.7 (Ubuntu)
Vary: X-Auth-Token
Content-Length: 143
Content-Type: application/json
{"error": {"message": "An unexpected error prevented the server from fulfilling your request.", "code": 500, "title": "Internal Server Error"}}
===== /EXAMPLE =====
I'm unsure what the security impact would be here, mainly because of the ambiguous examples provided in the Keystone API documentation (linked above). If either of the 2 scenarios I outlined is a reasonable use case (i.e. MD5 of a guessable value, or tenant IDs), there may be a risk of information leakage by brute-force. It would also be possible to prevent others from creating credentials with a given access key by simply creating lots of credentials in Keystone with predictable access keys. This would cause a collision whenever attempting to create a credential set with an access key that has already been used.
If, on the other hand, the credentials are always in the format described by AWS here ( link: https:/
I'm unclear on the utility of using SHA256 for the identifier at all here, since random UUIDs would make this potential issue moot.
tags: | added: security |
information type: | Public Security → Public |
Since this report concerns a possible security risk, an incomplete security advisory task has been added while the core security reviewers for the affected project or projects confirm the bug and discuss the scope of any vulnerability along with potential solutions.