CVE-2024-37293

Executive Summary

CVE-2024-37293 is a privilege escalation vulnerability in the AWS Deployment Framework (ADF), a tool for managing multi-account AWS deployments. The vulnerability resides in the bootstrap process, where a CodeBuild project or Lambda function is granted the sts:AssumeRole permission without restrictions. An attacker with permissions to modify the CodeBuild project or Lambda function can assume any role in any AWS account within the organization, leading to full administrative control. The CVSS score is 7.6 (High), and the vulnerability affects versions prior to 4.0.0. The official patch is included in version 4.0.0, and a temporary mitigation involves adding a permissions boundary to deny IAM and STS actions.

Supply Chain & Package Security

This vulnerability is not related to a package manager (NPM, PyPI, Go, Ruby) but is specific to the AWS Deployment Framework (ADF) infrastructure-as-code tool. The risk is in the bootstrap process, which is a core component of ADF's deployment pipeline.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
• Base Score: 7.6 (High)
• Attack Vector: Network (AV:N) – The attack can be launched remotely.
• Attack Complexity: Low (AC:L) – No special conditions are required.
• Privileges Required: Low (PR:L) – The attacker needs permissions to modify the CodeBuild project or Lambda function.
• User Interaction: None (UI:N) – No user action is required.
• Scope: Unchanged (S:U) – The vulnerability does not cross security boundaries.
• Confidentiality Impact: High (C:H) – Full access to all AWS resources.
• Integrity Impact: High (I:H) – Ability to modify or delete resources.
• Availability Impact: High (A:H) – Potential for denial of service.

Threat Level: High. The vulnerability allows an attacker with limited permissions to escalate to full administrative access across all AWS accounts in the organization.

Deep Dive & Mechanics

The AWS Deployment Framework (ADF) uses a bootstrap process to set up cross-account deployment pipelines. This process involves either a CodeBuild project (code-change driven) or a Lambda function (event-driven). Both are granted the sts:AssumeRole permission to assume roles in other AWS accounts.

Root Cause: The bootstrap CodeBuild role (or Lambda execution role) is granted sts:AssumeRole without any restrictions (e.g., no Resource or Condition constraints). This means the role can assume any role in any AWS account within the organization. By default, the cross-account access role created by AWS Organizations provides AdministratorAccess, giving full control over the target account.

Attack Flow:

1. An attacker gains permissions to modify the CodeBuild project or Lambda function (e.g., via IAM policy misconfiguration or compromised credentials).
2. The attacker modifies the CodeBuild project to execute a malicious build that calls sts:AssumeRole to assume the cross-account admin role in another account.
3. The attacker now has administrative access to the target account and can perform any action (e.g., exfiltrate data, deploy backdoors, destroy resources).

Affected Components:

• CodeBuild project used in the bootstrap pipeline.
• Lambda function used in the event-driven bootstrap process.
• The sts:AssumeRole permission granted to these roles.

Vulnerable vs. Patched Code

Vulnerable Code (Pre-4.0.0): The IAM policy for the bootstrap CodeBuild role includes a broad sts:AssumeRole permission:

{
  "Effect": "Allow",
  "Action": "sts:AssumeRole",
  "Resource": "*"
}

This allows assuming any role in any account.

Patched Code (4.0.0+): The policy is restricted to specific roles and accounts:

{
  "Effect": "Allow",
  "Action": "sts:AssumeRole",
  "Resource": "arn:aws:iam::*:role/ADF-*",
  "Condition": {
    "StringEquals": {
      "aws:ResourceAccount": "${aws:PrincipalAccount}"
    }
  }
}

This limits the AssumeRole action to roles with the ADF- prefix and only within the same account.

Exploitation & Lab Setup

Red Team (Exploitation)

Prerequisites:

• Access to an AWS account with permissions to modify the ADF CodeBuild project or Lambda function.
• Knowledge of the target account ID and the cross-account role name (default: OrganizationAccountAccessRole).

Exploitation Steps:

1. Identify the Bootstrap CodeBuild Project:
   • Use AWS CLI: aws codebuild list-projects --query "projects[?contains(@, 'adf-bootstrap')]"
