Overview

The BrunnerCTF challenge presented a compelling scenario: a Dockerized WordPress installation running PHP 8.2 on Debian Trixie, deployed via Kubernetes. The objective was to move from an initial low-privilege shell to root access. The path to initial compromise involved a deliberately vulnerable WordPress plugin named wp2shell. However, the true test lay in privilege escalation, as the system was hardened against common container escape techniques and SUID exploits. The intended solution hinged on exploiting a recent, real-world vulnerability in sudo itself.

Reconnaissance and Initial Access

The challenge was distributed as a zip archive (boot2root_wordpressed-to-root.zip) containing the Docker build context. Examining the provided files revealed the structure:

.
├── docker
│   ├── entrypoint.sh
│   ├── install.php
│   └── seed.php
├── docker-compose.yml
├── Dockerfile
└── theme
    └── brunnerne-docs
        ├── footer.php
        ├── functions.php
        ├── header.php

The reconnaissance phase involved scanning the target, typically starting with Nmap. Ports commonly associated with web servers (like 80 for HTTP and 443 for HTTPS) would be primary targets. In this CTF, the web server was readily accessible, hosting a WordPress instance. The crucial piece of information was the presence of a vulnerable plugin, wp2shell. This plugin, likely designed with specific exploitable functions, served as the entry point. By crafting a request that leveraged a flaw in wp2shell, an attacker could achieve remote code execution, typically resulting in a shell with the web server's user privileges – in this case, www-data.

The wp2shell plugin's vulnerability could manifest in various ways, such as insecure deserialization, command injection through unsanitized input, or improper file upload handling. The goal was to trigger one of these flaws to execute a command on the server. A common technique is to use a tool like wfuzz or Burp Suite to fuzz parameters and identify endpoints, or to directly probe known vulnerable function names if documented or hinted at.

Upon successful exploitation, the attacker gains a www-data shell. This shell, however, is confined within the container and operates with limited privileges. The next stage is to understand the environment and identify pathways for privilege escalation.

Environment Analysis and Privilege Escalation Puzzles

Once inside the container as www-data, the immediate priority is to enumerate the system. This involves:

  • Checking the operating system and kernel version (uname -a).
  • Listing running processes (ps aux) to identify any unusual or high-privilege services.
  • Reviewing user and group information (id, cat /etc/passwd, cat /etc/group).
  • Examining file permissions, particularly for world-writable files or directories, and SUID/SGID binaries (find / -perm -u=s -type f 2>/dev/null).
  • Checking cron jobs (crontab -l, ls -la /etc/cron.*) for scheduled tasks that might be exploitable.
  • Looking for sensitive information in configuration files, application logs, or user home directories.

In BrunnerCTF, the challenge explicitly mentioned that common container escape vectors and SUID exploits were mitigated. This implies that standard techniques like exploiting misconfigured Docker socket mounts, vulnerable kernel modules, or well-known SUID binaries (like find, nmap, etc.) would not yield results. The hardening measures likely included restricting direct kernel access, limiting file system access, and ensuring all binaries had correct permissions.

The entrypoint.sh script within the docker directory is a critical file to analyze. This script runs when the container starts and often contains logic for setting up the environment, configuring services, or running initial security checks. Understanding its execution flow can reveal misconfigurations or hardcoded credentials.

Exploiting the Sudo Vulnerability

The intended privilege escalation vector was a recent CVE in sudo. This is a significant detail, as sudo is a fundamental utility for privilege management on Linux systems. Vulnerabilities in sudo can be extremely powerful, allowing a low-privilege user to execute commands as root. The specific CVE would need to be identified and researched. For example, if the vulnerability was related to how sudoedit or sudo -l handles specific commands or file types, that would be the focus.

A common pattern for sudo exploits involves finding a command that a user can run via sudo with elevated privileges, and then finding a way to abuse that command's functionality to execute arbitrary code. The sudoers file (typically located at /etc/sudoers or managed via visudo) dictates which users can run which commands as which other users. The command sudo -l run by the www-data user would reveal what privileges, if any, it has been granted. If www-data could run a specific command as root, and that command had a known vulnerability or could be manipulated to execute arbitrary code, then root access would be achievable.

Let's consider a hypothetical, but illustrative, recent sudo vulnerability. Suppose there was a CVE that allowed command injection when sudoedit was invoked on a file with a specific, unusual extension, or when a command was passed with certain arguments. The attacker would first confirm if the www-data user could execute sudoedit (or the vulnerable command) using sudo -l. If permitted, the next step would be to craft an exploit payload. This might involve creating a malicious file, or executing a command that leverages the sudo vulnerability to spawn a root shell.

The exact CVE and its exploitation method would be specific to the CTF's configuration. However, the general approach involves:

  1. Identifying the vulnerable sudo version or a specific sudo configuration that is exploitable.
  2. Confirming that the current user (www-data) can leverage this vulnerability via sudo -l.
  3. Crafting and executing the exploit payload to gain a root shell.

The surprising detail here is not the initial access method, which is a common CTF trope, but the reliance on a recent, real-world sudo vulnerability. CTFs often use older, well-known exploits. Using a current CVE makes the challenge more dynamic and requires up-to-date knowledge of security research.

Post-Exploitation and Cleanup

Once root access is achieved, the final step is to confirm the achievement, typically by reading a root.txt flag file. For a CTF, this usually involves navigating to a specific directory (e.g., /root/) and displaying the contents of a flag file.

The challenge design, with its hardened container and specific sudo CVE, provides a realistic simulation of modern penetration testing scenarios where attackers must move beyond automated scripts and delve into system-level vulnerabilities and configurations. The intention is to teach participants to look for less obvious privilege escalation paths when common methods fail.