Challenge, Medium,  on  Security, Linux, Containers

A Simple Sandbox Breakout: Spot It and Stop It

You're given SSH access to a CI host that might have been compromised. A sandboxed "agent" is running in the background - it's our prime suspect.

Your mission has two parts:

  1. Confirm the breakout. Look around the host for evidence that the sandboxed agent has escaped and is doing something on the host.
  2. Mitigate it. Neutralize the breakout so the agent can no longer touch the host. Do not stop or restart the sandbox itself - the sandbox VM must stay up for further investigation.

The verification task observes the host and checks if there are any recent signs of the breakout. If the host remains unaffected for at least 30 seconds, the challenge is considered solved.

Hint 1 - Where to start looking

Take a look around the host's / folder. Are there any suspicious files there? Try removing them and see whether they come back.

Hint 2 - Noisy guests leave traces

Check the host's syslog / journal for any suspicious messages.

Hint 3 - Three pillars of sandboxing

Sandboxing has three dimensions - process isolation, filesystem isolation, and network isolation. A microVM sandbox provides strong coverage of the first two categories. But is the network properly secured?

The sandboxed workload is isolated from the host, but it can still talk to it over the network.
Hint 4 - Attack surface on the host

What can a sandboxed program talk to on the host? Check all the open ports on the host, and think about which of them should be better protected from untrusted workloads.

Hint 5 - The power of the Docker API

Did you know that gaining access to a Docker daemon's API is as powerful - and as bad - as gaining root access to the server? If the daemon is reachable without authentication, the game is essentially over.

Hint 6 - Shutting the door

Can you find a way to protect the local Docker daemon from being reached by a rogue sandboxed workload? There's more than one valid approach - anything from reconfiguring the daemon's listeners to adding packet-filtering rules in front of it will do.

But do not just kill the Docker daemon - the CI host must still be able to use it to build other projects.

How to Author Challenges on iximiuz Labs

Instead of providing a subpar online editing experience, iximiuz Labs offers a helper CLI tool called labctl, allowing you to use your favorite text editor (or a full-featured IDE) to write content from the comfort of your local machine.

Install labctl CLI

curl -sf https://labs.iximiuz.com/cli/install.sh | sh

This will download and install the latest version of the labctl CLI. You only need to do this once per workstation.

Authorize labctl

labctl auth login

This will open a browser window asking you to authorize labctl to access your account. You need to do it after a fresh install of labctl and repeat it whenever the auth session expires.

Pull challenge content

labctl content pull challenge sandbox-simple-breakout

This will create a local copy of the challenge content in a directory named sandbox-simple-breakout. You only need to do this once per challenge.

Stream your changes

labctl content push -fw challenge sandbox-simple-breakout

Run this command in a separate terminal to continuously upload your changes to the server while editing the challenge in your favorite text editor or IDE.

You can also use labctl to create, list, and delete your content. Learn more about the available commands: labctl content --help

Start challenge