El pasado mes de octubre salió a la luz una nueva debilidad en SSH y las configuraciones por defecto que millones de dispositivos IoT tienen que fue aprovechado por la botnet Mirai. Este fue uno de los vectores que se han utilizado en diferentes ataques DDoS alrededor del mundo y que ha llegado a afectar a empresas tecnológicas tan importantes como Twitter, WhatsApp o Netflix. Hoy en día, se siguen investigando todas las causas del incremento de los ataques en los que se utilizan dispositivos IoT. Una de las vías utilizadas ha sido la debilidad conocida como SSHowDown Proxy.

Figura 1: Fortifica tu SSH para evitar un SSHowDowN Attack!!!

¿Dónde se encuentran los servicios SSH? La respuesta es fácil de entender, en la mayoría de los sistemas conectados a Internet y, es más, en la gran mayoría de los dispositivos IoT. El servicio de SSH nos lo encontramos en televisiones, circuitos de televisión, routers, vídeos, neveras, puntos de acceso y un largo etcétera de dispositivos.

Figura 2: SSHowDownN Proxy

La debilidad de las configuraciones de estos servicios críticos hace que SShowDown Proxy pueda ser utilizado para enviar tráfico a través de dichos dispositivos. El problema radica en los dispositivos y en su configuración por defecto. En como salen de las fábricas y, por supuesto, en la dificultad que tendremos para actualizar firmwares a posteriori. El artículo de hoy no pretende hacer un repaso a SSHowDown, ya que para ello tenemos un artículo interesante de la gente de Akamai, donde se explica en detalle la vulnerabilidad y el riesgo. Aunque a modo de resumen, debemos tener en cuenta:

• Siempre cambiar configuración por defecto del servicio. Por ejemplo, no utilizar contraseñas por defecto, sobretodo en dispositivos conectados a Internet. 

• No permitir el reenvío de tráfico TCP, es decir, directiva del fichero sshd_config AllowTcpForwarding a “No”. 

• Configurar reglas de tráfico entrante en el firewall para prevenir acceso a SSH en dispositivos IoT. Esto se puede considerar. 

• Considerar reglas salientes en el firewall para prevenir la creación de túneles. 

• Deshabilitar el servicio SSH a no ser que sea absolutamente necesario. 

• Autenticación basada en clave pública en entornos críticos. No permitir usuario y contraseña.

En el artículo de hoy, queremos hablar de una herramienta que debe ser una obligatoria de uso en los equipos de pentesting, y sobre todo en las pruebas de la gente de seguridad que podemos encontrar en un equipo de QA. Se debe revisar que las configuraciones, los algoritmos y las implementaciones utilizadas sobre los dispositivos que salen son seguras.

SSH Audit

Hace unos meses hablamos de herramientas que automatizan la auditoría básica sobre un sistema, una serie de verificaciones que permiten ver potenciales fallos de configuraciones o de utilización de software obsoleto. Esta herramienta que podíamos lanzar sobre sistemas GNU/Linux se llamaba Lynis como parte de un proceso completo de fortificación de servidores GNU/Linux, y que permitía hacer ciertas labores de auditoría sobre el sistema.

Figura 3: SSH Audit en GitHub

En esta ocasión, ssh-audit nos permite hacer la auditoría y pasar un listado de buenas prácticas de configuración e implementación sobre un servicio SSH. La herramienta ssh-audit puede encontrarse en su Github. Las verificaciones, que a día de hoy, se encuentran disponibles en la herramienta son:

• Soporte para protocolo 1 y 2 de SSH. Se puede forzar a la herramienta a intentar conectar a través de la versión 1 del protocolo, lo cual no es seguro. 

• Banner Grabbing e identificación de dispositivo y software. Además, de verificar la compresión. 

• Recopilación del intercambio de claves, host-key, evaluación del cifrado y de los algoritmos que se pueden utilizar. 

• Proporciona información sobre la calidad del algoritmo disponible, indicando si se debe eliminar, si no está disponible, si es débil, si no es seguro, etcétera. 

• Proporciona información sobre el listado de CVE relacionados, como el Time-Based Info Leak que permite enumerar usuarios en servidores SSH.

• Analiza las implementaciones más comunes como son OpenSSH, Dropbear SSH y libssh.

Lanzamos la herramienta para que conecte a través del protocolo versión 2 de SSH y podemos ver cómo se empiezan a lanzar diferentes pruebas basadas en lo enunciado anteriormente:

Figura 4: Ejecución de SSH Audit

Los apartados que la herramienta va cubriendo con las diferentes pruebas son:

• Información general sobre la aplicación, dispositivo o sistema operativo. 

• Algoritmos del intercambio de clave. Como puede verse en la imagen anterior, la herramienta comienza a darnos información de que algoritmos debemos mirar con lupa, para ver si deberíamos quitarlos de lo que ofrece nuestro servicio. 

• Algoritmos de Host-Key. Como se puede ver en la imagen, nos indican si estamos utilizando pocos bits.

Figura 5: Análisis de sistemas criptográficos

• Calidad de los algoritmos de cifrado que se pueden utilizar con el SSH. Además, nos indican información tan interesante como a partir de que versión se dejó de utilizar el algoritmo. 

• Recomendaciones sobre los algoritmos que nuestro servicio está ofreciendo. En este caso, la versión de OpenSSH es la 6.6.1 y podemos obtener un listado de cosas a mejorar.

Figura 6: Recomendaciones de seguridad para este SSH

Las opciones de la herramienta permiten configurar el nivel de verbose que podemos lograr, mediante el uso del parámetro -v o –verbose, podemos indicar el nivel de información (info, warn o fail) con el parámetro –level, el puerto en el que se encuentra el servicio, si el servicio se encuentra en IPv4 o IPv6, lo cual es algo interesante para los servicios que están ya en el direccionamiento IPv6. A continuación, os dejamos una imagen dónde podemos ver la ayuda de la herramienta.

Figura 7: Ayuda de la herramienta SSH Audit

Esta herramienta es realmente útil para los equipos de seguridad de las organizaciones, para la gente de IT y los de QA, ya que en estos ámbitos cada uno necesitará monitorizar la seguridad de los servicios SSH antes de que vayan a ser publicados, comprobar la seguridad de terceros o probar los propios desarrollos y dispositivos que se realizan “in house”. Herramienta que debemos tener a mano, ya que nos permitirá auditar un servicio crítico y de actualidad hoy día.

Figura 8: Configuración de Latch para SSH

Por último, recuerda que si eres responsable de un servicio SSH lo suyo es que pongas medidas extras en la protección de los usuarios. Puedes configurar Latch para SSH o Cloud Latch TOTP para SSH tal y como se explican en esos artículos, y si además te gustan las protecciones de portknocking, puedes configurar un sistema basado en Latch para que el puerto de tu servidor SSH no sea tan fácil de localizar.

Autor: Pablo González Pérez (@pablogonzalezpe)
Escritor de los libros "Metasploit para Pentesters", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”