Container Escape in Dynamodb

A successful container escape gives an attacker execution on the host (or underlying VM) where the container runs. In AWS environments that host containers—EC2 instances, ECS/EKS nodes, or Lambda containers—the host typically possesses an IAM role attached to the instance or task. Once the attacker escapes, they can query the instance metadata service (IMDS) to obtain temporary credentials for that role and then use the AWS SDK to interact with DynamoDB tables.

Typical attack steps:

• Escape the container – exploiting a vulnerability such as CVE-2019-5736 (runc) or misconfigurations like privileged containers, --cap-add=SYS_ADMIN, or mounting /proc.
• Retrieve IAM credentials – from http://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name> (IMDSv1) or via the token‑required IMDSv2 endpoint if the instance still accepts v1 requests.
• Call DynamoDB APIs – using the stolen credentials to run Scan, DeleteTable, PutItem, or BatchWriteItem against any table the role can access, leading to data exfiltration, destruction, or unauthorized writes.

Example of what an attacker might run after escaping (Node.js AWS SDK v3):

import { DynamoDBClient, ScanCommand } from "@aws-sdk/client-dynamodb";

// Credentials are fetched from the instance metadata service automatically
const client = new DynamoDBClient({ region: "us-east-1" });

const params = {
  TableName: "ProductionOrders",
  Limit: 100
};

try {
  const data = await client.send(new ScanCommand(params));
  console.log("Exfiltrated items:", data.Items);
} catch (err) {
  console.error("DynamoDB access failed:", err);
}

This demonstrates how a container escape can directly lead to unauthorized DynamoDB access when the host’s IAM role is over‑privileged.

Detecting the risk involves looking for conditions that make container escape possible and that would allow the escaped process to reach DynamoDB credentials.

• IMDS exposure – containers that can reach 169.254.169.254 without requiring IMDSv2 tokens are vulnerable to SSRF‑style credential theft.
• Privileged or overly permissive containers – running with --privileged, --cap-add=SYS_ADMIN, or mounting host paths like /var/run/docker.sock or /proc increases escape surface.
• Exposed Docker or container APIs – an open Docker daemon socket (unix:///var/run/docker.sock) inside a container lets an attacker spawn new containers with host privileges.
• Missing runtime defenses – absence of seccomp profiles, AppArmor/SELinux, read‑only root filesystems, or non‑zero user IDs.

middleBrick can help identify the network‑exposed parts of this chain during its unauthenticated black‑box scan:

• It tests for SSRF to the instance metadata endpoint (both IMDSv1 and IMDSv2) and flags if a token‑less request returns credentials.
• It checks for open Docker API ports (e.g., 2375 or 2376) and for exposed environment variables that contain AWS keys.
• It reports findings under the "Property Authorization" and "SSRF" categories, providing severity, remediation guidance, and a reference to the specific endpoint tested.

Example of running middleBrick from the CLI against a public API that runs inside a container:

middlebrick scan https://api.example.com/orders

The output will include a finding such as:

SSRF to IMDSv1 detected – token‑less request returned IAM role credentials.
Severity: High
Remediation: Enforce IMDSv2, disable IMDSv1, and restrict network policies to prevent containers from reaching 169.254.169.254.

By surfacing these network‑level weaknesses, middleBrick gives developers actionable insight before an attacker can leverage a container escape to reach DynamoDB.

Mitigating the risk requires hardening the container runtime and applying least‑privilege IAM principles so that even if an escape occurs, the attacker cannot obtain useful DynamoDB credentials.

Container hardening

• Run containers as a non‑root user (USER 1000:1000 in Dockerfile).
• Drop all unnecessary Linux capabilities (--cap-drop ALL) and only add back those explicitly required.
• Use a read‑only root filesystem (--read-only) and write only to explicit volumes.
• Apply a strict seccomp profile (e.g., Docker’s default default.json or a custom profile that blocks keyctl, open_by_handle_at, etc.).
• Enable AppArmor or SELinux profiles in enforce mode.
• Avoid privileged containers and never mount /var/run/docker.sock or /proc unless absolutely required.

IMDS protection

• Enforce IMDSv2 only and disable IMDSv1 (metadata-options http-tokens=required).
• Use network policies or security groups to block outbound traffic to 169.254.169.254 from containers that do not need it.
• Consider using AWS Systems Manager Parameter Store or Secrets Manager with IAM roles for tasks instead of relying on instance metadata.

Least‑privilege IAM for DynamoDB

• Attach to the EC2 instance, ECS task, or EKS pod an IAM role that grants only the specific DynamoDB actions needed (e.g., dynamodb:GetItem, dynamodb:PutItem on a particular table).
• Use IAM policy conditions to restrict access by VPC endpoint or by source IP.
• Enable DynamoDB fine‑grained access control via VPC endpoint policies to limit which tables can be reached from a given VPC.
• Turn on DynamoDB encryption at rest (AWS‑owned or customer‑managed CMK) and enable DynamoDB Streams with Lambda logging for anomaly detection.

Example Dockerfile that applies many of the hardening steps:

FROM node:20-alpine
# Create non‑root user
RUN addgroup -S app && adduser -S -G app app
WORKDIR /app
COPY package*.json .
RUN npm ci --only=production
COPY . .
USER app
# Drop all capabilities (will be applied at run time)
# Read‑only rootfs, non‑privileged port
EXPOSE 3000
CMD ["node", "server.js"]

Example of starting the container with runtime hardening:

docker run --rm \
  --read-only \
  --tmpfs /tmp \
  --cap-drop ALL \
  --security-opt seccomp=default.json \
  --security-opt apparmor=docker-default \
  -p 3000:3000 \
  myapi:latest

With these controls in place, even if an attacker manages to escape the container, the host’s IAM role will be inaccessible or overly restricted, preventing them from leveraging stolen credentials to read, modify, or delete DynamoDB tables.