The Fault in Our Stars - Attack Vectors for APIs Using Amazon API Gateway Lambda Authorizers

Serverless applications are a really interesting new trend that promises benefits such as increased scalability and reduced cost. Frameworks like Serverless Application Model (SAM) and Serverless Framework are increasingly used to build them. APIs are a natural part of serverless applications, and in AWS that typically is implemented using the AWS API Gateway backed by Lambdas that implement the actual API endpoint logic. Our research focused on API Gateway Lambda Authorizers. This is a feature that allows developers to use a custom authentication and authorization scheme that uses a bearer token authentication strategy (like JWTs, OAuth or SAML), or that uses request parameters to determine the caller's identity and enforce which API endpoints they are allowed to access. We will present (AFAIK novel) techniques to attack the authentication and authorization of APIs that use Lambda Authorizers. We show how IAM policy injection is possible in theory but highly unlikely in practice due to some good decisions by AWS. We also show a class of problems based on incorrect security assumptions baked into AWS' own documentation and Lambda Authorizer open source code templates. Sample source code will be provided to demonstrate all techniques.

Presented at DEF CON 29 Cloud Village.

Transcript

1. The Fault in Our Stars Attack Vectors for APIs Using Amazon API Gateway Lambda Authorizers
2. arn:aws:iam:sa-east-1:*:user/AlexandreSieira • Co-Founder @ Tenchi Security • Cloud Security Posture Chiropractor (h/t @swagitda_) • São Paulo, Brazil 🇧🇷 sts:GetCallerIdentity asieira@tenchisecurity.com @AlexandreSieira arn:aws:iam:sa-east-1:*:user/LeonardoViveiros • DevSecOps Specialist @ Tenchi Security • Recovering serverful on-premises software developer • Limeira, Brazil 🇧🇷 lviveiros@tenchisecurity.com @LeonardoViveiro
3. Motivation Why should you care? https://twitter.com/CloudTrekAU/status/936300151005626368/photo/1 Expectation Reality https://twitter.com/swyx/status/1423025792783568899/photo/1
4. API Gateway Overview Pronounced “ah-pee gateway” by AWS teams (h/t @quinnypig)
5. API Gateway Overview Main Concepts • APIs are uniquely identified by IDs • API stages are logical reference to a lifecycle state like 'dev', 'prod', 'beta', 'v2’, and are identified by API ID and stage name. • Many ways to implement auth: ◦ Amazon Cognito ◦ Native OpenID Connect / OAuth 2.0 ◦ IAM ◦ Lambda authorizers
6. Amazon Cognito AWS’ Own CIAM Offering has a History • Andrés Riancho from Wildlife Studios published amazing research on this in 2019: https://andresriancho.com/internet- scale-analysis-of-aws-cognito-security/ • Cognito reference architecture relies on providing client-side code with AWS credentials for authenticated and unauthenticated users. • The research identified 2,500 identity pools, which were used to gain access to the following non-public resources using only unauthenticated user privileges: ◦ 13,000 S3 buckets ◦ 1,200 DynamoDB tables ◦ 1,500 Lambda functions @AndresRiancho
7. API Gateway Overview Lambda Authorizers Overview
8. API Gateway Overview Lambda Authorizers Return Value
9. API Gateway Overview Lambda Authorizers Policy Document • IAM policy in PAERC format – more familiar to ops and security than to devs. • Case sensitive resource matching. • Stars (‘*’) expand greedily inside each ARN component. • Lack of regular expression matching severely limits representation (i.e. path parameters, multiple methods).
10. API Gateway Execute-API arn:aws:execute-api:sa-east-1:account-id:api-id/prod/*/dashboard/*
11. API Gateway Execute-API arn:aws:execute-api:sa-east-1:account-id:api-id/prod/*/dashboard/* api-id/prod/POST/admin/store/order/creditcard/dashboard/ api-id/prod/POST/admin/dashboard/createAdminUser/
13. API Gateway Documentation If it’s documented it’s a feature, not a bug Documentation examples written as if “*” stopped expanding at “/”, which is not the case. https://docs.aws.amazon.com/apigateway/latest/d eveloperguide/api-gateway-control-access-using- iam-policies-to-invoke-api.html
14. API Gateway Documentation If it’s documented it’s a feature, not a bug
15. API Gateway Documentation If it’s documented it’s a feature, not a bug https://github.com/awslabs/aws-apigateway-lambda-authorizer-blueprints/
16. API Gateway Console If it’s documented it’s a feature, not a bug
17. Lambda Console If it’s documented it’s a feature, not a bug
18. Actual Examples This project on Github does exactly what someone would do after reading the AWS documentation. And these policies are for guest users... Someone with this policy can call: • GET /problems/submissions • GET /problems/foo/bar/submissions • GET /problems/foo/submissions • POST /problems/submit • POST /problems/foo/submit • POST /problems/foo/bar/submit • ...
19. Works on My Machine! Serverless Offline Deployed to AWS https://github.com/dherault/serverless-offline/issues/1259
20. Responsible Disclosure Playing by the rules • Initially reported issues to AWS on April 26th, 2021. • Published at https://www.tenchisecurity.com/blog/thefaultinours tars on June 21st, 20201. • AWS was incredibly responsive and professional about the entire thing. • Special thanks to Mark Ryland and the API Gateway team for their support throughout this process. • They updated documentation and lambda authorizer code, but notably not the AWS console output.
21. IAM Policy Injection Good design choices by AWS • Lambda authorizers use external input to build the policy document. • Can we perform an injection attack (i.e. a new statement with Allow for ”*”)? • Lambda authorizers must return a structured language object (Javascript object, Python dict, etc) by design, so they are not routinely built as strings. • This avenue of attack doesn’t seem practical for the vast majority of APIs. FOILED
22. IAM Policy Injection What if we provide “*” or “a*” as the external data? https://aws.amazon.com/blogs/compute/int roducing-custom-authorizers-in-amazon- api-gateway/
23. Recommendations First for AWS – you hold to key to improving this service! • Create IAM policy conditions for API gateway. • Change placeholders in AWS Console to ANYTHING other than “*”. • Find a way to allow regular expression matching at a minimum for resource paths, so path parameters can be safely handled. • Let some senior security folks into those fabled 2-🍕 teams! This could be us, AWS, but u playin’
24. Recommendations For AWS customers • Stars should ideally only be used as "/*" at the very end of the ARN (i.e.: "arn:aws:execute-api:us-west- 1:12345678:myApiId/test/GET/foo/bar/*"). • Use Deny statements to limit the impact or scope of star expansions when possible. • Check again that the user is authorized to call an endpoint in its implementation. Don’t trust the lambda authorizer alone with authorization decisions. • Make sure any code imported from the previous version of the lambda authorizer blueprints is updated to the latest version. • If you use URL path parameters in your APIs, avoid cases where valid values can be chosen by potential attackers. Prefer backend-generated IDs.
25. Questions? asieira@tenchisecurity.com @AlexandreSieira lviveiros@tenchisecurity.com @LeonardoViveiro https://www.reddit.com/r/ProgrammerHumor/comments/d37bzc/what_comes_after_ serverless/ Demo code available at: https://github.com/tenchi-security/the-fault-in-our-stars