Resources

People often ask me "How did you learn how to hack?" The answer: by reading. This page is a collection of the blog posts and other articles that I have accumulated over the years of my journey. Enjoy!

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!