Scoutsuite: IAM permissions in 5.8.0

[heydonovan]

We just upgraded our GitLab pipeline from 5.7.0 to 5.8.0. Here is the command we run:

$ python scout.py aws --debug --regions us-east-1

2020-03-23 23:32:36 runner-yleyvanw-project-17614511-concurrent-0j57gz scout[14] ERROR kms.py L40: Failed to get KMS key rotation: An error occurred (AccessDeniedException) when calling the GetKeyRotationStatus operation: User: arn:aws:sts::12345:assumed-role/scout-suite-gitlab-runner/1dfd2e18-scout-suite-gitlab-runner is not authorized to perform: kms:GetKeyRotationStatus on resource: arn:aws:kms:us-east-1:12345:key/REDACTED
Traceback (most recent call last):
  File "/builds/thezebra/infrastructure/scout-suite/ScoutSuite/providers/aws/facade/kms.py", line 40, in _get_and_set_key_rotation_status
    key['rotation_status'] = await run_concurrently(
  File "/builds/thezebra/infrastructure/scout-suite/ScoutSuite/providers/utils.py", line 24, in run_concurrently
    return await run_function_concurrently(function)
  File "/usr/local/lib/python3.8/concurrent/futures/thread.py", line 57, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/builds/thezebra/infrastructure/scout-suite/ScoutSuite/providers/aws/facade/kms.py", line 41, in <lambda>
    lambda: client.get_key_rotation_status(KeyId=key['KeyId']))
  File "/usr/local/lib/python3.8/site-packages/botocore/client.py", line 316, in _api_call
    return self._make_api_call(operation_name, kwargs)
  File "/usr/local/lib/python3.8/site-packages/botocore/client.py", line 626, in _make_api_call
    raise error_class(parsed_response, operation_name)
botocore.exceptions.ClientError: An error occurred (AccessDeniedException) when calling the GetKeyRotationStatus operation: User: arn:aws:sts::12345:assumed-role/scout-suite-gitlab-runner/1dfd2e18-scout-suite-gitlab-runner is not authorized to perform: kms:GetKeyRotationStatus on resource: arn:aws:kms:us-east-1:12345:key/REDACTED

This seems to be out-of-date: https://github.com/nccgroup/ScoutSuite/wiki/AWS-Minimal-Privileges-Policy - We gave our role two policies, ReadOnlyAccess and SecurityAudit as per: https://github.com/nccgroup/ScoutSuite/wiki/Amazon-Web-Services#permissions

We also cleaned up a bunch of s3 buckets, and ran into these issues. Do you think this is another instance of one resource referencing a non-existent one that AWS lets us do?

2020-03-23 23:30:27 runner-gx478rji-project-17614511-concurrent-0zb2h9 scout[15] ERROR s3.py L43: Failed to get bucket location for deploy-notifications-serverless-deployments: An error occurred (NoSuchBucket) when calling the GetBucketLocation operation: The specified bucket does not exist
Traceback (most recent call last):
  File "/builds/company/infrastructure/scout-suite/ScoutSuite/providers/aws/facade/s3.py", line 43, in _get_and_set_s3_bucket_location
    location = await run_concurrently(lambda: client.get_bucket_location(Bucket=bucket['Name']))
  File "/builds/company/infrastructure/scout-suite/ScoutSuite/providers/utils.py", line 24, in run_concurrently
    return await run_function_concurrently(function)
  File "/usr/local/lib/python3.8/concurrent/futures/thread.py", line 57, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/builds/company/infrastructure/scout-suite/ScoutSuite/providers/aws/facade/s3.py", line 43, in <lambda>
    location = await run_concurrently(lambda: client.get_bucket_location(Bucket=bucket['Name']))
  File "/usr/local/lib/python3.8/site-packages/botocore/client.py", line 316, in _api_call
    return self._make_api_call(operation_name, kwargs)
  File "/usr/local/lib/python3.8/site-packages/botocore/client.py", line 626, in _make_api_call
    raise error_class(parsed_response, operation_name)
botocore.errorfactory.NoSuchBucket: An error occurred (NoSuchBucket) when calling the GetBucketLocation operation: The specified bucket does not exist
2020-03-23 23:30:27 runner-gx478rji-project-17614511-concurrent-0zb2h9 scout[15] ERROR s3.py L43: Failed to get bucket location for application-serverless-files: An error occurred (NoSuchBucket) when calling the GetBucketLocation operation: The specified bucket does not exist
Traceback (most recent call last):
  File "/builds/company/infrastructure/scout-suite/ScoutSuite/providers/aws/facade/s3.py", line 43, in _get_and_set_s3_bucket_location
    location = await run_concurrently(lambda: client.get_bucket_location(Bucket=bucket['Name']))
  File "/builds/company/infrastructure/scout-suite/ScoutSuite/providers/utils.py", line 24, in run_concurrently
    return await run_function_concurrently(function)
  File "/usr/local/lib/python3.8/concurrent/futures/thread.py", line 57, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/builds/company/infrastructure/scout-suite/ScoutSuite/providers/aws/facade/s3.py", line 43, in <lambda>
    location = await run_concurrently(lambda: client.get_bucket_location(Bucket=bucket['Name']))
  File "/usr/local/lib/python3.8/site-packages/botocore/client.py", line 316, in _api_call
    return self._make_api_call(operation_name, kwargs)
  File "/usr/local/lib/python3.8/site-packages/botocore/client.py", line 626, in _make_api_call
    raise error_class(parsed_response, operation_name)
