Full Report
AWS Appsync is a GraphQL endpoint as a service. There are several different underlying data storage, such Lambda, DynamoDB, RDS and many others. There is also a custom option for this, which allows for the creating of developer written resolvers. To authorize the actions that AppSync will perform, a role ARN is passed in. The role has two components: a trust policy for who can assume the role and the IAM permissions this provides. In this case, the trusted entity for assuming is AppSync and the permissions are S3. Here's a good question: what stops a user from passing in an IAM role from a different account? The service has permission to assume the role, since they are allowed in the policy, but not for this user. This is known as the Confused Deputy Problem - "where a less-privileged entity (the attacker) convinces a more-privileged entity or service (AppSync) to perform some action on its behalf." AWS safeguards against these types of attacks quite well - with validation usually being done on the account the role is owned by. This wasn't an exception to the rule! There is validation being done. However, changing the casing of the parameter in the URL skips validation and gets the role to be used anyway. For instance, passing in httpConfig as the parameter with a cross account role wouldn't work. However, HTTPCONFIG would bypass the validation! This allows for the role being assumed into another account. In terms of exploitation, an attacker could pass in the bad role and write there own resolver API to query the information that the role has access to. From S3 buckets to DynamoDB, the custom resolver would have some serious impact here. To remediate the problem slightly, an attacker needs to know the role ARN, the role ARN must have allowlisted AppSync and all of the resources in the account will have to be guessed by the attacker. Case sensitivity problems are not new! The difference between two interpreters - verification and use, caused a major problem here. Overall, pretty neat bug!
Analysis Summary
# Vulnerability: AWS AppSync Confused Deputy via Case-Insensitive Parameter Bypass
## CVE Details
- CVE ID: Not explicitly provided in the text (Reported September 1, 2022; Fixed Spetember 6, 2022)
- CVSS Score: Not explicitly provided in the text (Impact suggests High severity)
- CWE: CWE-918 (Server-Side Request Forgery - Related to how the deputy confusion is leveraged, or potentially CWE-284 Improper Access Control)
## Affected Systems
- Products: AWS AppSync
- Versions: Undisclosed (Affected versions prior to the fix deployed on September 6, 2022)
- Configurations: Custom resolvers configured to invoke AWS APIs via HTTP resolvers where the underlying IAM role trusted `appsync.amazonaws.com` for the `sts:AssumeRole` action.
## Vulnerability Description
The vulnerability resided in how AWS AppSync performed validation when using custom resolvers that required assuming an IAM role from a different account (Confused Deputy scenario). While standard validation for role assumption checks occurred, **changing the casing of the URL parameter** used to invoke this functionality bypassed the validation logic.
Specifically, a properly cased parameter like `httpConfig` would trigger validation, but an attacker controlling the case, such as `HTTPCONFIG`, would skip this check, allowing AppSync to assume a cross-account role specified by the attacker (provided the role's trust policy allowed AppSync to assume it). This allowed an attacker to pivot into external AWS accounts via the AppSync service.
## Exploitation
- Status: PoC available (Datadog demonstrated a proof of concept using `sts:AssumeRole`)
- Complexity: Low (Requires knowledge of the target role ARN and exploitation of a case-sensitive parameter mistake)
- Attack Vector: Network
## Impact
- Confidentiality: High (Gained access to S3, DynamoDB, and potentially other resources within the victim account via the assumed role)
- Integrity: High (Ability to modify or delete resources accessed by the assumed role)
- Availability: Medium (Potential for data deletion or service disruption, depending on the assumed role's permissions)
## Remediation
### Patches
- AWS deployed a fix to the AppSync service on September 6, 2022, remediating the case-insensitivity issue that bypassed validation logic.
### Workarounds
- Ensure that any IAM roles configured for AppSync data sources have stringent trust policies that only allow the specific AppSync principal ARN, though the primary fix addresses the underlying validation bypass.
- Monitor logs for anomalous behavior related to `sts:AssumeRole` originating from the AppSync service principal that might indicate an active attack attempt.
## Detection
- **Indicators of Compromise (IoCs):**
- High volume of `AccessDenied` events originating from the `appsync.amazonaws.com` principal attempting to access resources, especially if the attacker is guessing permissions ("brute forcing").
- Unusually initiated API calls (e.g., `s3:ListBuckets`) from the assumed role if that action has never been performed by the role historically.
- **Detection Methods and Tools:**
- Monitor AWS CloudTrail logs for `sts:AssumeRole` events targeting roles trusted by AppSync.
- Implement anomaly detection rules within security monitoring tools (like Datadog) to flag unusual access patterns originating from AppSync-assumed roles.
## References
- AWS Security Bulletin: [aws.amazon.com/security/security-bulletins/AWS-2022-009/] (Defanged)
- Datadog Security Labs Report: [securitylabs.datadoghq.com/articles/appsync-vulnerability-disclosure/] (Defanged)