Cross-Service Confused Deputy Attacks on AWS: Are Your Permissions Being Exploited?

Imagine you’ve embraced the convenience of a third-party service designed to provide insightful reports by analyzing data from your AWS account. To enable this, you establish a cross-account IAM role, granting the third-party service’s AWS account the necessary permissions to assume it and retrieve the data. It’s a common practice, streamlining workflows and unlocking valuable insights.

However, this seemingly straightforward integration can harbor a subtle yet significant security risk.

Consider an attacker named Eve who also signs up for the same third-party service. She creates a legitimate account, complete with her own username and password. When it’s time to connect her AWS environment, instead of providing a role from an account she legitimately controls, Eve manages to identify (or cleverly guesses) the Amazon Resource Name (ARN) of your cross-account role — the very role you intended solely for the third-party service’s use on your behalf.

Here’s the crux of the problem: because your role’s trust policy is already configured to trust the third-party service’s AWS account, Eve’s attempt to have the service assume your role on her behalf succeeds. Now, when Eve logs into the third-party service using her legitimate credentials, the service, acting upon her request, assumes your role, fetches data from your AWS account, and presents it to Eve within her own session.

In this classic “Confused Deputy” scenario, the third-party service is unwittingly acting on the instructions of an unauthorized user (Eve) because it was provided with valid credentials (your role ARN) intended for a different purpose. The potential consequences could range from unauthorized access to sensitive data to unforeseen actions being performed within your AWS environment.

This real-world-inspired example highlights the critical vulnerability of Cross-Service Confused Deputy attacks in AWS, particularly when involving third-party integrations. In this article, we’ll delve into the mechanics of these attacks and, more importantly, explore concrete strategies and best practices to effectively prevent them, ensuring the security of your AWS resources.

Deeper Dive into the Confused Deputy Concept in AWS

You’ve seen a glimpse of the Confused Deputy problem with Eve and the third-party service. At its core, a Confused Deputy attack in AWS occurs when a less privileged service or principal (the “deputy”) is tricked into performing an action on resources it wouldn’t normally have access to. This happens because the deputy is acting under the authority of a more privileged principal, but the request is initiated or influenced by a malicious actor.

AWS, with its rich ecosystem of interconnected services, offers numerous opportunities for such scenarios to arise. The very flexibility and power of IAM roles and policies, which enable secure cross-service communication, can also be a pathway for exploitation if not carefully managed.

Think of it like this: your application (the deputy) might have permission to read data from a specific S3 bucket because it’s running on an EC2 instance with an IAM role that grants that permission. Now, imagine a scenario where a malicious user can somehow influence your application to read from a different, more sensitive S3 bucket that the application itself shouldn’t have access to. The application, acting as the “deputy” under its legitimate role permissions, is “confused” into performing an action it shouldn’t.

The key elements at play are:

• The Less Privileged Deputy: An AWS service (like Lambda, EC2, CodeBuild) or a principal with limited permissions.
• The More Privileged Principal: An IAM role or user with broader permissions that the deputy can assume or utilize.
• The Malicious Actor: An entity (like our fictional Eve) who manipulates the interaction.
• The Unauthorized Resource: The AWS resource that the malicious actor aims to access or modify through the confused deputy.

It’s crucial to remember that Cross-Service Confused Deputy attacks involve the interaction of two or more distinct AWS services or principals. This distinguishes them from attacks that might occur within the confines of a single service due to misconfigurations.

How Attackers Exploit the Confused Deputy in AWS

Attackers like Eve thrive on exploiting established trust relationships within your AWS environment. In our initial example, the trust relationship was the cross-account IAM role you created, explicitly allowing the third-party service’s AWS account to assume it. Eve didn’t need to compromise your account or the third-party service’s account directly; she simply leveraged this existing trust by providing your role ARN in a context where the third-party service would act upon it.

The beauty (from the attacker’s perspective) of a Confused Deputy attack is that they often don’t need to directly breach a highly secured resource. Instead, they manipulate a trusted intermediary to do their bidding. This manipulation can take various forms:

