Comment 20 for bug 1618615

Replying by email because my 2FA has broken and I can't log into LP.

I agree that documentation enhancements would be useful. Luke we could
consider rolling this enhanced guidance into an OSSN but I share your
concerns about posting something without a clear fix/workaround.

-Rob

On Wed, May 24, 2017 at 3:58 PM, Charles Neill <email address hidden>
wrote:

> The main thing that I think would help is updating the documentation to
> include more reasonable examples. As stated above, I think the examples
> provided in the docs increase the risk of someone storing
> sensitive/easily guessed information where it could be exposed by this
> vector.
>
> --
> You received this bug notification because you are a member of OSSG
> CoreSec, which is subscribed to the bug report.
> https://bugs.launchpad.net/bugs/1618615
>
> Title:
> Potential information disclosure in EC2 "credentials"
>
> Status in OpenStack Identity (keystone):
> New
> Status in OpenStack Security Advisory:
> Won't Fix
> Status in OpenStack Security Notes:
> New
>
> 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://github.com/openstack/keystone/blob/master/keystone/
> credential/controllers.py#L36-L60)
>
> ===== EXAMPLE REQUEST =====
>
> POST /v3/credentials HTTP/1.1
> Host: [ENDPOINT]
> X-Auth-Token: [ADMIN TOKEN]
> Content-Length: 231
> Content-Type: application/json
>
> {
> "credential": {
> "blob": "{\"access\":\"<script>alert(
> 2)</script>\",\"secret\":\"secretKey\"}",
> "project_id": "12345",
> "type": "ec2",
> "user_id": "12345"
> }
> }
>
> 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]/v3/credentials/141ce7a938b5973dd71c90bcdd7e40
> 97317ee7374259cf6d8774fdfd86c1f8ea"},
> "blob":
> "{\"access\":\"<script>alert(2)</script>\",\"secret\":\"secretKey\"}",
> "project_id": "12345", "type": "ec2", "id":
> "141ce7a938b5973dd71c90bcdd7e4097317ee7374259cf6d8774fdfd86c1f8ea"}}
>
> ===== /EXAMPLE =====
>
> The id from the example above is
> "141ce7a938b5973dd71c90bcdd7e4097317ee7374259cf6d8774fdfd86c1f8ea",
> which is the same as the SHA256 value of "<script>alert(2)</script>"
> (you can test this with `echo -n "<script>alert(2)</script>" | openssl
> dgst -sha256` on *nix)
>
> The documentation here seems to show MD5s and possibly tenant IDs used
> as "access" values: http://developer.openstack.org/api-
> ref/identity/v3/?expanded=assign-role-to-user-on-projects-owned-by-
> domain-detail,create-policy-detail,show-credential-details-detail
> ,list-credentials-detail,create-credential-detail#list-credentials
>
> 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) = 21232f297a57a5a743894a0e4a801fc3
> sha256(21232f297a57a5a743894a0e4a801fc3) =
> 465c194afb65670f38322df087f0a9bb225cc257e43eb4ac5a0c98ef5b3173ac
>
> 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/141ce7a938b5973dd71c90bcdd7e40
> 97317ee7374259cf6d8774fdfd86c1f8ea HTTP/1.1
> 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:get_credential", "code": 403, "title":
> "Forbidden"}}
>
> Non-existent credential
>
> GET /v3/credentials/deadbeef HTTP/1.1
> 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
>
> {
> "credential": {
> "blob": "{\"access\":\"\uffff\",\"secret\":\"secretKey\"}",
> "project_id": "12345",
> "type": "ec2",
> "user_id": "12345"
> }
> }
>
> 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://docs.aws.amazon.com/AWSSimpleQueueService/latest/
> SQSGettingStartedGuide/AWSCredentials.html
> ), it would require a huge number of requests to bruteforce the access
> key (though it would not be impossible). However, it would be
> possible, using the approach described above with a regular user
> token, to determine whether a known EC2 access key was in place as a
> credential in a given Keystone database.
>
> I'm unclear on the utility of using SHA256 for the identifier at all
> here, since random UUIDs would make this potential issue moot.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/keystone/+bug/1618615/+subscriptions
>