Serverless pentest: AWS Lambda, Cloud Functions, Azure Functions y Workers

Serverless computing eliminó el concepto de servidor persistente del paradigma de desarrollo moderno. Con AWS Lambda, Google Cloud Functions, Azure Functions y Cloudflare Workers, los desarrolladores escriben funciones que se ejecutan on-demand en response a eventos (HTTP requests, file uploads, queue messages, scheduled triggers). La plataforma gestiona infraestructura, scaling, availability. Los developers no se preocupan de servers, OS patching, o capacity planning. Para los auditores de seguridad, esto significa que el modelo mental tradicional de pentesting no aplica: no hay SSH para hacer, no hay persistent compromise, no hay lateral movement clásico.

Esta lección cubre los vectores específicos de serverless: event injection, over-privileged roles, layer poisoning, dependency confusion, cold start abuse, denial-of-wallet attacks, y los patrones defensivos modernos. Es la tercera lección del bloque red team avanzado de la Tanda 6, extendiendo las lecciones previas de cloud IAM (AWS, Azure, GCP) al paradigma event-driven.

Prueba solo en accounts propios o autorizados. Serverless resources acumulan cargos; abuse genera costs rápidamente.

Paradigma shift#

Diferencias cruciales:

• Ephemeral: function runs for seconds (max 15min AWS Lambda), then dies.
• Event-driven: triggered por HTTP, queues, files, schedules.
• Multi-tenant: shared infrastructure con other customers.
• Pay per invocation: costs linked a execution volume.
• Platform-managed: patching, scaling por vendor.
• Stateless: state goes to databases, caches, object storage.

Para pentesting:

• No SSH / persistent access.
• No lateral movement en el sentido tradicional.
• Focus on: event payload manipulation, role abuse, dependencies, platform-specific issues.
• Attack cost: denial-of-wallet is real vector.

Vectores específicos#

Event injection#

El event payload es input del cliente. Si function no sanitiza, vulns clásicas aplican:

• SQL injection si function queries DB.
• Command injection si function invokes shell.
• SSRF si function fetches URLs.
• Path traversal en file operations.

Específico serverless: event source variation. Function triggered por API Gateway tiene distinto schema que S3 event. Confusion entre sources puede llevar a validation gaps.

Over-privileged IAM roles#

Cada function tiene execution role. Common misconfig: roles con *:* permissions (Owner, Editor en GCP; AdministratorAccess en AWS). Si function compromise → attacker usa role credentials para explorar accountwide.

Example attack: SSRF en Lambda → curl 169.254.169.254/latest/meta-data/iam/security-credentials/ → credentials → aws s3 ls.

(Cross-reference: SSRF a metadata lesson en Tanda 4.)

Layer poisoning#

AWS Lambda y Azure Functions permiten layers (shared libraries añadidas al function environment). Si attacker puede modify layer (via misconfig IAM o supply chain), todas las functions usando layer son comprometidas.

Variantes:

• Public layer malicioso: user adds untrusted layer.
• Internal layer modification: insider threat o IAM misconfig.
• Dependency confusion: npm/PyPI package con mismo nombre que private package.

Cold start timing#

Primera invocation de function después de inactivity triggers "cold start" (container initialization). Observable delay. Side-channel potential:

• Function existence probing.
• Resource allocation inference.
• Timing-based attack on crypto operations.

Not commonly exploited pero research continues.

Denial of wallet#

Attacker triggers massive function invocations → cloud bills explode. Para startups con limited budget, catastrophic.

Vectors:

• Public-facing function sin rate limiting.
• Recursive lambda (function invokes itself o otras).
• SQS/Kinesis trigger flooding.

Example documented: startup con Lambda procesando image uploads, attacker uploaded miles of large images, bill went from $50/month a $10,000/month en horas.

Timing-based data leaks#

Multi-tenant platforms: previous customer execution puede dejar traces en shared container reused (warm container). Specific patterns:

• Residual environment variables.
• Temporary files no clean sin cleanup.
• Cached DNS lookups.

AWS Firecracker reduces mucho con microVMs; otros less isolated.

Platform-specific bugs#

Historical issues:

• AWS Lambda - 2018: CVE where Lambda could access other Lambdas' /tmp. Patched.
• Azure Functions - various: shared storage issues.
• GCP Cloud Functions: metadata service edge cases.

Vendors patch rápido pero research continues.

Herramientas de audit#

• ScoutSuite: covers serverless config audit.
• CloudFox: discovery + config of functions.
• FunctionShield: runtime protection (comercial).
• Snyk: dependencies de functions.
• PureSec (now Prisma): serverless security platform.
• AWS IAM Access Analyzer: detects over-privileged functions.

