b0ysie7e

Appearance

Linux-Remote-Management-Protocols ​

SSH (Secure Shell) ​

Secure Shell (SSH) permite a dos ordenadores establecer una conexión cifrada y directa dentro de una red posiblemente insegura, en el puerto estándar TCP 22. Esto es necesario para evitar que terceros intercepten el flujo de datos y, por tanto, datos sensibles. El servidor SSH también puede configurarse para permitir conexiones solo desde clientes específicos. Una ventaja de SSH es que el protocolo funciona en todos los sistemas operativos comunes: al ser originalmente una aplicación Unix, está implementado de forma nativa en todas las distribuciones de Linux y en macOS, y también puede usarse en Windows instalando un cliente adecuado. El conocido servidor SSH de OpenBSD (OpenSSH) en distribuciones Linux es una bifurcación de código abierto del servidor SSH original y comercial de SSH Communication Security. En consecuencia, existen dos protocolos que compiten entre sí: SSH-1 y SSH-2 (este último, el estándar actual).

Configuración por defecto ​

c
❯ cat /etc/ssh/sshd_config | grep -v "#" | sed -r '/^\s*$/d'

Include /etc/ssh/sshd_config.d/*.conf
ChallengeResponseAuthentication no
UsePAM yes
X11Forwarding yes
PrintMotd no
AcceptEnv LANG LC_*
Subsystem       sftp    /usr/lib/openssh/sftp-server
  • X11Forwarding yes : permite reenviar aplicaciones gráficas sobre la conexión SSH; en algunos casos puede ampliar la superficie de ataque si se combina con aplicaciones X11 vulnerables.
  • Subsystem sftp : habilita la transferencia de archivos vía SFTP sobre el mismo puerto/servicio.

Footprinting del servicio ​

SSH-Audit ​

Herramienta dedicada a auditar la configuración criptográfica de un servidor SSH: algoritmos de intercambio de claves, cifrados, y claves de host soportadas, marcando cuáles son débiles u obsoletas.

c
❯ git clone https://github.com/jtesta/ssh-audit.git && cd ssh-audit
c
❯ ./ssh-audit.py 172.16.66.10

# general
(gen) banner: SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.3
(gen) software: OpenSSH 8.2p1
(gen) compatibility: OpenSSH 7.4+, Dropbear SSH 2018.76+
(gen) compression: enabled (zlib@openssh.com)                                   

# key exchange algorithms
(kex) curve25519-sha256                     -- [info] available since OpenSSH 7.4, Dropbear SSH 2018.76                            
(kex) curve25519-sha256@libssh.org          -- [info] available since OpenSSH 6.5, Dropbear SSH 2013.62
(kex) ecdh-sha2-nistp256                    -- [fail] using weak elliptic curves
                                            `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(kex) ecdh-sha2-nistp384                    -- [fail] using weak elliptic curves
                                            `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(kex) ecdh-sha2-nistp521                    -- [fail] using weak elliptic curves
                                            `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(kex) diffie-hellman-group-exchange-sha256 (2048-bit) -- [info] available since OpenSSH 4.4
(kex) diffie-hellman-group16-sha512         -- [info] available since OpenSSH 7.3, Dropbear SSH 2016.73
(kex) diffie-hellman-group18-sha512         -- [info] available since OpenSSH 7.3
(kex) diffie-hellman-group14-sha256         -- [info] available since OpenSSH 7.3, Dropbear SSH 2016.73

# host-key algorithms
(key) rsa-sha2-512 (3072-bit)               -- [info] available since OpenSSH 7.2
(key) rsa-sha2-256 (3072-bit)               -- [info] available since OpenSSH 7.2
(key) ssh-rsa (3072-bit)                    -- [fail] using weak hashing algorithm
                                            `- [info] available since OpenSSH 2.5.0, Dropbear SSH 0.28
                                            `- [info] a future deprecation notice has been issued in OpenSSH 8.2: https://www.openssh.com/txt/release-8.2
(key) ecdsa-sha2-nistp256                   -- [fail] using weak elliptic curves
                                            `- [warn] using weak random number generator could reveal the key
                                            `- [info] available since OpenSSH 5.7, Dropbear SSH 2013.62
(key) ssh-ed25519                           -- [info] available since OpenSSH 6.5
...SNIP...
  • El banner (SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.3) ya revela versión exacta del software y hasta la distribución del sistema operativo — punto de partida para buscar CVEs específicos de esa versión.
  • Las líneas marcadas [fail] señalan algoritmos débiles/obsoletos aún habilitados (curvas elípticas débiles, ssh-rsa con hash SHA-1 deprecado) — útil como hallazgo de hardening a reportar, aunque no siempre representan una vía de explotación directa.

Forzar un método de autenticación específico ​

Por defecto, el cliente SSH probará varios métodos en orden (normalmente clave pública antes que contraseña). Se puede forzar cuál usar con -o PreferredAuthentications, útil para saber exactamente qué métodos acepta el servidor:

c
❯ ssh -v jsmith@172.16.66.10

OpenSSH_8.2p1 Ubuntu-4ubuntu0.3, OpenSSL 1.1.1f  31 Mar 2020
debug1: Reading configuration data /etc/ssh/ssh_config 
...SNIP...
debug1: Authentications that can continue: publickey,password,keyboard-interactive

Forzar autenticación por contraseña explícitamente (por ejemplo, si se quiere confirmar que el servidor la acepta antes de intentar un ataque de fuerza bruta, o si el intento automático con clave pública está fallando o generando ruido innecesario):

c
❯ ssh -v jsmith@172.16.66.10 -o PreferredAuthentications=password

OpenSSH_8.2p1 Ubuntu-4ubuntu0.3, OpenSSL 1.1.1f  31 Mar 2020
debug1: Reading configuration data /etc/ssh/ssh_config
...SNIP...
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password

jsmith@172.16.66.10's password:

Fuerza bruta de credenciales ​

c
❯ hydra -L usuarios.txt -P contraseñas.txt ssh://172.16.66.10
  • Al estar SSH cifrado de extremo a extremo, no hay forma de interceptar credenciales pasivamente en la red (a diferencia de FTP/Telnet en texto plano); la fuerza bruta activa contra el servicio es la vía habitual cuando no se dispone de credenciales ni claves privadas.

Rsync ​

Rsync es un protocolo/herramienta para sincronizar archivos y directorios entre sistemas de forma eficiente (solo transfiere las diferencias), muy usado para backups y despliegues. Corre por defecto sobre el puerto TCP 873 cuando se expone como servicio de red (rsyncd), independientemente de SSH.

Escaneo del servicio ​

c
❯ sudo nmap -sV -p 873 172.16.66.11

Starting Nmap 7.92 ( https://nmap.org ) at 2022-09-19 09:31 EDT
Nmap scan report for 172.16.66.11
Host is up (0.0058s latency).

PORT    STATE SERVICE VERSION
873/tcp open  rsync   (protocol version 31)

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 1.13 seconds

Comprobar recursos ("shares") accesibles ​

Un daemon rsync mal configurado puede permitir listar sus módulos disponibles sin autenticación, de forma similar a listar shares de SMB o FTP anónimo:

c
❯ nc -nv 172.16.66.11 873

(UNKNOWN) [172.16.66.11] 873 (rsync) open
@RSYNCD: 31.0
@RSYNCD: 31.0
#list
dev            	Dev Tools
@RSYNCD: EXIT
  • Enviar #list tras el saludo del protocolo devuelve los módulos ("shares") configurados en el daemon, junto con su descripción.

Enumerar el contenido de un recurso abierto ​

c
❯ rsync -av --list-only rsync://172.16.66.11/dev

receiving incremental file list
drwxr-xr-x             48 2022/09/19 09:43:10 .
-rw-r--r--              0 2022/09/19 09:34:50 build.sh
-rw-r--r--              0 2022/09/19 09:36:02 secrets.yaml
drwx------             54 2022/09/19 09:43:10 .ssh
  • --list-only : lista el contenido sin descargar nada, ideal para reconocimiento inicial.
  • Un archivo llamado secrets.yaml accesible en un módulo rsync sin autenticación es exactamente el tipo de hallazgo que justifica investigar más a fondo — a menudo estos archivos contienen credenciales o tokens de API.

Descargar el contenido completo de un módulo una vez confirmado que hay algo de interés:

c
❯ rsync -av rsync://172.16.66.11/dev ./dev_descargado/

Comprobar si el módulo también permite escritura (lo que abriría la puerta a subir archivos maliciosos, por ejemplo una clave SSH pública propia en .ssh/authorized_keys si el directorio es accesible):

c
❯ echo "prueba de escritura" > test.txt
❯ rsync -av test.txt rsync://172.16.66.11/dev/
  • Si la subida tiene éxito, el módulo permite escritura sin autenticación — una configuración de alto riesgo.

R-Services ​

Los R-services (rlogin, rsh, rexec, rcp, rwho, rusers) son un conjunto de utilidades antiguas de Unix para ejecución remota de comandos y transferencia de archivos, predecesoras directas de SSH. Su principal problema — y la razón principal por la que SSH las reemplazó — es el modelo de confianza que usan para la autenticación.

Modelo de confianza: /etc/hosts.equiv y .rhosts ​

Por defecto, los r-services usan PAM (Pluggable Authentication Modules) para autenticar usuarios, pero también permiten evitar por completo esa autenticación mediante los archivos /etc/hosts.equiv (a nivel de sistema) y .rhosts (a nivel de usuario, en su directorio home). Estos archivos contienen una lista de hosts (IPs o hostnames) y usuarios en los que el sistema local confía automáticamente al recibir una conexión por r-commands, sin pedir contraseña.

c
❯ cat /etc/hosts.equiv

# <hostname> <local username>
workstation01 jsmith
  • Esta línea le dice al sistema: "confía sin pedir contraseña en el usuario jsmith si se conecta desde el host workstation01".

Ejemplo de archivo .rhosts ​

c
❯ cat .rhosts

svcuser     172.16.66.20
+           172.16.66.30
+           +
  • Primera línea: confía en el usuario svcuser conectándose específicamente desde 172.16.66.20.
  • Segunda línea: el + como usuario significa "confiar en cualquier usuario" que se conecte desde 172.16.66.30.
  • Tercera línea (+ +): la configuración más peligrosa posible — confía en cualquier usuario desde cualquier host, sin restricción alguna. Si se encuentra esto en un sistema real, es un hallazgo crítico.

Escaneo de R-Services ​

c
❯ sudo nmap -sV -p 512,513,514 172.16.66.20

Starting Nmap 7.80 ( https://nmap.org ) at 2022-12-02 15:02 EST
Nmap scan report for 172.16.66.20
Host is up (0.11s latency).

PORT    STATE SERVICE    VERSION
512/tcp open  exec?
513/tcp open  login?
514/tcp open  tcpwrapped

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 145.54 seconds
  • Puerto 512 : rexec (ejecución remota de comandos).
  • Puerto 513 : rlogin (inicio de sesión remota).
  • Puerto 514 : rsh/shell (comúnmente mostrado como tcpwrapped por Nmap, ya que suele estar protegido por TCP Wrappers).

Iniciar sesión con Rlogin ​

Si el host/usuario desde el que nos conectamos está en la lista de confianza (.rhosts o hosts.equiv) del sistema objetivo, rlogin inicia sesión sin pedir contraseña:

c
❯ rlogin 172.16.66.20 -l svcuser

Last login: Fri Dec  2 16:11:21 from localhost

[svcuser@localhost ~]$
  • -l : especifica el usuario remoto con el que iniciar sesión.
  • Este es precisamente el riesgo del modelo de confianza: si un atacante logra spoofear la IP de un host confiable (o simplemente pivotar desde uno legítimo ya comprometido), obtiene acceso directo sin necesidad de ninguna credencial.

Listar usuarios autenticados con Rwho ​

Muestra qué usuarios tienen sesión iniciada en hosts de la red local que también corren el servicio rwhod:

c
❯ rwho

root       web01:pts/0 Dec  2 21:34
svcuser    workstn01:tty1  Dec  2 19:57  2:25

Listar usuarios autenticados con Rusers ​

Similar a rwho, pero dirigido a un host específico:

c
❯ rusers -al 172.16.66.30

svcuser    172.16.66.30:console          Dec 2 19:57     2:25
  • -a : muestra todos los usuarios, incluso los inactivos.
  • -l : formato de salida detallado (long).

Nota sobre el riesgo de los R-services ​

Más allá de la configuración de hosts.equiv/.rhosts, los r-services transmiten todo en texto plano, incluidas las contraseñas cuando sí se usan (por ejemplo con rexec). Esto los hace vulnerables a sniffing pasivo en la red además del problema de confianza por IP/hostname (que de por sí es endeble, ya que el spoofing de IP de origen es una técnica antigua y bien documentada). Por estas razones, encontrar r-services activos en un objetivo moderno suele ser en sí mismo un hallazgo de seguridad relevante, independientemente de si se logra explotar el modelo de confianza.