How Misconfigured Trust Policies in AWS Amplify and AppSync Enable Cross-Account Takeover

TLDR: Recent research into AWS identity-based attacks reveals how misconfigured trust policies in AWS Amplify and AppSync can be weaponized to perform cross-account resource access. By exploiting a confused deputy vulnerability, an attacker can manipulate IAM roles to gain unauthorized access to sensitive data in a victim's account. Security teams should immediately audit their IAM roles for overly permissive trust policies and implement condition keys like aws:SourceAccount to restrict access to trusted entities.

Cloud security often feels like a game of whack-a-mole where the moles are just different versions of the same identity-based misconfiguration. We spend our time hunting for leaked access keys or exposed S3 buckets, but the real danger lies in the subtle, systemic flaws in how cloud services trust one another. At Black Hat 2024, Nick Frichette presented a masterclass on how to move beyond the low-hanging fruit and exploit the trust relationships that underpin modern serverless architectures.

The Confused Deputy in the Cloud

The core of this research centers on the confused deputy problem, a classic security failure where a privileged entity is tricked into performing an action on behalf of an unauthorized user. In the context of AWS, this happens when an IAM role has a trust policy that allows a service to assume it, but fails to restrict which specific resources or accounts that service can act upon.

When you create an AWS AppSync API, the service automatically generates an IAM role to manage data sources. By default, this role trusts the AppSync service. If that trust policy is not explicitly scoped, an attacker who can influence the configuration of an AppSync API in their own account can potentially trick the service into assuming a role in a victim's account.

The research highlights a fascinating technical nuance: AWS APIs are often case-sensitive, but in the case of AppSync, the API was not. By simply changing the casing of a JSON parameter, an attacker could bypass validation checks that were intended to prevent cross-account role assumption. This is a perfect example of why developers should never rely on client-side or API-level validation as a security boundary.

Weaponizing AWS Amplify

AWS Amplify is designed to abstract away the complexity of backend infrastructure, which is a massive productivity win for developers but a potential nightmare for security. The research identified that Amplify projects, when configured with certain authentication settings, would generate IAM roles with vulnerable trust policies.

Specifically, these roles were created with a trust policy that allowed the sts:AssumeRoleWithWebIdentity action without a strict condition key. This effectively meant that any entity capable of generating a token from a public identity provider could assume the role. The vulnerability was so widespread that it was assigned CVE-2024-28056.

To find these vulnerable roles in the wild, the research team used Sourcegraph to search public GitHub repositories for specific IAM role naming conventions. By searching for patterns like authRole or unauthRole alongside the team-provider-info.json file, they identified thousands of potentially exposed roles. This is a powerful technique for any bug bounty hunter or red teamer looking to map the attack surface of a target organization.

The Power of Condition Keys

The fix for these issues is surprisingly straightforward but requires a shift in how we think about IAM. The goal is to move from "who can assume this role" to "who can assume this role, and under what specific circumstances."

AWS provides IAM condition keys that allow you to restrict access based on the source of the request. By adding a condition key like aws:SourceAccount or aws:SourceArn to your trust policy, you ensure that even if a service is tricked into assuming your role, it can only do so if the request originates from a trusted account or resource.

"Condition": {
    "StringEquals": {
        "aws:SourceAccount": "111111111111"
    }
}

This is a form of defense in depth. Even if a developer makes a mistake in the application logic or if a service has an underlying vulnerability, the IAM policy acts as a final, hard-coded gatekeeper.

Practical Steps for Pentesters

If you are currently on an engagement, stop looking for just the obvious misconfigurations. Start auditing the trust policies of every IAM role you encounter. Use the AWS CLI to list roles and inspect their trust documents. Look for roles that trust services like AppSync, Amplify, or Cognito and check if they have restrictive condition keys.

If you find a role that trusts a service without a condition key, you have found a potential path for lateral movement or privilege escalation. The impact of this is often full account takeover, as these roles are frequently granted broad permissions to S3, DynamoDB, or other critical services.

Security is not about building a wall that is impossible to climb. It is about ensuring that even if an attacker gets over the wall, they find themselves in a room with no doors. By properly scoping your trust policies, you make it significantly harder for an attacker to turn your own infrastructure against you. Take the time to audit your environment today, because the next time someone finds a way to kick in the door, you want to make sure the room is empty.