Manual audit checklist:

• Function IAM role permissions.
• Environment variables (secrets hardcoded?).
• Layers used (trusted?).
• Dependencies versions (vulns known?).
• Trigger config (public API Gateway?).
• Rate limiting (concurrent executions, reserved concurrency).
• Logging + monitoring (CloudWatch, Cloud Logging, App Insights).
• Encryption at rest + in transit.

OWASP Serverless Top 10#

OWASP published Serverless Top 10 (2017, updated). Key items:

• SAS-1: Function event data injection.
• SAS-2: Broken authentication.
• SAS-3: Insecure serverless deployment config.
• SAS-4: Over-privileged function permissions.
• SAS-5: Inadequate monitoring.
• SAS-6: Insecure third-party dependencies.
• SAS-7: Insecure secrets storage.
• SAS-8: Inappropriate exception handling.
• SAS-9: Legacy / unused functions (not patched, forgotten).
• SAS-10: Cross-execution data persistency.

Defensa#

Principle of least privilege#

Function roles con minimum permissions. Cada function with role específico (no shared). AWS SAM / Serverless Framework pueden generate automatically.

Secrets management#

Never hardcode secrets en environment variables (visible in config). Use:

• AWS Secrets Manager / Parameter Store.
• Azure Key Vault.
• GCP Secret Manager.
• HashiCorp Vault.

Function retrieves at invocation.

Rate limiting#

• API Gateway with throttling.
• AWS Lambda reserved concurrency.
• Azure Functions consumption plan limits.
• GCP Cloud Functions max instances.

Prevents denial of wallet + abuse.

Input validation#

Treat event data as untrusted. Schema validation (JSON Schema). Sanitize before use.

Dependency hygiene#

• Lockfiles (package-lock.json).
• Automated scans (Snyk, Dependabot).
• Review before updates.

Monitoring#

• Execution counts + patterns.
• Error rates.
• Cost anomalies (billing alerts).
• Security events (CloudTrail Lambda API calls).

Function lifecycle#

• Code reviews.
• Remove unused functions.
• Update dependencies regularly.
• Patch versioning.

Multi-cloud comparación#

Cloudflare Workers son unique: V8 isolates en lugar de containers, much faster cold start, different security model (no filesystem, limited APIs).

Walkthrough: audit de Lambda#

Para fijar el patrón, un flujo típico contra AWS Lambda function de un target.

Paso 1 — enumeración:

# Con credentials con permission list
aws lambda list-functions --region us-east-1

# Para cada function
aws lambda get-function --function-name <name>
# Devuelve: Role ARN, Handler, Runtime, Environment variables, Layers

Paso 2 — review IAM role:

aws iam get-role --role-name <lambda-role>
aws iam list-attached-role-policies --role-name <lambda-role>
aws iam list-role-policies --role-name <lambda-role>

# Review permissions - buscar overly broad (s3:*, dynamodb:*, iam:*)

Paso 3 — environment variables review:

# Via get-function response
# Chequear secrets hardcoded (DB passwords, API keys)

Paso 4 — layers check:

aws lambda get-layer-version --layer-name <layer> --version-number N
# Review source, es trusted? publicly accessible?

Paso 5 — trigger config:

aws lambda get-policy --function-name <name>
# Who can invoke this function?
# Public API Gateway? S3 trigger? Event bridge?

Paso 6 — code download:

aws lambda get-function --function-name <name> --query Code.Location
# Download code, review for vulnerabilities

Paso 7 — event simulation:

Try injection payloads via trigger. Monitor response + CloudWatch logs.

Paso 8 — reporte: findings con severity based en impact del compromise (data access, cost, etc.), fixes específicos.

Rol del lambda como pivoting primitive#

Interesting pattern: Lambda compromise como pivoting mechanism. Attacker:

1. Compromises Lambda function (via event injection o layer poisoning).
2. Lambda has IAM role with permissions.
3. Attacker uses role to access other resources (S3, DynamoDB, RDS via VPC, Kinesis).
4. Depending on role, lateral movement to other Lambdas, modify them, chain compromise.

En cloud-native architectures where Lambda es core, es ruta de attack realistic.

Defense: least privilege per function + resource-level access controls + network isolation (VPC + Private Link) + monitoring de API calls anómalos.

Errores comunes#

• Lambda con * IAM policy «for convenience».
• Secrets en env vars committed to Git.
• No rate limiting → denial of wallet.
• Shared layer sin version pinning.
• Not monitoring billing anomalies.
• Legacy functions nunca updated.
• Trust en event source identity sin verify.

Preguntas frecuentes#

¿Pentest de serverless es más fácil o más difícil?#

