Varia

Tunnels ssh

Qu’est-ce qu’un tunnel?

Normalement, l’encapsulation (par exemple d’une communication SSH) dans la pile TCP/IP est
constituée des couches suivantes :

SSH est encapsulé dans un paquet TCP, lui-même encapsulé dans une trame IP, etc. Mais si on utilisait
SSH pour encapsuler un autre protocole de la couche application (par exemple FTP, http ou autre) ? Ceci
aurait l’avantage de dissimuler la nature des communications (car elles sont chiffrées) et de contourner
certaines règles de pare-feu – en effet, si un pare-feu autorise les connexions ssh entrantes mais bloque
les connexions ftp, alors on peut contourner ce blocage en faisant passer les connexions ftp par un
tunnel ssh.

On utilise les tunnels dans d’autres applications, notamment les VPN où l’encapsulation peut être
similaire à celle-ci :

tunnel
Qu’est-ce que la redirection de ports?

Le programme ssh permet de faire ce qu’on appelle de la redirection de ports : essentiellement, de

prendre tous les paquets entrants sur le port n d’un hôte A et de les rediriger vers le port p d’un hôte B.
La redirection de ports est souvent utilisée sur les routeurs ou les pare-feux, en particulier lorsque ceux-
ci sont entre un réseau privé et un réseau public. Supposons que vous avez sur votre réseau à la maison
(un réseau privé) un serveur Minecraft et que vous souhaitez le rendre accessible de l’extérieur, vous
devrez activer la redirection de port sur votre routeur afin que les requêtes sur le port 25535 de votre
adresse publique soient redirigées vers le même port sur votre serveur :

Dans cet exemple, les paquets entrants sur l’interface externe à destination du port 25535 sont redirigés
à destination de 192.168.0.202 au port 25535. Plus précisément, il s’agit de remplacer les champs des
entêtes dans les paquets lorsqu’ils arrivent sur la passerelle :

Dans cet exemple, la redirection ne change que l’adresse IP de destination; le port de destination
demeure le même. Mais il serait tout-à-fait possible de changer aussi le port de destination.
Fonctionnement d’un tunnel ssh

La redirection de ports en ssh combine ces deux techniques : elle utilise un tunnel (chiffré par ssh) pour
transporter les données de la couche application, et aussi permet de modifier les IP et ports de
destination entre l’entrée et la sortie du tunnel :

Dans cet exemple, tous les messages entrants sur l’hôte A à destination de 10.1.1.10:3333 sont envoyés
dans le tunnel ssh et on change leur destination pour 172.16.1.30:445. Les deux hôtes reliés par le tunnel
peuvent se trouver sur n’importe quel réseau tant qu’une connexion ssh est possible entre les deux.
Aussi, un d’entre eux doit être le serveur ssh et l’autre doit être le client (on ne peut pas établir de tunnel
ssh entre deux clients ou deux serveurs).

Il y a deux types de redirection avec ssh: la redirection de locale et la redirection distante. Dans la
redirection locale, l’entrée du tunnel est sur le client ssh : la traduction des adresses et ports de
destination se fait du client vers le serveur. Dans la redirection distante, l’entrée du tunnel est sur le
serveur ssh : la traduction des adresses et ports de destination se fait du serveur vers le client.

Redirection locale

Si un hôte n’est pas accessible à partir du client mais l’est à partir du serveur, la redirection locale permet
d’y accéder à partir du client.

Pour établir un tunnel ssh comme dans l’exemple précédent, on doit lancer la commande suivante sur le
client ssh :

ssh -L 10.1.1.10:3333:172.16.1.30:445 bob@172.16.1.10

Redirection distante

Si un hôte n’est pas accessible à partir du serveur mais l’est à partir du client, la redirection distante
permet au serveur d’y accéder.

Pour établir un tunnel ssh comme dans l’exemple précédent, on doit lancer la commande suivante sur le
client ssh :

ssh -R 10.1.1.10:3333:172.16.1.30:445 bob@10.1.1.10

Utilité

Puisque ssh utilise le port 22 et que celui-ci est souvent ouvert sur les pare-feux de réseaux ou d’hôtes,
utiliser un tunnel ssh permet d’atteindre des ports qui peuvent être bloqués sur les hôtes distants.

Premier cas

Dans un premier scénario, vous avez réussi à compromettre un serveur http sur le réseau 10.0.22.20/24.
Vous remarquez que cet hôte exécute aussi le service ssh et vous disposez des identifiants de connexion
d’un utilisateur (bob/abc-123). Aussi, vous savez qu’il existe un hôte sur le même réseau à l’adresse
10.0.22.30 qui partage des fichiers au port 445 (protocole SMB), mais vous ne pouvez pas y accéder à
partir de votre PC en raison d’un pare-feu de réseau qui bloque les connexions entrantes au port 445. Le
serveur à 10.0.22.20, étant sur le même réseau, peut y accéder cependant.