2. Modify the Buildspec:
   • Update the CodeBuild project to run a malicious buildspec that assumes the target role:

   version: 0.2
   phases:
     build:
       commands:
         - aws sts assume-role --role-arn "arn:aws:iam::TARGET_ACCOUNT_ID:role/OrganizationAccountAccessRole" --role-session-name "ExploitSession"
   

3. Trigger the Build:
   • Start the build: aws codebuild start-build --project-name <project-name>
4. Use the Temporary Credentials:
   • The build output will contain AccessKeyId, SecretAccessKey, and SessionToken. Use these to access the target account.

Alternative Lambda Exploitation:

• Modify the Lambda function code to include the same sts:AssumeRole call and invoke it.

Blue Team (Defense)

Detection:

• Monitor CloudTrail for sts:AssumeRole calls from the ADF bootstrap role to unusual accounts.
• Alert on modifications to CodeBuild projects or Lambda functions that are part of the ADF bootstrap process.
• Use AWS Config rules to detect overly permissive IAM policies.

Hunting:

• Query CloudTrail logs for AssumeRole events where the userIdentity.arn matches the ADF bootstrap role ARN.
• Look for UpdateProject or UpdateFunctionConfiguration API calls on ADF-related resources.

Lab Setup:

1. Deploy ADF version 3.x in a test AWS Organization.
2. Create a separate "attacker" IAM user with permissions to modify CodeBuild projects.
3. Follow the Red Team steps to escalate privileges.
4. Monitor CloudTrail and set up alerts to detect the attack.

Indicators of Compromise (IOCs)

• CloudTrail Events:
  • AssumeRole API calls from the ADF bootstrap role to roles in other accounts.
  • UpdateProject or UpdateFunctionConfiguration API calls on ADF bootstrap resources.
• IAM Policy Changes:
  • Modification of the bootstrap role's policy to include sts:AssumeRole with Resource: "*".
• Suspicious Buildspecs:
  • CodeBuild projects with buildspecs containing sts:AssumeRole commands.
• Network Traffic:
  • API calls to sts.amazonaws.com from the ADF bootstrap role to unusual regions or accounts.

Detection Engineering

YARA Rule

rule CVE_2024_37293_ADF_PrivEsc {
    meta:
        description = "Detects overly permissive sts:AssumeRole in ADF bootstrap IAM policies"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2024-37293"
    strings:
        $s1 = "sts:AssumeRole" ascii wide nocase
        $s2 = "\"Resource\": \"*\"" ascii wide
    condition:
        all of them
}

Sigma Rule

title: ADF Bootstrap Role AssumeRole to External Account
id: 8f3b2a1c-5d7e-4f9b-8a2c-1e3d5f7a9b0c
status: experimental
description: Detects sts:AssumeRole calls from ADF bootstrap role to accounts outside the management account
author: Valters IT
date: 2025-04-10
logsource:
    product: aws
    service: cloudtrail
detection:
    selection:
        eventSource: sts.amazonaws.com
        eventName: AssumeRole
        userIdentity.arn: "*adf-bootstrap*"
    condition: selection
falsepositives:
    - Legitimate ADF cross-account deployments
level: high

Suricata Rule

alert tcp $HOME_NET any -> $EXTERNAL_NET 443 (msg:"CVE-2024-37293 ADF Bootstrap Role AssumeRole"; flow:to_server,established; content:"sts.amazonaws.com"; http_host; content:"AssumeRole"; http_uri; classtype:attempted-admin; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Mitigation:

• Add a permissions boundary to the roles created by ADF in the management account. The boundary should deny all IAM and STS actions:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "iam:*",
        "sts:*"
      ],
      "Resource": "*"
    }
  ]
}

• Note: This will disable ADF's ability to create, manage, and bootstrap accounts until the patch is applied.

Permanent Fix:

• Upgrade to ADF version 4.0.0 or later.
• After upgrading, remove the temporary permissions boundary.

Long-Term Recommendations:

• Implement least privilege for all IAM roles, especially those used in CI/CD pipelines.
• Use AWS IAM Access Analyzer to identify overly permissive policies.
• Enable AWS CloudTrail and set up alerts for suspicious sts:AssumeRole activity.
• Regularly review and audit IAM roles and policies.

Valters IT Signature

Report generated by Valters IT DevSecOps AI Assistant. For questions, contact security@valters-it.com.