GITBOOK-733: No subject

2025-12-12 15:50:19 -08:00 · 2024-12-18 16:46:27 +00:00
parent 2934cfc93e
commit 528d2c968c
3 changed files with 814 additions and 1 deletions
--- a/SUMMARY.md
+++ b/SUMMARY.md
@@ -42,9 +42,10 @@
  * [Cloudflare Zero Trust Network](pentesting-ci-cd/cloudflare-security/cloudflare-zero-trust-network.md)
 * [Okta Security](pentesting-ci-cd/okta-security/README.md)
  * [Okta Hardening](pentesting-ci-cd/okta-security/okta-hardening.md)
 * [Serverless.com Security](pentesting-ci-cd/serverless.com-security.md)
 * [Supabase Security](pentesting-ci-cd/supabase-security.md)
 * [Ansible Tower / AWX / Automation controller Security](pentesting-ci-cd/ansible-tower-awx-automation-controller-security.md)
-* [Vercel](pentesting-ci-cd/vercel.md)
+* [Vercel Security](pentesting-ci-cd/vercel-security.md)
 * [TODO](pentesting-ci-cd/todo.md)
 ## ⛈️ Pentesting Cloud
--- a/pentesting-ci-cd/serverless.com-security.md
+++ b/pentesting-ci-cd/serverless.com-security.md
@@ -0,0 +1,812 @@
 # Serverless.com Security
 {% hint style="success" %}
 Learn & practice AWS Hacking:<img src="../.gitbook/assets/image (1) (1) (1) (1).png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="../.gitbook/assets/image (1) (1) (1) (1).png" alt="" data-size="line">\
 Learn & practice GCP Hacking: <img src="../.gitbook/assets/image (2) (1).png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="../.gitbook/assets/image (2) (1).png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
 <details>
 <summary>Support HackTricks</summary>
 * Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
 * **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks_live)**.**
 * **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
 </details>
 {% endhint %}
 ## 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.
 ```yaml
 service: my-service
 provider:
  name: aws
  runtime: nodejs14.x
 functions:
  hello:
    handler: handler.hello
 ```
 <details>
 <summary>Function</summary>
 A **Function** represents a single serverless function, such as an AWS Lambda function. It contains the code that executes in response to events.
 It's defined under the `functions` section in `serverless.yml`, specifying the handler, runtime, events, environment variables, and other settings.
 ```yaml
 functions:
  hello:
    handler: handler.hello
    events:
      - http:
          path: hello
          method: get
 ```
 </details>
 <details>
 <summary>Event</summary>
 **Events** are triggers that invoke your serverless functions. They define how and when a function should be executed.
 Common event types include HTTP requests, scheduled events (cron jobs), database events, file uploads, and more.
 ```yaml
 functions:
  hello:
    handler: handler.hello
    events:
      - http:
          path: hello
          method: get
      - schedule:
          rate: rate(10 minutes)
 ```
 </details>
 <details>
 <summary>Resource</summary>
 **Resources** allow you to define additional cloud resources that your service depends on, such as databases, storage buckets, or IAM roles.
 They are specified under the `resources` section, often using CloudFormation syntax for AWS.
 ```yaml
 resources:
  Resources:
    MyDynamoDBTable:
      Type: AWS::DynamoDB::Table
      Properties:
        TableName: my-table
        AttributeDefinitions:
          - AttributeName: id
            AttributeType: S
        KeySchema:
          - AttributeName: id
            KeyType: HASH
        ProvisionedThroughput:
          ReadCapacityUnits: 1
          WriteCapacityUnits: 1
 ```
 </details>
 <details>
 <summary>Provider</summary>
 The **Provider** object specifies the cloud service provider (e.g., AWS, Azure, Google Cloud) and contains configuration settings relevant to that provider.
 It includes details like the runtime, region, stage, and credentials.
 ```yaml
 yamlCopy codeprovider:
  name: aws
  runtime: nodejs14.x
  region: us-east-1
  stage: dev
 ```
 </details>
 <details>
 <summary>Stage and Region</summary>
 The stage represents different environments (e.g., development, staging, production) where your service can be deployed. It allows for environment-specific configurations and deployments.
 ```yaml
 provider:
  stage: dev
 ```
 The region specifies the geographical region where your resources will be deployed. It's important for latency, compliance, and availability considerations.
 ```yaml
 provider:
  region: us-west-2
 ```
 </details>
 <details>
 <summary>Plugins</summary>
 **Plugins** extend the functionality of the Serverless Framework by adding new features or integrating with other tools and services. They are defined under the `plugins` section and installed via npm.
 ```yaml
 plugins:
  - serverless-offline
  - serverless-webpack
 ```
 </details>
 <details>
 <summary>Layers</summary>
 **Layers** allow you to package and manage shared code or dependencies separately from your functions. This promotes reusability and reduces deployment package sizes. They are defined under the `layers` section and referenced by functions.
 ```yaml
 layers:
  commonLibs:
    path: layer-common
 functions:
  hello:
    handler: handler.hello
    layers:
      - { Ref: CommonLibsLambdaLayer }
 ```
 </details>
 <details>
 <summary>Variables and Custom Variables</summary>
 **Variables** enable dynamic configuration by allowing the use of placeholders that are resolved at deployment time.
 *   **Syntax:** `${variable}` syntax can reference environment variables, file contents, or other configuration parameters.
    ```yaml
    functions:
      hello:
        handler: handler.hello
        environment:
          TABLE_NAME: ${self:custom.tableName}
    ```
 -   **Custom Variables:** The `custom` section is used to define user-specific variables and configurations that can be reused throughout the `serverless.yml`.
    ```yaml
    custom:
      tableName: my-dynamodb-table
      stage: ${opt:stage, 'dev'}
    ```
 </details>
 <details>
 <summary>Outputs</summary>
 **Outputs** define the values that are returned after a service is deployed, such as resource ARNs, endpoints, or other useful information. They are specified under the `outputs` section and often used to expose information to other services or for easy access post-deployment.
 ```yaml
 ¡outputs:
  ApiEndpoint:
    Description: "API Gateway endpoint URL"
    Value:
      Fn::Join:
        - ""
        - - "https://"
          - Ref: ApiGatewayRestApi
          - ".execute-api."
          - Ref: AWS::Region
          - ".amazonaws.com/"
          - Ref: AWS::Stage
 ```
 </details>
 <details>
 <summary>IAM Roles and Permissions</summary>
 **IAM Roles and Permissions** define the security credentials and access rights for your functions and other resources. They are managed under the `provider` or individual function settings to specify necessary permissions.
 ```yaml
 provider:
  iamRoleStatements:
    - Effect: Allow
      Action:
        - dynamodb:Query
        - dynamodb:Scan
      Resource: arn:aws:dynamodb:${self:provider.region}:*:table/my-table
 ```
 </details>
 <details>
 <summary>Environment Variables</summary>
 **Variables** allow you to pass configuration settings and secrets to your functions without hardcoding them. They are defined under the `environment` section for either the provider or individual functions.
 ```yaml
 provider:
  environment:
    STAGE: ${self:provider.stage}
 functions:
  hello:
    handler: handler.hello
    environment:
      TABLE_NAME: ${self:custom.tableName}
 ```
 </details>
 <details>
 <summary>Dependencies</summary>
 **Dependencies** manage the external libraries and modules your functions require. They typically handled via package managers like npm or pip, and bundled with your deployment package using tools or plugins like `serverless-webpack`.
 ```yaml
 plugins:
  - serverless-webpack
 ```
 </details>
 <details>
 <summary>Hooks</summary>
 **Hooks** allow you to run custom scripts or commands at specific points in the deployment lifecycle. They are defined using plugins or within the `serverless.yml` to perform actions before or after deployments.
 ```yaml
 custom:
  hooks:
    before:deploy:deploy: echo "Starting deployment..."
 ```
 </details>
 ### Tutorial
 This is a summary of the official tutorial [**from the docs**](https://www.serverless.com/framework/docs/tutorial):
 1. Create an AWS account (Serverless.com start in AWS infrastructure)
 2. Create an account in serverless.com
 3. Create an app:
 ```bash
 # Create temp folder for the tutorial
 mkdir /tmp/serverless-tutorial
 cd /tmp/serverless-tutorial
 # Install Serverless cli
 npm install -g serverless
 # Generate template
 serverless #Choose first one (AWS / Node.js / HTTP API)
 ## Indicate a name like "Tutorial"
 ## Login/Register
 ## Create A New App
 ## Indicate a name like "tutorialapp)
 ```
 This should have created an **app** called `tutorialapp` that you can check in [serverless.com](serverless.com-security.md) 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:
 {% tabs %}
 {% tab title="handler.js" %}
 ```javascript
 exports.hello = async (event) => {
  return {
    statusCode: 200,
    body: JSON.stringify({
      message: "Go Serverless v4! Your function executed successfully!",
    }),
  };
 };
 ```
 {% endtab %}
 {% tab title="serverless.yml" %}
 ```yaml
 # "org" ensures this Service is used with the correct Serverless Framework Access Key.
 org: testing12342
 # "app" enables Serverless Framework Dashboard features and sharing them with other Services.
 app: tutorialapp
 # "service" is the name of this project. This will also be added to your AWS resource names.
 service: Tutorial
 provider:
  name: aws
  runtime: nodejs20.x
 functions:
  hello:
    handler: handler.hello
    events:
      - httpApi:
          path: /
          method: get
 ```
 {% endtab %}
 {% endtabs %}
 4. Create an AWS provider, going in the **dashboard** in `https://app.serverless.com/<org name>/settings/providers?providerId=new&provider=aws`.
   1. 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.yml](https://serverless-framework-template.s3.amazonaws.com/roleTemplate.yml)
   2. This template generates a role called **`SFRole-<ID>`** with **`arn:aws:iam::aws:policy/AdministratorAccess`** over the account with a Trust Identity that allows `Serverless.com` AWS account to access the role.
 <details>
 <summary>Yaml roleTemplate</summary>
 ```yaml
 Description: This stack creates an IAM role that can be used by Serverless Framework for use in deployments.
 Resources:
  SFRole:
    Type: AWS::IAM::Role
    Properties:
      AssumeRolePolicyDocument:
        Version: '2012-10-17'
        Statement:
          - Effect: Allow
            Principal:
              AWS: arn:aws:iam::486128539022:root
            Action:
              - sts:AssumeRole
            Condition:
              StringEquals:
                sts:ExternalId: !Sub 'ServerlessFramework-${OrgUid}'
      Path: /
      RoleName: !Ref RoleName
      ManagedPolicyArns:
        - arn:aws:iam::aws:policy/AdministratorAccess
  ReporterFunction:
    Type: Custom::ServerlessFrameworkReporter
    Properties:
      ServiceToken: 'arn:aws:lambda:us-east-1:486128539022:function:sp-providers-stack-reporter-custom-resource-prod-tmen2ec'
      OrgUid: !Ref OrgUid
      RoleArn: !GetAtt SFRole.Arn
      Alias: !Ref Alias
 Outputs:
  SFRoleArn:
    Description: 'ARN for the IAM Role used by Serverless Framework'
    Value: !GetAtt SFRole.Arn
 Parameters:
  OrgUid:
    Description: Serverless Framework Org Uid
    Type: String
  Alias:
    Description: Serverless Framework Provider Alias
    Type: String
  RoleName:
    Description: Serverless Framework Role Name
    Type: String
 ```
 </details>
 <details>
 <summary>Trust Relationship</summary>
 ```json
 {
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::486128539022:root"
            },
            "Action": "sts:AssumeRole",
            "Condition": {
                "StringEquals": {
                    "sts:ExternalId": "ServerlessFramework-7bf7ddef-e1bf-43eb-a111-4d43e0894ccb"
                }
            }
        }
    ]
 }
 ```
 </details>
 5. 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 the `serverless.yml` file to make it generate a **new DynamoDB table**, define an **environment variable**, the role that will be using the generated lambdas.
 {% tabs %}
 {% tab title="createCustomer.js" %}
 ```javascript
 'use strict'
 const AWS = require('aws-sdk')
 module.exports.createCustomer = async (event) => {
  const body = JSON.parse(Buffer.from(event.body, 'base64').toString())
  const dynamoDb = new AWS.DynamoDB.DocumentClient()
  const putParams = {
    TableName: process.env.DYNAMODB_CUSTOMER_TABLE,
    Item: {
      primary_key: body.name,
      email: body.email,
    },
  }
  await dynamoDb.put(putParams).promise()
  return {
    statusCode: 201,
  }
 }
 ```
 {% endtab %}
 {% tab title="serverless.yml" %}
 ```yaml
 # "org" ensures this Service is used with the correct Serverless Framework Access Key.
 org: testing12342
 # "app" enables Serverless Framework Dashboard features and sharing them with other Services.
 app: tutorialapp
 # "service" is the name of this project. This will also be added to your AWS resource names.
 service: Tutorial
 provider:
  name: aws
  runtime: nodejs20.x
  environment:
    DYNAMODB_CUSTOMER_TABLE: ${self:service}-customerTable-${sls:stage}
  iam:
    role:
      statements:
        - Effect: 'Allow'
          Action:
            - 'dynamodb:PutItem'
            - 'dynamodb:Get*'
            - 'dynamodb:Scan*'
            - 'dynamodb:UpdateItem'
            - 'dynamodb:DeleteItem'
          Resource: arn:aws:dynamodb:${aws:region}:${aws:accountId}:table/${self:service}-customerTable-${sls:stage}
 functions:
  hello:
    handler: handler.hello
    events:
      - httpApi:
          path: /
          method: get
  createCustomer:
    handler: createCustomer.createCustomer
    events:
      - httpApi:
          path: /
          method: post
 resources:
  Resources:
    CustomerTable:
      Type: AWS::DynamoDB::Table
      Properties:
        AttributeDefinitions:
          - AttributeName: primary_key
            AttributeType: S
        BillingMode: PAY_PER_REQUEST
        KeySchema:
          - AttributeName: primary_key
            KeyType: HASH
        TableName: ${self:service}-customerTable-${sls:stage}
 ```
 {% endtab %}
 {% endtabs %}
 6. Deploy it running **`serverless deploy`**
   1. The deployment will be performed via a CloudFormation Stack
   2. Note that the **lambdas are exposed via API gateway** and not via direct URLs
 7. **Test it**
   1. 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.
 #### **Mitigation Strategies**
 *   **Principle of Least Privilege:** Assign only necessary permissions to each function.
    ```yaml
    provider:
      iamRoleStatements:
        - Effect: Allow
          Action:
            - dynamodb:Query
            - dynamodb:Scan
          Resource: arn:aws:dynamodb:${self:provider.region}:*:table/my-table
    ```
 * **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 or if access to AWS is compromised as they will be readable from the lambdas configurations.
 #### **Mitigation Strategies**
 *   **Environment Variables:** Inject secrets at runtime without hardcoding.
    ```yaml
    provider:
      environment:
        DB_PASSWORD: ${ssm:/aws/reference/secretsmanager/my-db-password~true}
    ```
 * **Secrets Manager Integration:** Use services like **AWS Secrets Manager**, **Azure Key Vault**, or **HashiCorp Vault**.
 * **Encrypted Variables:** Leverage Serverless Framework’s encryption features for sensitive data.
 * **Access Controls:** Restrict access to secrets based on roles.
 * **Avoid Logging Secrets:** Ensure that secrets are not exposed in logs or error messages.
 ***
 ### **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.
    ```yaml
    plugins:
      - serverless-webpack
      - serverless-plugin-snyk
    ```
 * **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**.
    ```yaml
    plugins:
      - serverless-plugin-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.
    ```yaml
    functions:
      hello:
        handler: handler.hello
        events:
          - http:
              path: hello
              method: get
              authorizer: aws_iam
    ```
 *   **Rate Limiting and Throttling:** Prevent abuse by limiting request rates.
    ```yaml
    provider:
      apiGateway:
        throttle:
          burstLimit: 200
          rateLimit: 100
    ```
 *   **Secure CORS Configuration:** Restrict allowed origins, methods, and headers.
    ```yaml
    functions:
      hello:
        handler: handler.hello
        events:
          - http:
              path: hello
              method: get
              cors:
                origin: https://yourdomain.com
                headers:
                  - Content-Type
    ```
 * **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.
    ```yaml
    provider:
      vpc:
        securityGroupIds:
          - sg-xxxxxxxx
        subnetIds:
          - subnet-xxxxxx
    ```
 * **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.
    ```yaml
    resources:
      Resources:
        MyDynamoDBTable:
          Type: AWS::DynamoDB::Table
          Properties:
            SSESpecification:
              SSEEnabled: true
    ```
 * **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.
    ```javascript
    javascriptCopy code// Example in Node.js
    exports.hello = async (event) => {
      try {
        // Function logic
      } catch (error) {
        console.error(error);
        return {
          statusCode: 500,
          body: JSON.stringify({ message: 'Internal Server Error' }),
        };
      }
    };
    ```
 * **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 named `SERVERLESS_ACCESS_KEY`.
 #### **Security Risks**
 1. **Exposure Through Code Repositories:**
   * Hardcoding or accidentally committing Access Keys and License Keys to version control systems can lead to unauthorized access.
 2. **Insecure Storage:**
   * Storing keys in plaintext within environment variables or configuration files without proper encryption increases the likelihood of leakage.
 3. **Improper Distribution:**
   * Sharing keys through unsecured channels (e.g., email, chat) can result in interception by malicious actors.
 4. **Lack of Rotation:**
   * Not regularly rotating keys extends the exposure period if keys are compromised.
 5. **Excessive Permissions:**
   * Keys with broad permissions can be exploited to perform unauthorized actions across multiple resources.
 {% hint style="success" %}
 Learn & practice AWS Hacking:<img src="../.gitbook/assets/image (1) (1) (1) (1).png" alt="" data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<img src="../.gitbook/assets/image (1) (1) (1) (1).png" alt="" data-size="line">\
 Learn & practice GCP Hacking: <img src="../.gitbook/assets/image (2) (1).png" alt="" data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<img src="../.gitbook/assets/image (2) (1).png" alt="" data-size="line">](https://training.hacktricks.xyz/courses/grte)
 <details>
 <summary>Support HackTricks</summary>
 * Check the [**subscription plans**](https://github.com/sponsors/carlospolop)!
 * **Join the** 💬 [**Discord group**](https://discord.gg/hRep4RUj7f) or the [**telegram group**](https://t.me/peass) or **follow** us on **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks_live)**.**
 * **Share hacking tricks by submitting PRs to the** [**HackTricks**](https://github.com/carlospolop/hacktricks) and [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
 </details>
 {% endhint %}
--- a/pentesting-ci-cd/vercel-security.md
+++ b/pentesting-ci-cd/vercel-security.md