• Exploiting Third-Party Service Integrations: As we saw with Eve, if a third-party service doesn’t have robust controls in place to verify the legitimacy of the AWS resources being connected by its users, an attacker can potentially link resources they don’t own but that the service has permission to access.
• Abusing Cross-Account Access: Overly permissive trust policies on IAM roles that allow assumption from a wide range of AWS accounts can be a prime target. An attacker might gain access to one of those trusted accounts and then assume the more privileged role in your account.
• Leveraging Service-to-Service Interactions: Consider a scenario where a build service (like CodeBuild) has permissions to modify IAM policies. If an attacker can control the build configuration, they might be able to instruct CodeBuild to modify policies in a way that grants them unintended access.
• Manipulating User-Controlled Inputs: Many AWS services accept user-provided input. If a trusted service uses this input to interact with other resources, an attacker might be able to craft malicious input to target resources outside the intended scope. For instance, if a Lambda function takes an S3 bucket name as input and has broad S3 permissions, an attacker might provide the name of a sensitive bucket.

Understanding these common attack vectors is the first step towards building effective defenses.

The good news is that AWS provides powerful mechanisms to prevent Cross-Service Confused Deputy attacks. Implementing these strategies diligently is key to securing your environment.

• Principle of Least Privilege (The Cornerstone): This cannot be overstated. Grant services and principals only the absolute minimum permissions they need to perform their intended functions. The less power a potential “deputy” has, the less damage it can cause if compromised or tricked.
• Leveraging aws:SourceArn and aws:SourceAccount Condition Keys: These are your most potent tools in preventing confused deputy scenarios.

1. Deep Dive into aws:SourceArn: The aws:SourceArn condition key allows you to specify the Amazon Resource Name (ARN) of the AWS resource that is making the request. You can use this in resource policies (like S3 bucket policies, KMS key policies, and IAM role trust policies) to restrict access to only requests originating from a specific, known resource.

// Example: S3 Bucket Policy allowing a specific Lambda function to write
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowSpecificLambdaWrite",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::123456789012:role/MyLambdaExecutionRole"
            },
            "Action": "s3:PutObject",
            "Resource": "arn:aws:s3:::my-secure-bucket/*",
            "Condition": {
                "ArnEquals": {
                    "aws:SourceArn": "arn:aws:lambda:eu-west-1:123456789012:function:MyDataProcessor"
                }
            }
        }
    ]
}

Similarly, in an IAM role’s trust policy, you can use aws:SourceArn to specify which specific AWS resources are allowed to assume that role:

// Example: IAM Role Trust Policy allowing a specific CodeBuild project to assume
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "Service": "codebuild.amazonaws.com"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "ArnEquals": {
                    "aws:SourceArn": "arn:aws:codebuild:eu-west-1:123456789012:project/MyWebAppBuild"
                }
            }
        }
    ]
}

2. Deep Dive into aws:SourceAccount: The aws:SourceAccount condition key allows you to restrict access based on the AWS account ID of the principal making the request. This is particularly useful in cross-account scenarios where you want to limit access to resources from only specific trusted accounts.

// Example: KMS Key Policy allowing access only from a specific account
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowAccessFromSpecificAccount",
            "Effect": "Allow",
            "Principal": {
                "AWS": "*"
            },
            "Action": "kms:Encrypt",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:SourceAccount": "123456789012"
                }
            }
        }
    ]
}

3. Importance in Trust Policies: When configuring trust policies for IAM roles that will be assumed by services in other accounts or even within your own account, always strive to include aws:SourceArn or aws:SourceAccount (or both, where appropriate) to tightly control who can assume the role and under what circumstances.

• The Power of External ID: The External ID provides an additional layer of security when establishing trust between AWS accounts, especially with third-party services. The third party generates a unique, non-secret ID for your account during the registration process. You then include this External ID in the trust policy of the cross-account role you create.

// Example: IAM Role Trust Policy using External ID
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::THIRD_PARTY_ACCOUNT_ID:root"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "StringEquals": {
                    "sts:ExternalId": "YOUR_UNIQUE_EXTERNAL_ID"
                }
            }
        }
    ]
}

In the scenario with Eve, even if she knows the ARN of your role, the third-party service, when operating on her behalf, will send her unique External ID, which won’t match the one in your role’s trust policy. This prevents the unauthorized role assumption.

