Kali Linux y SSH-1: Seguridad
Kali Linux y SSH-1: Seguridad
Entiendo que estás buscando información sobre el soporte de SSH-1 (la versión antigua y vulnerable del protocolo SSH) en Kali Linux.
Es importante aclarar que, por defecto, las versiones modernas de Kali Linux (y de OpenSSH en general) tienen deshabilitado o incluso eliminado el soporte para SSH-1 porque es extremadamente inseguro y susceptible a ataques de interceptación.
Aquí tienes los detalles técnicos de por qué sucede esto y cómo se gestiona en un entorno de auditoría:
1. ¿Por qué no se usa SSH-1?
A diferencia de SSH-2, la versión 1 tiene fallos de diseño críticos:
Vulnerabilidad a MITM: Es vulnerable a ataques de "Man-in-the-Middle" (hombre en el medio).
Debilidad en la integridad: No utiliza códigos de autenticación de mensajes (MAC) fuertes, lo que permite la inserción de datos.
Cifrado obsoleto: Utiliza algoritmos que hoy en día se consideran fáciles de romper.
2. Situación en Kali Linux
Si intentas conectarte a un dispositivo muy antiguo que solo soporta SSH-1 desde una terminal de Kali, probablemente verás un error similar a:
Protocol major versions differ: 1 vs. 2
Desde la versión OpenSSH 7.0, el soporte para la versión 1 se deshabilitó en el momento de la compilación o se requiere una configuración muy específica para activarlo.
3. Cómo forzar la conexión (Si es estrictamente necesario)
Si estás realizando una auditoría de seguridad (Pentesting) sobre un hardware antiguo (como un router de hace 15 años) y necesitas entrar, puedes intentar lo siguiente:
Usar el parámetro de protocolo:
Bashssh -1 usuario@ip-objetivoNota: Si el binario de tu versión de Kali no fue compilado con soporte para SSH-1, este comando fallará.
Modificar el archivo de configuración:
Debes editar
/etc/ssh/ssh_config(cliente) o crear un archivo temporal de configuración y añadir:PlaintextProtocol 2,1
Herramientas alternativas en Kali
Dado que SSH-1 es una vulnerabilidad en sí misma, en Kali solemos usar herramientas para detectar y explotar este protocolo en lugar de simplemente "conectarnos":
Nmap: Para detectar si un servidor permite SSH-1.
Bashnmap -sV --script sshv1 <ip>Metasploit: Existen módulos para verificar la versión del protocolo y posibles debilidades.
[!WARNING]
Advertencia de Seguridad: Nunca habilites SSH-1 en un servidor de producción. Si encuentras un servidor que lo usa durante una auditoría, debe reportarse como una vulnerabilidad crítica.
Si estás en medio de un ejercicio de pentesting o auditoría, identificar servicios que aún corren SSH-1 es como encontrar una puerta abierta con una cerradura de juguete.
Aquí tienes cómo puedes usar Kali Linux para detectar, analizar y entender por qué este protocolo es un riesgo, incluyendo el flujo de una conexión SSH.
1. Escaneo de Red con Nmap
Para identificar rápidamente qué máquinas en tu red todavía aceptan la versión 1.5 o 1.99 (que permite degradar a SSH-1), utiliza este comando:
nmap -p 22 --script sshv1 <IP_O_RANGO>
Interpretación: Si el script devuelve
SSHv1 supported, el objetivo es vulnerable a ataques de degradación (downgrade attacks) y de interceptación de tráfico.
2. Entendiendo la diferencia: SSH-1 vs SSH-2
La razón por la que Kali y el resto del mundo intentan enterrar SSH-1 es su arquitectura de intercambio de claves. En SSH-1, el servidor tiene una "clave de servidor" que cambia cada hora, pero el proceso de cifrado de la clave de sesión es débil y carece de una verificación de integridad robusta.
| Característica | SSH-1 | SSH-2 |
| Integridad | CRC-32 (Vulnerable a inserción) | HMAC (Seguro) |
| Intercambio de claves | Un solo método (Riesgoso) | Múltiples métodos (Diffie-Hellman) |
| Seguridad MITM | Muy baja | Alta (con verificación de host) |
| Cifrado | DES, 3DES, RC4 | AES, ChaCha20, etc. |
3. Uso de Metasploit para Auditoría
Si ya confirmaste que el puerto está abierto, puedes usar Metasploit para obtener más detalles técnicos del banner y la configuración:
Inicia la consola:
msfconsoleBusca el módulo:
use auxiliary/scanner/ssh/ssh_versionConfigura el objetivo:
set RHOSTS <IP>Ejecuta:
run
¿Qué hacer si encuentras SSH-1?
Si eres el administrador, la solución no es "parchear", es deshabilitar.
En el archivo /etc/ssh/sshd_config del servidor, asegúrate de que la línea de protocolo especifique solo la versión 2:
# Forzar solo SSH-2
Protocol 2
Para realizar una demostración de Man-in-the-Middle (MITM) en un entorno controlado (como un laboratorio con máquinas virtuales), aprovechamos que SSH-1 no tiene una verificación de integridad de mensajes (MAC) fuerte y es vulnerable a la inserción de datos y al secuestro de sesión.
En Kali Linux, la herramienta clásica para esto es Ettercap.
Paso 1: Configurar el Escenario
Necesitas tres actores en la misma red local:
Atacante: Tu máquina Kali Linux.
Víctima (Cliente): Una máquina intentando conectar por SSH.
Servidor (Legacy): Un equipo antiguo que acepte SSH-1.
Paso 2: Ejecutar el ataque con Ettercap (Gráfico)
Ettercap tiene un "filtro" específico para degradar o interceptar SSH-1.
Abre Ettercap:
sudo ettercap -GSelecciona tu interfaz de red (ej.
eth0owlan0).Escanea los hosts de la red y añade la Víctima como Target 1 y el Servidor como Target 2.
Ve al menú ARP Poisoning y selecciona "Sniff remote connections".
Carga el Plugin: Ve a Plugins -> Manage Plugins y busca uno llamado
ssh_helper. Este plugin intenta interceptar los datos de la sesión SSH-1.
Paso 3: ¿Qué sucede técnicamente?
Cuando el protocolo es SSH-1, el atacante puede interceptar el intercambio de la "clave de sesión". A diferencia de SSH-2, que usa Diffie-Hellman para que ambas partes acuerden una clave sin enviarla nunca por la red, SSH-1 envía la clave de sesión cifrada con la clave pública del servidor.
Si el atacante intercepta esa clave pública y la sustituye por la suya (falsificación de identidad), puede:
Descifrar el tráfico en tiempo real.
Ver las contraseñas en texto plano cuando el usuario se loguea.
Modificar los comandos que el usuario envía al servidor.
Diferencia Visual del Flujo
Es vital entender por qué SSH-2 detiene esto y SSH-1 no:
En SSH-1: El cliente confía ciegamente en la primera clave que recibe si no tiene el "fingerprint" guardado.
En SSH-2: El intercambio de llaves es "perfect forward secrecy", lo que significa que incluso si robas la clave del servidor después, no puedes descifrar sesiones pasadas.
Resumen de Seguridad
Si en tu escaneo con Nmap (--script sshv1) viste que el puerto 22 está abierto con SSH-1, no necesitas herramientas complejas: cualquier interceptor de paquetes básico podrá leer la comunicación.
Aquí tienes una propuesta de informe técnico profesional que podrías presentar tras una auditoría. Está diseñado para ser claro, directo y con el peso suficiente para que un administrador de sistemas entienda la urgencia del cambio.
Informe de Hallazgo de Seguridad: Uso de Protocolo Obsoleto (SSH-1)
1. Resumen Ejecutivo
Durante la fase de análisis de servicios, se ha detectado que el servidor [Insertar IP/Nombre del Host] permite conexiones mediante el protocolo SSH versión 1 (SSH-1). Este protocolo se considera inseguro y ha sido reemplazado por SSH-2 hace más de una década debido a fallos críticos en su diseño.
2. Detalles Técnicos
El protocolo SSH-1 presenta debilidades estructurales que no pueden ser corregidas mediante parches de software:
Vulnerabilidad a la Inserción de Datos: Utiliza el algoritmo CRC-32 para la integridad de los mensajes, el cual carece de propiedades criptográficas fuertes. Un atacante puede manipular los paquetes en tránsito sin que el cliente o el servidor lo detecten.
Falta de Secreto Hacia Adelante (Forward Secrecy): Si la clave del servidor es comprometida en el futuro, todas las sesiones capturadas anteriormente pueden ser descifradas.
Ataques de Interceptación (MITM): El intercambio de claves en SSH-1 facilita que un atacante se posicione entre el cliente y el servidor para capturar credenciales en texto plano.
3. Prueba de Concepto (PoC)
Utilizando herramientas de auditoría estándar en Kali Linux, se confirmó la exposición:
Detección:
nmap -sV --script sshv1 [IP]confirmó que el banner responde conProtocol 1.99oProtocol 1.5.Simulación: Se logró capturar el flujo de datos mediante un ataque de envenenamiento ARP (ARP Poisoning), demostrando que la confidencialidad de la sesión es nula bajo este protocolo.
4. Impacto en el Negocio
Riesgo de Intrusión: Robo de credenciales administrativas (root).
Incumplimiento Normativo: Viola estándares de seguridad como PCI-DSS, ISO 27001 y GDPR, que exigen el uso de cifrado fuerte y actualizado.
Pérdida de Integridad: Posibilidad de ejecución de comandos no autorizados mediante la inyección de tráfico.
5. Recomendaciones (Remediación)
Deshabilitar SSH-1: Editar el archivo de configuración del servidor SSH (
/etc/ssh/sshd_config) y asegurar que solo se permita la versión 2:PlaintextProtocol 2Actualizar el Software: Asegurarse de que el paquete
openssh-serveresté en su versión más reciente.Auditoría de Claves: Generar nuevas llaves de host (RSA/Ed25519) una vez desactivado el soporte para la versión 1.