Hacking Lamda
Last updated
Last updated
AWS Lambda is a serverless service which allows users to run code without managing the need of server. This means you dont have to provison any CPU cores,disk space or even memory since everything is taken care of by AWS.
You just have to upload your code and just execute it without worrying about hardware which makes it serverless. AWS later executes your lambda in a sandbox environment where each request is executed in a seperate sandbox which makes each execution unique and seperate from other executions.
A single lambda function can have multiple versions. This helps keep track of old code. Default lambda is at $LATEST
version. Any new version creation starts at number 1
and increases by factor of 1 as new versions are published.
Above screenshot indicates that lambda securitylabs-lambda
has a existing version with id 1
. In order to access the v1 of the securitylabs-lambda, the ARN would become arn:aws:lambda:us-east-2:584358494719:function:securitylabs-lambda:1
Notice the :1
at end. It indicates the version of the lambda.If there are v2 of securitylabs-lambda, then ARN would have become arn:aws:lambda:us-east-2:584358494719:function:securitylabs-lambda:2
Lambda layers provide a convenient way to package libraries and other dependencies that you can use with your Lambda functions. You can use it to define functions that can be directly used with your main lambda function.
The above diagram indicates that there is layer called AWSDataWrangler-Python39
added to lambda function.
In order to create lambda, one needs to pass a zip file and add the compatible architecture and runtime environments as shown below.
One fact to note that adedd Layer is unziped at /opt
directory in the lambd sandbox. Hence to import the code we need to import it from /opt
Lambda Sandbox has 2 main process i.e init and bootstrap. Init server is ran at 9001
and has various endpoints :-
/2018-06-01/runtime/invocation/next
– Get the next invocation event i.e the parameters which will be passed to lambda during invocation
/2018-06-01/runtime/invocation/{invoke-id}/response
- Returns the response for the invoked event.
/2018-06-01/runtime/invocation/{invoke-id}/error
- Reports an error if any during execution.
Invoke-ID can be found in the response header Lambda-Runtime-Aws-Request-Id
while quering /2018-06-01/runtime/invocation/next
.
Hence, you can simply query 127.0.0.1:9001/2018-06-01/runtime/invocation/next
to get the exact parameters that would be used to invoke the lambda.
To read the original research, refer unit42
Lambda functions have a Role attached to them which be usefull for privilege escalations. In order to dump down all the secrets of lambda function, simply executing env
or cat /etc/proc/self/environ
can help dump the role credentials.
These credentials are the STS tokens for the Role attached to the lambda.
Except /tmp
the whole Lambda sandbox is read-only system. To perform enumeration of the sandbox, you can upload all your tools at /tmp
AWS uses a concept of hot
and cold
lambda. If lambda is ran once in every 10-15 minutes, the lambda remains in hot state i.e any tools downloaded at /tmp
or any sandbox changes are not removed and the existing container is used for execution. But if lambda is not executed in the above timeframe, AWS provisons a new container for execution of your request and hence any changes in sandbox are lost.