Serverless.com Security
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Basic Information
Organization
An Organization is the highest-level entity within the Serverless Framework ecosystem. It represents a collective group, such as a company, department, or any large entity, that encompasses multiple projects, teams, and applications.
Team
The Team are the users with access inside the organization. Teams help in organizing members based on roles. Collaborators
can view and deploy existing apps, while Admins
can create new apps and manage organization settings.
Application
An App is a logical grouping of related services within an Organization. It represents a complete application composed of multiple serverless services that work together to provide a cohesive functionality.
Services
A Service is the core component of a Serverless application. It represents your entire serverless project, encapsulating all the functions, configurations, and resources needed. It's typically defined in a serverless.yml
file, a service includes metadata like the service name, provider configurations, functions, events, resources, plugins, and custom variables.
Tutorial
This is a summary of the official tutorial from the docs:
Create an AWS account (Serverless.com start in AWS infrastructure)
Create an account in serverless.com
Create an app:
This should have created an app called tutorialapp
that you can check in serverless.com and a folder called Tutorial
with the file handler.js
containing some JS code with a helloworld
code and the file serverless.yml
declaring that function:
Create an AWS provider, going in the dashboard in
https://app.serverless.com/<org name>/settings/providers?providerId=new&provider=aws
.To give
serverless.com
access to AWS It will ask to run a cloudformation stack using this config file (at the time of this writing): https://serverless-framework-template.s3.amazonaws.com/roleTemplate.ymlThis template generates a role called
SFRole-<ID>
witharn:aws:iam::aws:policy/AdministratorAccess
over the account with a Trust Identity that allowsServerless.com
AWS account to access the role.
The tutorial asks to create the file
createCustomer.js
which will basically create a new API endpoint handled by the new JS file and asks to modify theserverless.yml
file to make it generate a new DynamoDB table, define an environment variable, the role that will be using the generated lambdas.
Deploy it running
serverless deploy
The deployment will be performed via a CloudFormation Stack
Note that the lambdas are exposed via API gateway and not via direct URLs
Test it
The previous step will print the URLs where your API endpoints lambda functions have been deployed
Security Review of Serverless.com
Misconfigured IAM Roles and Permissions
Overly permissive IAM roles can grant unauthorized access to cloud resources, leading to data breaches or resource manipulation.
When no permissions are specified for the a Lambda function, a role with permissions only to generate logs will be created, like:
Mitigation Strategies
Principle of Least Privilege: Assign only necessary permissions to each function.
Use Separate Roles: Differentiate roles based on function requirements.
Insecure Secrets and Configuration Management
Storing sensitive information (e.g., API keys, database credentials) directly in serverless.yml
or code can lead to exposure if repositories are compromised.
The recommended way to store environment variables in serverless.yml
file from serverless.com (at the time of this writing) is to use the ssm
or s3
providers, which allows to get the environment values from these sources at deployment time and configure the lambdas environment variables with the text clear of the values!
Therefore, anyone with permissions to read the lambdas configuration inside AWS will be able to access all these environment variables in clear text!
For example, the following example will use SSM to get an environment variable:
And even if this prevents hardcoding the environment variable value in the serverless.yml
file, the value will be obtained at deployment time and will be added in clear text inside the lambda environment variable.
The recommended way to store environment variables using serveless.com would be to store it in a AWS secret and just store the secret name in the environment variable and the lambda code should gather it.
Mitigation Strategies
Secrets Manager Integration: Use services like AWS Secrets Manager.
Encrypted Variables: Leverage Serverless Framework’s encryption features for sensitive data.
Access Controls: Restrict access to secrets based on roles.
Vulnerable Code and Dependencies
Outdated or insecure dependencies can introduce vulnerabilities, while improper input handling may lead to code injection attacks.
Mitigation Strategies
Dependency Management: Regularly update dependencies and scan for vulnerabilities.
Input Validation: Implement strict validation and sanitization of all inputs.
Code Reviews: Conduct thorough reviews to identify security flaws.
Static Analysis: Use tools to detect vulnerabilities in the codebase.
Inadequate Logging and Monitoring
Without proper logging and monitoring, malicious activities may go undetected, delaying incident response.
Mitigation Strategies
Centralized Logging: Aggregate logs using services like AWS CloudWatch or Datadog.
Enable Detailed Logging: Capture essential information without exposing sensitive data.
Set Up Alerts: Configure alerts for suspicious activities or anomalies.
Regular Monitoring: Continuously monitor logs and metrics for potential security incidents.
Insecure API Gateway Configurations
Open or improperly secured APIs can be exploited for unauthorized access, Denial of Service (DoS) attacks, or cross-site attacks.
Mitigation Strategies
Authentication and Authorization: Implement robust mechanisms like OAuth, API keys, or JWT.
Rate Limiting and Throttling: Prevent abuse by limiting request rates.
Secure CORS Configuration: Restrict allowed origins, methods, and headers.
Use Web Application Firewalls (WAF): Filter and monitor HTTP requests for malicious patterns.
Insufficient Function Isolation
Shared resources and inadequate isolation can lead to privilege escalations or unintended interactions between functions.
Mitigation Strategies
Isolate Functions: Assign distinct resources and IAM roles to ensure independent operation.
Resource Partitioning: Use separate databases or storage buckets for different functions.
Use VPCs: Deploy functions within Virtual Private Clouds for enhanced network isolation.
Limit Function Permissions: Ensure functions cannot access or interfere with each other’s resources unless explicitly required.
Inadequate Data Protection
Unencrypted data at rest or in transit can be exposed, leading to data breaches or tampering.
Mitigation Strategies
Encrypt Data at Rest: Utilize cloud service encryption features.
Encrypt Data in Transit: Use HTTPS/TLS for all data transmissions.
Secure API Communication: Enforce encryption protocols and validate certificates.
Manage Encryption Keys Securely: Use managed key services and rotate keys regularly.
Lack of Proper Error Handling
Detailed error messages can leak sensitive information about the infrastructure or codebase, while unhandled exceptions may lead to application crashes.
Mitigation Strategies
Generic Error Messages: Avoid exposing internal details in error responses.
Centralized Error Handling: Manage and sanitize errors consistently across all functions.
Monitor and Log Errors: Track and analyze errors internally without exposing details to end-users.
Insecure Deployment Practices
Exposed deployment configurations or unauthorized access to CI/CD pipelines can lead to malicious code deployments or misconfigurations.
Mitigation Strategies
Secure CI/CD Pipelines: Implement strict access controls, multi-factor authentication (MFA), and regular audits.
Store Configuration Securely: Keep deployment files free from hardcoded secrets and sensitive data.
Use Infrastructure as Code (IaC) Security Tools: Employ tools like Checkov or Terraform Sentinel to enforce security policies.
Immutable Deployments: Prevent unauthorized changes post-deployment by adopting immutable infrastructure practices.
Vulnerabilities in Plugins and Extensions
Using unvetted or malicious third-party plugins can introduce vulnerabilities into your serverless applications.
Mitigation Strategies
Vet Plugins Thoroughly: Assess the security of plugins before integration, favoring those from reputable sources.
Limit Plugin Usage: Use only necessary plugins to minimize the attack surface.
Monitor Plugin Updates: Keep plugins updated to benefit from security patches.
Isolate Plugin Environments: Run plugins in isolated environments to contain potential compromises.
Exposure of Sensitive Endpoints
Publicly accessible functions or unrestricted APIs can be exploited for unauthorized operations.
Mitigation Strategies
Restrict Function Access: Use VPCs, security groups, and firewall rules to limit access to trusted sources.
Implement Robust Authentication: Ensure all exposed endpoints require proper authentication and authorization.
Use API Gateways Securely: Configure API Gateways to enforce security policies, including input validation and rate limiting.
Disable Unused Endpoints: Regularly review and disable any endpoints that are no longer in use.
Excessive Permissions for Team Members and External Collaborators
Granting excessive permissions to team members and external collaborators can lead to unauthorized access, data breaches, and misuse of resources. This risk is heightened in environments where multiple individuals have varying levels of access, increasing the attack surface and potential for insider threats.
Mitigation Strategies
Principle of Least Privilege: Ensure that team members and collaborators have only the permissions necessary to perform their tasks.
Access Keys and License Keys Security
Access Keys and License Keys are critical credentials used to authenticate and authorize interactions with the Serverless Framework CLI.
License Keys: They are Unique identifiers required for authenticating access to Serverless Framework Version 4 which allows to login via CLI.
Access Keys: Credentials that allow the Serverless Framework CLI to authenticate with the Serverless Framework Dashboard. When login with
serverless
cli an access key will be generated and stored in the laptop. You can also set it as an environment variable namedSERVERLESS_ACCESS_KEY
.
Security Risks
Exposure Through Code Repositories:
Hardcoding or accidentally committing Access Keys and License Keys to version control systems can lead to unauthorized access.
Insecure Storage:
Storing keys in plaintext within environment variables or configuration files without proper encryption increases the likelihood of leakage.
Improper Distribution:
Sharing keys through unsecured channels (e.g., email, chat) can result in interception by malicious actors.
Lack of Rotation:
Not regularly rotating keys extends the exposure period if keys are compromised.
Excessive Permissions:
Keys with broad permissions can be exploited to perform unauthorized actions across multiple resources.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Last updated