• Service Control Policies (SCPs) for Organization-Wide Governance: If you use AWS Organizations, SCPs allow you to centrally manage permissions across all accounts in your organization. You can use SCPs to enforce the use of aws:SourceArn and aws:SourceAccount in IAM policies, ensuring a consistent security baseline.
• AWS IAM Access Analyzer: This invaluable service continuously analyzes your resource policies (IAM policies, S3 bucket policies, KMS key policies, etc.) and identifies permissions that grant broader access than intended. It can specifically highlight potential Confused Deputy vulnerabilities by identifying cross-account access that doesn’t use aws:SourceArn or aws:SourceAccount. Regularly reviewing Access Analyzer findings is crucial.
• VPC Endpoints: For services like S3 and DynamoDB, using VPC endpoints can help to contain traffic within your Virtual Private Cloud (VPC), reducing the potential attack surface and limiting the ability of a confused deputy to interact with these services from unexpected network locations.
• Regular Security Audits and Policy Reviews: IAM policies and trust relationships should not be a “set it and forget it” configuration. Regularly audit your policies to ensure they still adhere to the principle of least privilege and that the aws:SourceArn and aws:SourceAccount conditions are correctly implemented and still relevant.

Best Practices for Third-Party Integrations (Relating Back to Eve’s Scenario)

When integrating with third-party services, the risk of Confused Deputy attacks can be heightened. Here are some key best practices to follow:

• Scrutinize Required Permissions: Before granting any third-party service access to your AWS environment, meticulously review the permissions they are requesting. Understand why they need each permission and grant only the absolute minimum necessary for their functionality. Be wary of services that request overly broad permissions.
• Prefer Service-Linked Roles Where Possible: If the third-party service supports it, using service-linked roles can be a more secure option. These roles have predefined permissions managed by AWS, reducing the need for you to create and manage custom roles.
• Utilize aws:SourceArn and External ID: When establishing trust with a third-party service via a cross-account IAM role, always insist on the use of a unique External ID provided by the service. Additionally, if the third-party service operates from a predictable AWS resource (e.g., a specific Lambda function or set of EC2 instances), consider further restricting the trust policy using aws:SourceArn.
• Implement Robust Verification Processes: If your application interacts with third-party services, ensure you have mechanisms in place to verify the legitimacy and integrity of the data and requests coming from those services.
• Regularly Review and Audit Third-Party Access: Periodically review the permissions granted to all third-party services connected to your AWS account. If a service is no longer needed or its required permissions have changed, revoke or update the access accordingly.

Conclusion: Proactive Security in the Cloud

Preventing Cross-Service Confused Deputy attacks in AWS is not a one-time task but an ongoing commitment to security best practices. By understanding the mechanisms of these attacks and diligently implementing preventative measures like the principle of least privilege, aws:SourceArn, aws:SourceAccount, and External IDs, you can significantly reduce your risk.

Remember that security in the cloud is a shared responsibility. While AWS provides the tools and services to secure your environment, it’s up to you to configure and utilize them effectively. Regularly reviewing your IAM policies, scrutinizing third-party integrations, and staying informed about AWS security best practices are crucial steps in maintaining a robust and secure cloud environment.

Take proactive steps today to review your AWS IAM configurations and third-party integrations. By doing so, you can safeguard your valuable resources and avoid becoming the next victim of a Confused Deputy attack.

Further Reading

• AWS IAM User Guide: Confused Deputy Prevention: https://docs.aws.amazon.com/IAM/latest/UserGuide/confused-deputy.html
• AWS Database Migration Service User Guide: Cross-Service Confused Deputy Prevention: https://docs.aws.amazon.com/dms/latest/userguide/cross-service-confused-deputy-prevention.html

A message from our Founder

Hey, Sunil here. I wanted to take a moment to thank you for reading until the end and for being a part of this community.

Did you know that our team run these publications as a volunteer effort to over 3.5m monthly readers? We don’t receive any funding, we do this to support the community. ❤️

If you want to show some love, please take a moment to follow me on LinkedIn, TikTok, **Instagram. You can also subscribe to our [weekly newsletter](https://newsletter.plainenglish.io/)**.

And before you go, don’t forget to clap and follow the writer️!