About the Machine
Editor is an Easy Linux machine that combines web exploitation, credential reuse, and privilege escalation in a realistic attack chain. The initial foothold is obtained by exploiting a vulnerable version of XWiki (CVE-2025-24893) running on port 8080, which allows remote code execution and provides shell access as the low-privileged xwiki user. Further enumeration of configuration files reveals database credentials that are reused by the system user oliver, granting SSH access and user-level flag retrieval.
Privilege escalation is achieved through a misconfigured Netdata ndsudo plugin affected by CVE-2024-32019. By compiling a malicious binary and manipulating the PATH, an attacker can escalate privileges to root and capture the final flag. Overall, Editor is a well-balanced machine that teaches the importance of patch management, credential hygiene, and the risks of insecure SUID binaries in production systems.
The Nmap scan revealed that three ports were open:
- Port 22 (SSH) — running OpenSSH 8.9p1 on Ubuntu.
- Port 80 (HTTP) — serving content through nginx 1.18.0. The HTTP title revealed "Editor – SimplistCode Pro"
- Port 8080 (HTTP) — running Jetty 10.0.20, hosting XWiki at
/xwiki/bin/view/Main/. XWiki is a Java-based wiki platform, and this instance exposed WebDAV methods (PROPFIND,LOCK,UNLOCK) — potentially dangerous if misconfigured.
The WebDAV scan hinted that the server might allow certain file operations via HTTP methods not normally available. The robots.txt file was particularly interesting — it listed 50 disallowed paths, many related to editing, creating, and deleting wiki content.
From the OS detection, the host appeared to be running Linux kernel 5.x, with a possibility of MikroTik RouterOS somewhere in the path — probably part of the network routing rather than the target OS itself.
At this stage, my gut told me the real action was going to be in XWiki on port 8080, with nginx on port 80 possibly acting as the public-facing front end. Given the presence of editing-related paths in robots.txt and risky HTTP methods, it was clear my next move was to dig into the wiki’s configuration and see if I could find any way to gain write or upload access.
With the hostname in place, I pointed my browser to http://editor.htb:8080/. The page loaded a clean, wiki-style interface — a quick glance at the footer confirmed it was running XWiki Debian 15.10.8.
This was a big lead. XWiki is a Java-based wiki platform, and certain versions are known to have vulnerabilities, especially when editing features or administrative pages are exposed. Given that my earlier Nmap scan had already uncovered a robots.txt file full of editing-related paths, I suspected there might be misconfigurations or outdated components here that I could exploit.
Knowing the site was running XWiki Debian 15.10.8, I immediately went hunting for any public exploits tied to that version. It didn’t take long I found CVE-2025-24893, a recently disclosed Remote Code Execution (RCE) vulnerability affecting XWiki versions prior to 15.10.11, 16.4.1, and 16.5.0RC1.
The flaw allowed an attacker to execute arbitrary code on the server by abusing a vulnerable component within XWiki’s scripting engine. Since my target was running 15.10.8 — squarely in the vulnerable range — this was definitely worth trying.
I located a working proof-of-concept on GitHub:
http://editor.htb:8080/ to test whether the vulnerability was exploitable in this environment.Before launching the exploit, I needed to make sure my reverse shell would call back to the right address.
A quick check with ifconfig showed that my VPN interface tun0 was assigned the IP 10.10.14.45 — this would be the address the target connects back to once the payload executes.
With that in hand, I navigated into the cloned exploit directory:
With my reverse shell successfully connected, I started poking around the XWiki installation directory to see if any sensitive configuration files were lying around. A quick look under /usr/lib/xwiki/WEB-INF revealed a promising candidate — hibernate.cfg.xml.
Hibernate configuration files often contain database credentials, so I decided to check for any password fields:
xwiki passwords, but one line immediately stood out:While exploring the system, I eventually checked /home/ to see which user accounts existed. Among the directories, one in particular caught my attention — oliver. Since I had already recovered a potential password (theEd1t0rTeam99) from the XWiki configuration file, I decided to see if it worked for this account over SSH.
From my attack machine, I ran:
When prompted for a password, I entered theEd1t0rTeam99. To my satisfaction, the login succeeded, and I was greeted with a shell as oliver@editor — a much more stable foothold than my initial reverse shell.
The first thing I did was check the home directory for the user flag:
user.txt. I wasted no time in reading its contents:
With the user flag secured, I turned my attention to privilege escalation. A common first step is to search the system for SUID binaries — files that run with the permissions of their owner (often root), even when executed by a normal user. This can sometimes lead to privilege escalation if the binary is vulnerable or misconfigured.
I ran the following command to look for any files owned by root with the SUID bit set:
/usr/bin/passwd, /usr/bin/su, and /usr/bin/sudo, but one entry immediately stood out:ndsudo before. Given its location under /opt/netdata/, it appeared to be part of the Netdata monitoring suite. The name suggested it might be a privileged helper tool — and if it was improperly restricted, it could potentially be abused to run commands as root.
Digging deeper into the suspicious ndsudo binary, I decided to see if it had any known vulnerabilities. A quick search led me to a GitHub repository by AzureADTrent containing a proof-of-concept for CVE-2024-32019 - a local privilege escalation targeting the ndsudo utility bundled with Netdata.
According to the write-up, ndsudo can be tricked into executing arbitrary commands as root by abusing its handling of trusted commands. Specifically, the exploit works by planting a malicious binary in a directory that appears early in the user’s PATH environment variable. When ndsudo attempts to run a legitimate tool - in this case nvme - it will instead execute the attacker’s fake binary, but with root privileges.
This meant I didn’t need a memory corruption or race condition - just a bit of path hijacking. If successful, I’d be able to run any command I wanted as root, effectively giving me full control of the system.
My next step was clear: recreate the PoC’s setup, poison the PATH, and let ndsudo do the privilege escalation for me. With the PoC in hand, I cloned the exploit repository to my local machine:
poc.c) that made the exploit’s intent crystal clear. The code simply set the user ID and group ID to 0 (root) and then executed /bin/bash. Essentially, this binary would become a root shell as soon as it was run by ndsudo.
nvme so it would impersonate the legitimate command ndsudo expects to run:nvme binary onto the target machine. I used SCP to copy it over to /tmp/ on the editor.htb box:
theEd1t0rTeam99), and successfully transferred the binary.PATH and trick ndsudo into running this fake nvme to escalate straight to root.nvme binary sitting in /tmp/, I made it executable:PATH environment variable so that when ndsudo tried to execute nvme, it would actually run my trojanized version in /tmp/ instead of the legitimate one:ndsudo utility with the nvme-list command:
nvme, ndsudo executed my malicious binary - and because it ran with elevated privileges, I was instantly dropped into a root shell:/root/ directory and read the root flag:
0 Comments