SLS-6: Security Misconfiguration

Before you start: make sure you are in the project directory.

cd /workspaces/very-vulnerable-serverless

Theory: What is Security Misconfiguration?

The code may be fine, but the settings are unsafe: secrets written in code, default or open permissions, debug left on. It is the easiest bug to find because the attacker just reads the repo or config.

Example: A password written in app.py and pushed to public GitHub. Anyone can copy it.

Objective

Hunt for hardcoded secrets, plaintext environment variables, and an over-broad IAM role in the project files.

Hardcoded Secrets in Source Code

Find the hardcoded secret in the application source code:

grep secret_key app.py

Output:

app.secret_key = 'ThisisSuperFlagBySecurityDojo'

Impact: The Flask secret key is hardcoded in a public repository. Anyone who reads the repo can forge session cookies, impersonate users, and bypass authentication entirely.

Plaintext Secrets in Environment Variables

Check for plaintext secrets in the deployment config:

grep -A1 'environment:' serverless.yml

Output:

environment:
  VARIABLE_1: supersecret99

Impact: This secret is stored in plaintext. It is visible in the serverless.yml file (committed to Git), the AWS Lambda console, the CloudFormation template, and the output of printenv — which we already demonstrated via command injection.

Overpermissive IAM Role

Check the IAM permissions:

grep -A4 'statements:' serverless.yml

Output:

statements:
  - Effect: Allow
    Action:
      - s3:*
    Resource: "*"

Impact: The Lambda function has full access to every S3 bucket in the AWS account. The function does not use S3 at all. Combined with command injection, stolen credentials give the attacker full S3 access.

Fix

• Load secrets from AWS Secrets Manager or SSM Parameter Store at runtime. Never commit secrets to source code.
• Reference secrets in serverless.yml with ${ssm:/app/variable_1}. Never store secrets as plaintext environment variables.
• Follow least privilege: grant only the specific actions on the specific resources the function needs.
• Run truffleHog or git-secrets in CI to catch leaks before they reach the repository.

Next step: Insecure Third-Party Components