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.

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