botocore.errorfactory.NoSuchBucket: An error occurred (NoSuchBucket) when calling the GetBucketLocation operation: The specified bucket does not exist

[x4v13r64]

This seems to be out-of-date

You're getting an error when calling kms:GetKeyRotationStatus, which is indeed in https://github.com/nccgroup/ScoutSuite/wiki/AWS-Minimal-Privileges-Policy, so [this time!] it doesn't look to be the issue.

We gave our role two policies, ReadOnlyAccess and SecurityAudit

Both arn:aws:iam::aws:policy/SecurityAudit and arn:aws:iam::aws:policy/ReadOnlyAccess has "kms:Get*", so that's not it either.

The issue is most likely that the resource-based policy on those keys disallows access to the principal you're running scout with. Please refer to https://docs.aws.amazon.com/kms/latest/developerguide/control-access-overview.html.

We also cleaned up a bunch of s3 buckets, and ran into these issues. Do you think this is another instance of one resource referencing a non-existent one that AWS lets us do?

Could be, can you confirm that these resources previously existed but have since been deleted? Might be a question of waiting a bit.

[alock]

My team has the same issue with KMS, and our role has kms:GetKeyRotationStatus on resources *. It looks like you cannot get the key rotation status of an AWS managed key even with an admin role.

[heydonovan]

Ahh, right. The key has a policy with the following, which doesn't include the CI/CD role.

{
    "Version": "2012-10-17",
    "Id": "key-default-1",
    "Statement": [
        {
            "Sid": "Enable IAM User Permissions",
            "Effect": "Allow",
            "Principal": {
                "AWS": [
                    "arn:aws:iam::12345:root",
                    "arn:aws:iam::12345:role/REDACTED"
                ]
            },
            "Action": "kms:*",
            "Resource": "*"
        }
    ]
}

[x4v13r64]

My team has the same issue with KMS, and our role has kms:GetKeyRotationStatus on resources *. It looks like you cannot get the key rotation status of an AWS managed key even with an admin role.

Did you read my above comment?

Again, see https://docs.aws.amazon.com/kms/latest/developerguide/control-access-overview.html#managing-access.

[x4v13r64]

                "arn:aws:iam::12345:root",

This bit actually means that there are no restrictions at the resource level on who can access the key.

From https://docs.aws.amazon.com/kms/latest/developerguide/key-policies.html#key-policy-default:

_When you create a CMK programmatically you have the option of providing the key policy for the new CMK. If you don't provide one, AWS KMS creates one for you. This default key policy has one policy statement that gives the AWS account (root user) that owns the CMK full access to the CMK and enables IAM policies in the account to allow access to the CMK._

[alock]

@j4v - I have to do some more digging but the keys we are dealing with were not created by us the "customer" they are AWS managed keys which are created by AWS for specific services (aws/sns, aws/codecommit, aws/cloud9, aws/dynamodb, aws/lambda, aws/fsx, aws/rds, aws/ssm, aws/backup, aws/lightsail).

Some of them allow for getting info on key rotations status some of them don't. I am a little concerned with modifying the policy since this is defined by AWS.

[JLLeitschuh]

I'm running into the same issue. Is this an issue with AWS not assigning the right role to the keys by default? Or is this an intentional decision. If AWS is intentionally not including newly generated keys in the scope of the two AWS permissions that scousuite needs, shouldn't scout skip them?

Barring that, is there some simple way to disable this rule but leave the rest in place? I'd like to not have to create a full custom ruleset to disable one default rule.

[x4v13r64]

@JLLeitschuh this is not an issue, it's just how KMS resource-based policies work. See above.

If you don't want to scan the KMS service then use the --skip kms command.

[alock]

It seems strange that we are checking the rotation policy of an AWS managed KMS key. I want to keep the kms checks for customer managed keys not AWS managed keys.

[munntjlx]

Is this fixed in newest version? v 5.10?

[x4v13r64]

@munntjlx we removed the check for rotation on AWS managed keys if that's what you're asking. Scout might still output some errors for CMKs if it's run by a principal that doesn't have access to those keys, but that's expected.