Vous créez donc un tunnel ssh entre vous et le serveur ssh compromis; dans ce tunnel, vous faites passer
des messages SMB, contournant ainsi le blocage du port 445. Pour accéder au service sur la cible
(10.0.22.30:445), il s’agit donc d’envoyer des messages vers 127.0.0.1:4455 :

Ici la redirection est locale (l’entrée du tunnel est votre PC); la commande est donc la suivante :

ssh -L 127.0.0.1:4455:10.0.22.30:445 bob@10.0.22.20

Remarque :

Il est possible d’omettre l’adresse IP d’origine lorsque celle-ci est 127.0.0.1 :

ssh -L 4455:10.0.22.30:445 bob@10.0.22.20

Ensuite, à partir de votre PC kali, il sera possible d’envoyer les commandes suivantes pour accéder à la
cible :

nmap -sV -p445 127.0.0.1

smbclient -L 127.0.0.1

Deuxième cas

Dans un autre scénario, on a obtenu un accès sur notre cible, par exemple à l’aide d’un shell inversé; on
sait que le service mysqld (port 3306) s’exécute sur celle-ci mais en raison d’un pare-feu on ne peut y
accéder. Il est possible d’exécuter ssh sur la cible : on doit donc créer à partir de celle-ci un tunnel dont le
point d’entrée sera notre PC kali, et qui redirigera toutes les connexions à 3306 sur kali vers 3306 sur la
cible (ceci requiert que le service sshd s’exécute sur kali) :

Ici, la redirection est distante ; il faut donc lancer la commande suivante à partir de la cible :

ssh -R 10.10.10.44:3306:127.0.0.1:3306 kali@10.10.10.44

Remarques :

1. Pour qu’un serveur ssh puisse être utilisé dans un tunnel (dans une redirection locale ou distante), le
paramètre AllowTcpForwarding doit être à yes dans /etc/ssh/sshd_config

2. Pour qu’un serveur ssh puisse être utilisé dans une redirection distante, le paramètre GatewayPorts
doit être à clientspecified dans /etc/ssh/sshd_config
Attaques sur l’authentification

THC-hydra

Cet outil est un programme qui sert à automatiser les tentatives de connexions sur un grand nombre de
services dans le contexte d’attaques par force brutale ou par dictionnaires. En d’autres termes, il permet
de lancer des tentatives de connexions ftp, ssh, smb, mysql, cisco, pcanywhere, et plusieurs autres
services en utilisant comme logins et mots de passe des listes de mots dans des fichiers, ou encore des
combinaisons de caractères.

Plusieurs options sont disponibles, mais l’utilisation de base est similaire à ce qui suit :

└─$ hydra -L identifiants.txt -P mdp.txt 192.168.229.132 smb

Ici, on utilise une liste d’identifiants de connexion et de mots de passe pour lancer des tentatives de
connexion sur le service smb. Il serait aussi possible de préfixer l’adresse par le nom du protocole si celui-
ci permet de définir une url; la commande suivante est équivalente à celle qui précède :

└─$ hydra -L identifiants.txt -P mdp.txt smb://192.168.229.132

Autres options utiles :

-l/-L Pour spécifier l’identifiant / le fichier contenant les identifiants à tester

Pour spécifier le mot de passe / le fichier contenant les mots de passe à
-p/-P
tester
Pour spécifier un fichier contenant des paires d’identifiants et mots de
-C
passe au format ident:motdepasse
Définit les paramètres pour générer des mots passe. Les valeurs sont
séparées par « : » et ont la signification suivante :
 nombre minimum de caractères
 nombre maximum de caractères
 types de caractères :
-x 4:10:aA1@#$%?!
◦ a = lettres minuscules
◦ A = lettres majuscules
◦ 1 = nombres
◦ les autres caractères sont ajoutés à la liste des caractères à
utiliser
John the Ripper

John the Ripper est un outil qui permet de mener des attaques « par dictionnaire » sur le fichier
/etc/shadow.

Trouver les mots de passe dans le fichier shadow à partir de la liste de mots mdp.txt:

└─$ sudo john --wordlist=mdp.txt shadow

John the Ripper reconnaît assez facilement les différents formats des hachages de mots de passe dans
linux; cependant lorsque ce n’est pas le cas (ou lorsqu’on a affaire à d’autres OS), il faudra spécifier
explicitement un format. Par exemple, pour attaquer un fichier contenant des mots de passe Windows
on lancera la commande suivante :

└─$ sudo john --wordlist=mdp.txt --format=NT hash.txt

Les MDP trouvés sont stockés dans ~john/john.pot, mais on peut voir avec la commande suivante:

└─$ sudo john --show shadow

Règles

