Solucionan una vulnerabilidad crítica en OpenSSH

Durante el último año hemos visto cómo se han publicado y solucionado varias vulnerabilidades con bastante antigüedad en sistemas GNU/Linux. Si echamos la vista atrás, recordaremos la vulnerabilidad Ghost en la librería glibc o la que afectaba al sistema de arranque Grub.

Sin embargo, cuando los usuarios son conscientes de estas vulnerabilidades ya suele existir un parche que la soluciona o este está a punto de publicarse, limitando los ataques que se pueden realizar, siempre y cuando se apliquen las debidas actualizaciones.

¿Qué es OpenSSH?

Por si hay alguien que no lo conozca, OpenSSH es una de las principales herramientas para conectarse remotamente usando el protocolo SSH. Se encarga de cifrar todo el tráfico y así evitar que se puedan interceptar las comunicaciones y realizar cierto tipo de ataques. Además, OpenSSH proporciona capacidades de crear túneles de comunicación seguros, varios métodos de autenticación y unas opciones de configuración avanzadas.

Su uso está muy extendido entre usuarios de múltiples sistemas operativos, ya que por diseño es incluso más seguro que el protocolo SSH original. Esto es posible gracias a que sus desarrolladores procuran crear código limpio y que pueda ser auditado sin muchos problemas, algo que contribuye a su seguridad permitiendo descubrir fallos como el que hoy analizamos.

¿En qué consiste esta vulnerabilidad?

Los investigadores de Qualys descubrieron esta vulnerabilidad (que en realidad son dos, identificadas con los códigos CVE-2016-0777 y CVE-2016-0778) en una característica presente en las versiones experimentales de OpenSSH que van desde la versión 5.4 a la 7.1. La característica de roaming que permite contactar de nuevo con el servidor SSH en caso de que se produzca una interrupción de la conexión es la responsable de este fallo de seguridad.

Un atacante podría engañar a los usuarios de OpenSSH de las versiones vulnerables para que se conectasen a un servidor malicioso y poder obtener así sus claves SSH cuando se inicie la sesión. Es importante destacar que esta vulnerabilidad tan solo puede ser explotada cuando se ha realizado una autenticación correcta, por lo que se requiere utilizar un servidor SSH malicioso o que haya sido comprometido por un atacante.

¿Qué sistemas están afectados?

Como ya hemos indicado, el fallo está presente en las versiones que van desde la 5.4 a la 7.1 del cliente OpenSSH usado por los usuarios, sin que la versión utilizada en servidores se vea afectada.

Los sistemas afectados serían aquellos que usen clientes OpenSSH en Linux, FreeBSD y Mac OS X, así como también aquellos usuarios de Windows que utilicen clientes que no sean PuTTY (uno de los más extendidos y que, curiosamente, no se ve afectado funcionando en Windows).

De momento, desde OpenSSH no tienen constancia de que existan ataques que hayan aprovechado esta vulnerabilidad, aunque existe la posibilidad de que haya sido utilizada por atacantes debido a que el fallo ha estado presente durante varios años. Los investigadores de Qualys han publicado una prueba de concepto para demostrar la explotación de esta vulnerabilidad.

¿Cómo solucionar esta vulnerabilidad?

Los responsables de OpenSSH han puesto a disposición de todos aquellos usuarios de las versiones vulnerables un parche de seguridad en la versión 7.1p2, apenas tres días después de conocerse la vulnerabilidad por primera vez. Algunas de las distribuciones de Linux y BSD más conocidas como puedan ser Ubuntu, RedHat, Debian, FreeBSD y OpenBSD ya han lanzado actualizaciones que corrigen esta vulnerabilidad, por lo que se recomienda encarecidamente actualizar nuestro sistema.

Asimismo, también podemos desactivar manualmente la característica roaming causante del problema ejecutando el siguiente comando para añadir una línea de código a la configuración de SSH.

FreeBSD y Linux

echo ‘UseRoaming no’ | sudo tee -a /etc/ssh/ssh_config

Mac OS X

echo «UseRoaming no» >> ~/.ssh/config

Una vez se haya ejecutado este comando, deben reiniciarse todas aquellas sesiones de SSH que estén abiertas para que el cambio sea aplicado.

Conclusión

Tal y como acabamos de ver, el uso de protocolos supuestamente seguros debe ser auditado periódicamente para descubrir fallos como este. Solamente gracias a este tipo de revisión de código es posible descubrir fallos que pueden haber pasado desapercibidos incluso durante años, permitiendo su solución y evitando que los delincuentes puedan utilizarlos en su beneficio.

Josep Albors