Imagine configuring your AWS with pre-set policies, thinking you’ve secured your cloud environment, only to discover subtle misconfigurations that expose you to unforeseen vulnerabilities. AWS does offer a range of managed policies, aiming to provide ready-to-use configurations for various use cases. But can we trust them blindly? Let’s delve into the hidden risks and potential missteps lurking within some popular AWS managed policies and explore ways to secure our cloud effectively.
Some managed AWS policies are considered harmful
Assuming you genuinely intend to grant unrestricted permissions to the account (assuming there are no service control policies in the organization), this managed policy is acceptable. The policy itself is quite straightforward:
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "*",
"Resource": "*"
}
]
}Since its inception in 2015, AWS has never updated this policy. It’s challenging to restrict this policy with permission boundaries due to the potential to overlook an IAM edge case.
For instance, if you place a boundary for this admin to solely manage their own access keys via a Condition element, this admin could still create a new user and manage the new user’s access keys. They could also assume any available role in the organization to evade their restriction.
AmazonEC2ContainerServiceforEC2Role Policy
This AWS-managed policy is attached to EC2 instances running ECS containers. If you don’t specify an explicit task role, the containers will also use this policy. If a container is compromised, an attacker could deregister all your container instances.
In such situations, always utilize explicit task roles to limit container permissions. Additionally, follow the AWS documentation instructions to prevent the container from inheriting EC2 permissions.
AmazonS3FullAccess Policy
This frequently used policy grants s3:* access (on all resources!). If you operate in governance mode, this policy also includes s3:BypassGovernanceRetention, potentially leading to data loss in other buckets if an identity with this policy is compromised.
AmazonElasticTranscoderFullAccess Policy
AWS misconfigured this policy, resulting in privilege escalation. It was deprecated soon after. The problem was that it allowed iam:PutRolePolicy on all resources, essentially allowing roles to modify their own inline policies on their role (enabling them to escalate their permissions to root permissions).
ReadOnlyAccess Policy
Some audit systems require read-only access to your AWS account to collect data and analyze the account. The ReadOnlyAccess policy is often employed for this purpose, but it has its drawbacks and potential security risks. Two of these are highlighted below.
This might be one of the riskiest policies you can apply in AWS.
The policy has several versions and is constantly updated
When AWS alters the policy and designates the new policy as the default, the change is instantly applied to all identities with the policy.
This implies that read-only permission could be granted to new services, providing more access than originally intended when the policy was assigned. This contradicts the principle of granting identities only the necessary privileges for their tasks.
The policy provides access to potential customer data
Some granted permissions include:
• s3:Get* – Allows access to all S3 buckets and their objects, unless a custom KMS key encrypts the objects in the bucket (or if a bucket policy denies this specific user access).
• ssm:GetParameter(s): Grants access to secrets in the secrets manager, such as database passwords and other confidential variables.
• apigateway:GET: Enables the identity to call internal API gateway URLs.
• ecr:GetAuthorizationToken: Retrieves a token to pull private images from the ECR registry.
This list is not exhaustive because there are also many other unexpected permissions that might arise with this policy. Technically, all these actions are read-only, but some can result in significant data leaks.
Potential Solutions
There have been instances where AWS has incorrectly granted broad access with their managed policies. There’s even a dedicated repository tracking these changes, complete with a ‘hall of fails‘.
AWS policies typically fall into two categories:
• They are excessively permissive, leading to security issues if compromised.
• They might be poorly managed, out of date, and can cause unforeseen side effects.
Two solutions to these problems exist. You could utilize a permission boundary in conjunction with these policies, but the issue remains that AWS controls the policy, potentially exposing you to unexpected security vulnerabilities.
For example, if you assigned the read-only policy to a user three years ago and verified all their permissions, this user might now have elevated permissions that you’re unaware of as the default policy has changed.
The only proper solution is to create your IAM policies from scratch using infrastructure automation tools like Terraform or CloudFormation. This aligns with the principle of least privilege. The AWS Policy Generator makes it easy to construct a policy.
If you’re currently using the ReadOnlyPolicy or another AWS-managed policy, consider using IAM Access Advisor to verify the required permissions for this user or role.
Follow these steps:
- Navigate to the user with the managed policy.
- Click Access Advisor.
- Filter on Services Accessed.
Create new self-managed policies with only the permissions this identity requires. If you need more details on specific calls so you can add a Condition element, examine your CloudTrail logs.
You’ll then have to consider the required permissions for a service, and permissions will only escalate if you alter the policy through manual or automated action. If you’re uncertain about the explicit permissions a service needs, you can assign a permissive policy for a limited time and then analyse the required permissions via CloudTrail or IAM access advisor.
In essence: Always prefer self-managed policies over AWS-managed ones, or ensure you understand the potential drawbacks of these policies.