John permet d’appliquer des règles de transformation sur les mots dans le fichier de mots de passe afin
d’en générer de nouveaux. Par exemple à partir d’une liste de mots de passe en minuscule, on pourrait
vouloir générer les mêmes mots de passe mais dont la première lettre serait majuscule. On doit donc
définir un ensemble de règles de transformation. Les différents ensembles de règles sont définis dans le
fichier de configuration /etc/john/john.conf. Il en existe déjà plusieurs qui sont distribuées avec Kali; si on
souhaite en ajouter une on doit adopter le format suivant :

[List.Rules:DemoJohn]
:
c

La première ligne spécifie de prendre le mot tel qu’il est dans le fichier; la deuxième ligne transforme le
mot en mettant sa première lettre en majuscule.

Ensuite on peut afficher les résultats:

└─$ john --wordlist=mdp.txt --rules:DemoJohn --stdout

On redirige le tout vers un fichier puis on utilise ensuite ce fichier comme nouvelle liste de mots :

└─$ john --wordlist=mdp.txt --rules:DemoJohn –stdout > mdpCap.txt

└─$ john --wordlist=mdpCap.txt shadow

On pourrait vouloir prendre des mots probables (par exemple les mots de passe de moins de 6
caractères exclusivement alphabétiques) et y ajouter des nombres. Si notre liste de mots de passe se
nomme minirock.txt on créerait donc l’ensemble de règles suivant pour y ajouter (en plus des règles
qu’on a déjà) deux nombres de 0 à 9 à chaque mot de passe:

[List.Rules:DemoJohn]
:
c
$[0-9]$[0-9]

On crée notre nouvelle liste de mots puis on lance la recherche:

└─$ john --wordlist=dictionnaire.txt --stdout --rules:DemoJohn > motplusNombre.txt
└─$ john --wordlist= motplusNombre.txt shadow

Une autre règle qui insère un “!” à la position 0 et ajoute deux chiffres à la fin:

[List.Rules:DemoJohn]
:
c
$[0-9]$[0-9]
i0!$[0-9]$[0-9]

etc.

Élévation de privilèges en linux

Il existe en linux deux moyens d’élever les privilèges d’un utilisateur. Ces moyens ont été conçus pour
être utilisés volontairement, en bonne connaissance de cause (sudo est un exemple); mais des erreurs de
configuration peuvent ouvrir des portes imprévues qui pourront constituer des vulnérabilités
exploitables.

SUID / SGID

Il est possible dans linux de faire en sorte que n’importe quel utilisateur qui exécute un programme
spécifique prenne les privilèges associés à son groupe ou à son propriétaire.

Par exemple, si un fichier n’est accessible en lecture que par les membres du groupe admins :

-rw-r----- 1 root admins 7 Nov 4 18:46 serveur.log

On souhaite tout de même que tout le monde puisse effectuer des recherches dans ce fichier avec grep.
Dans ce cas on donnera la permission SGID au programme grep pour le groupe admins :

└─$ sudo chmod g+s /usr/bin/grep

└─$ sudo chown admins /usr/bin/grep
└─$ ls -l /usr/bin/grep
-rwxr-sr-x 1 root admins 203072 Nov 9 2020 /usr/bin/grep
On remarque que le bit exécutable pour le groupe a la valeur « s ».

Le cas le plus répandu est cependant la permission SUID de root sur un exécutable : c’est un moyen
simple de donner à tous les utilisateurs des privilèges système pour une commande spécifique. La
logique est la même : supposons qu’on souhaite que tous les utilisateurs puissent redémarrer un hôte
avec la commande reboot, on lancera la commande suivante :

└─$ sudo chmod u+s /usr/sbin/reboot

└─$ ls -l /usr/sbin/reboot
-rwsr-xr-x 1 root root 14 Apr 12 2021 /usr/sbin/reboot

Ici le bit exécutable pour le propriétaire (root) a la valeur « s ».

Les vulnérabilités des permissions SGID/SUID viennent du fait que certains programmes ont des
fonctionnalités « cachées » leur permettant eux-mêmes de lancer l’exécution d’autres programmes. Par
exemple, l’éditeur vi permet de lancer des commandes; ainsi s’il dispose des permissions SUID de root,
un utilisateur pourra à travers vi exécuter (sur certains systèmes) n’importe quelle commande en tant
que root.

sudo

L’utilisation de sudo rend généralement les hôtes plus sécuritaires que lorsqu’il est possible de se
connecter comme root. Cependant des oublis ou des mauvaises configurations de sudo (ou des fichiers
visés par sudo) peuvent entraîner des vulnérabilités importantes.

Il est possible en effet de configurer sudo pour que les permissions systèmes ne soient accordées que
pour un programme spécifique à un utilisateur spécifique. Dans ce cas cependant il faut s’assurer que le
programme en question ne peut pas être modifié par l’utilisateur (i.e. que celui-ci n’a pas les droits
d’écriture sur le fichier du programme), car si c’est le cas il aura effectivement le droit de faire exécuter
n’importe quelle commande sur le système.

Pour voir quels sont les droits sudo d’un utilisateur, on se connecte comme cet utilisateur et on lance la
commande suivante :

└─$ sudo -l