HTB: EDITOR

Hack the Box: Editor

Machine difficulty: Easy

Setting up the environment

Refer the blog on the machine MEOW to configure and connect to the HTB VPN.

Cracking EDITOR

STEP 1: Launch the machine

In order to use the machine, we must first launch an instance of it. However, connecting to the VPN is necessary before the machine can be spawned. If you're unsure where to begin, take a look at my Meow walkthrough where I already discussed on the topic. You will be granted an IP address once you have joined and created a machine.

STEP 2: Check its status

Ping the host to see if alive. We can use the ping tool to test if the machine responds to our ICMP messages in order to verify that we can interact with it. You may do this from the terminal by entering ping followed by the device's IP address as shown in the image above.

STEP 3: Enumeration

Using nmap we enumerate that ports 22, 80 and 8080 are open. On trying the default passwords for port 22(ssh) there were no successful results. On opening port 80 on the browser the name allotted for the port is http://editor.htb. Once viewed add it to the /etc/hosts to access the functionality. This can be done by the command: sudo vim/etc/hosts and the enter the ip along with the domain name and save the file.

On adding it to the /etc/hosts file we will be able to view the website as below:

I switched to the main website and its subdomains after directory fuzzing failed to yield any useful results. Even typos, footers, and banners are important details. The platform, XWiki 15.10.8, was disclosed in the page footer. I looked for public vulnerabilities in this version because older builds frequently map to known problems. A brief search turned up CVE-2025-24893, a critical unauthenticated RCE that affects XWiki versions prior to 15.10.11. The emphasis then changed from general recon to specific validation of that exposure.

After identifying the application as XWiki, I researched publicly disclosed issues affecting the detected version and found CVE-2025-24893, a remote code execution vulnerability referenced by a corresponding GitHub repository. Given the potential impact, I cloned the repository and, following the usage guidance in its README, proceeded to validate the finding within the lab’s authorized scope.

As seen below I used cat to read the example and syntax f the given poc.

Now for the user flag, I ran the exploit and always remember to listen. I used netcat for this as shown below:

Reviewing /etc/passwd helps map local accounts and understand the operating context. From the RCE foothold as xwiki, I noted additional users such as netdata and oliver. I focused on accounts more likely tied to active services or interactive logins.

After obtaining access, I conducted careful post-exploitation enumeration with a focus on sensitive items, including application configuration files, service definitions, and credential stores. In web applications, configurations often reveal environment variables, database endpoints, API keys, or authentication settings. I examined all relevant configuration paths and managed outputs carefully, paying attention to unusual values and filtering out standard defaults. The aim was to distinguish important information from irrelevant details and pull out only what significantly added to context or access.

During a systematic review of configuration files, I traversed the web application’s directory structure and identified WEB-INF/hibernate.cfg.xml. Inspecting this file revealed database connection parameters, including a username and password. This highlights the value of meticulous configuration auditing and careful directory navigation when assessing web applications in a lab environment.

Again, I used cat to view the contents of the config file.

In the config file we find a password and a username.

Noting that SSH was exposed, I attempted authentication with the recovered credentials. Access as xwiki was unsuccessful, so I tested the same password for the oliver account, which successfully authenticated. This validated the credential reuse and provided an interactive shell for further analysis

And there we have the user flag.

Step 4: Privilege escalation

Running ss -tulpn enumerates listening sockets on the host; the output shows several services bound to loopback (e.g., 127.0.0.1:19999, 127.0.0.1:3306, 127.0.0.1:53), meaning they are only reachable locally and not exposed to the network. In practice, 127.0.0.1:19999 strongly suggests a local Netdata instance, while :80, :8080, and :22 indicate services accessible on external interfaces. Because this was executed as a non-root user, the -p (process) details are masked for other users’ services. The takeaway is that local-bound services require on-host access (or an authorized tunnel) to interact with them, whereas the externally bound ports are directly reachable from the network.

To reach the Netdata service bound to loopback on the target (127.0.0.1:19999), I established an SSH local port forward, which maps a local port on my workstation to the remote loopback address. The SSH login succeeded, but the client reported “bind [127.0.0.1]:19999: Address already in use”—meaning my chosen local port was occupied, so that specific forward didn’t attach. Repeating the tunnel with an unused local port resolved it; from there, browsing to http://127.0.0.1:<chosen_port> on my machine proxied directly to the remote Netdata UI without exposing it to the network.

On entering we see the UI of the loopback address in the browser and the thing that caught my eye was “Critical needs updating”

On further research I found CVE-2024-32019 was exploitable on the netdata version.

Vulnerability (CVE-2024-32019). In Netdata versions up to 1.45.2 (prior to patch), the ndsudo helper is installed set-UID root and resolves permitted commands via the PATH environment. If a local, low-privileged user can influence PATH and place a look-alike executable with the expected name ahead of system directories, ndsudo may execute that binary with root privileges. This results in a local privilege escalation. The recommended remediation is to upgrade to a fixed release; administrators can also remove the SUID bit from ndsudo, sanitize the environment, and ensure absolute paths are used.

Plain-language summary. Netdata includes a root-privileged helper that calls certain tools by name. Because it trusts PATH, a user who controls their environment can position a counterfeit executable so it’s found first, causing the helper to run it as root.

In a sanctioned test environment, you can:

·       confirm the presence and SUID status of ndsudo;

·       create a harmless test executable that reports its effective user ID;

·       place it in a writable, executable directory;

·       ensure it’s executable;

·       adjust the test process’s PATH so that directory precedes system paths.

Invoking the helper with the target command name will demonstrate the issue if the system is vulnerable. Remove all artifacts afterward and apply the patch or hardening controls.

POC:

https://github.com/AliElKhatteb/CVE-2024-32019-POC?source=post_page-----3c1edb9f4e8a---------------------------------------

I compiled the code then changed into my home directory before starting python3 server 8080.

After preparing the test binary, I adjusted the environment so my controlled directory appeared first in PATH. I then located the ndsudo helper and confirmed its location. Invoking it with a permitted subcommand caused name resolution to favor my binary, which executed with elevated privileges in the lab. This resulted in a root shell, after which retrieving the root flag was straightforward.

Use a lister in his case again netcat.

And there we have the root flag!