Tenemos un sistema de servidor Windows 2003 SP2. Al realizar un análisis de seguridad, hemos descubierto que estamos obteniendo:
Vulnerabilidad admitida de la versión 1 del protocolo SSH
Amenaza: las consecuencias de las vulnerabilidades presentes en la versión 1 de SSH incluyen:
- Compromiso de tráfico protegido por SSH
- acceso de shell raíz al sistema que ejecuta el servidor SSH
¿Qué pasos en el lado de Windows podemos tomar para solucionar este problema?
¿Por qué ejecutas SSH?
Tener un servidor SSH ejecutándose en Windows 2003 que no conoce es altamente sospechoso ... no es un servicio incluido.
El primer paso es averiguar por qué SSH se está ejecutando, ¡y si es que debería estarlo! Un buen lugar para comenzar podría ser ver qué binario está abriendo el puerto con netstat -anb .
Puede que no sea para proporcionar un terminal. Algunos servidores FTP de terceros ofrecen SFTP que se ejecuta a través de SSH.
Endurecimiento de SSH
Siempre que esté ejecutando intencionalmente algún producto de servidor SSH, su objetivo sería fortalecer su configuración al deshabilitar SSH v1 y las suites de cifrado inseguras (piense en MD5 / SHA1, etc.). En última instancia, esto es específico para lo que está ejecutando y casi sería una segunda pregunta sobre ese software de servidor específico.
Pasos que debes seguir: -
Debes instalar la versión actualizada de openssh para Windows
Vulnerabilidad en SSHv1
En el proceso de autenticación SSH-1, el servidor genera un número aleatorio de 256 bits llamado desafío. El desafío se encripta con la clave pública del cliente, de modo que solo el cliente pueda descifrarlo. El cliente recibe el desafío encriptado y lo desencripta. El cliente devuelve la respuesta de desafío: un hash MD5 de la concatentación del desafío y el ID de sesión. El servidor calcula independientemente la respuesta de desafío esperada por la misma fórmula. Si la respuesta de desafío del cliente coincide con lo que el servidor calculó, el servidor responde que el cliente se ha autenticado correctamente.
Lamentablemente, se descubrió una debilidad en la fórmula para calcular una ID de sesión a partir de la clave pública del servidor. Este descubrimiento permite la modificación de la clave de host pública de un servidor sin cambiar el ID de sesión derivado. Además, la clave modificada es a menudo mucho más débil que la original, por lo que es fácil crear una clave privada correspondiente. Este nuevo par de claves se puede utilizar para negociar varias conexiones SSH simultáneas con el mismo ID de sesión.
La debilidad anterior da la posibilidad de MIMT.
más sobre el PROTOCOL DOWNGRADE es también posible si el servidor permite SSH v1, en el cual un atacante puede obligar al cliente a conectarse a V1, degradando las capacidades de la sesión
V1 sí da FORWARD SECRECY, abriendo la posibilidad de un ataque fuera de línea
Lea otras preguntas en las etiquetas ssh