Diferente. Menos reconnaissance (menos surface visible), pero focus en configuration + dependencies + events. Tools IT clásicos poco útiles; cloud-specific tools critical.

¿Workers de Cloudflare más seguros que Lambda?#

Diferentes trade-offs. Workers isolation model (V8) blocks many classical attacks (filesystem, network expansivo). Pero limited APIs, debugging harder. Lambda más flexible, mayor surface.

¿Serverless mata lateral movement?#

No elimina, cambia. Post-function-compromise, attacker uses function's IAM role para access cloud resources (S3, DynamoDB, etc.). «Lateral movement» es via cloud APIs, not network.

¿Cost de serverless security tools justificable?#

For small orgs with couple functions: manual + Snyk suficient. Mid-size con many functions + regulated industry: specialized tools (PureSec, FunctionShield) valen la pena.

¿Dónde practico?#

El laboratorio armageddon de whoami-labs incluye deployment serverless simulado: Lambdas con IAM policies amplias, event injection vulnerabilities, layer con known CVEs. Practicas identification, exploitation, mitigation.

¿Edge computing (Workers, Vercel) cambia pentest?#

Significativamente. V8 isolate model muy different de Lambda container. No filesystem, limited APIs, mucho mejor isolation. Vectors: KV namespace abuse, Durable Objects compromise, Workers AI prompt injection (relevant con lección AI).

¿Cold start es exploitable en prod?#

Edge cases. Research académico muestra side-channels teóricos. Exploitation práctica en prod requires conditions específicas. Not primary vector 2026.

¿Serverless mata containers?#

No. Each tiene use cases. Serverless: event-driven, bursty, short tasks. Containers: long-running, stateful, complex dependencies. Many architectures hybrid.

¿Dependency scanning es sufficient?#

Base necesaria pero no suficiente. Snyk/Dependabot catchean known CVEs. Novel vulnerabilities, business logic issues, IAM misconfigs requieren audit manual. Combinación needed.

¿Vendor escapes (Firecracker, etc.) son concern?#

Para most teams no. Isolation de Firecracker (AWS) es strong; last public escape 2018. For nation-state threats, maybe. For typical corporate threats, focus on config issues antes que vendor bugs.

¿Cómo manage secrets en serverless?#

Native secrets managers: AWS Secrets Manager, Azure Key Vault, GCP Secret Manager. Fetch at cold start, cache en memory for warm invocations. Never hardcode en environment variables (visible en config exports).

Resumen#

• Serverless: event-driven, ephemeral, multi-tenant, pay-per-invocation.
• Paradigm shift: no persistent access, no classical lateral movement.
• Vectores: event injection, over-privileged roles, layer poisoning, cold start timing, denial of wallet.
• OWASP Serverless Top 10 canonicalizes risks.
• Herramientas: ScoutSuite, CloudFox, Snyk, Prisma Cloud (ex-PureSec).
• Defensa: least privilege IAM, secrets manager, rate limiting, input validation, dependency scanning, monitoring.
• Plataformas: AWS Lambda dominant, Cloudflare Workers unique isolation model.

Casos famosos#

Algunos incidentes serverless documentados en 2022-2026:

• Denonia (2022): primer malware específico para AWS Lambda detectado en wild. Golang backdoor.
• Denial of wallet case startup (2023): Lambda-based image processor abused via public API para procesar images arbitrariamente grandes. Bill from $100 to $10k en 48h.
• Capital One revisited: aunque el breach original fue EC2 con SSRF, revelaciones posteriores mostraron sophisticated use de Lambda functions en lateral movement cloud-native.
• Multiple PyPI incidents: dependency confusion packages impacting Lambda deployments con private packages shadowed por public versions.
• Azure Functions Storage Shared Key (2023): misconfigured functions con storage shared keys permitiendo cross-tenant access.

Cada caso enseña: serverless tiene vulns únicos, defensa requires understanding específico del paradigma.

Rol en moderna cloud architecture#

En 2026, serverless es component central de arquitecturas event-driven. Patterns common:

• Microservices: cada microservice puede ser Lambda.
• Event-driven data processing: S3 trigger → Lambda → transform → DynamoDB.
• API backends: API Gateway + Lambda proxy integration.
• Scheduled jobs: EventBridge rules → Lambda.
• IoT ingestion: Kinesis → Lambda → store.
• CI/CD automation: triggered por GitHub webhooks.

Each pattern has implications for security: more surface, more roles to manage, more potential vectors. Auditor must understand architecture, not just function in isolation.

Fuentes y lecturas recomendadas#

• OWASP Serverless Top 10
• AWS Lambda Security Best Practices
• PureSec research
• Serverless Framework security