La nueva vulnerabilidad grave del momento se llama CVE-2018-10933. Se trata de una vulnerabilidad crítica en una librería de código abierto llamada libssh.
El problema es más que grave, es aterrador, ya que en teoría permite a un atacante conectarse a un servidor protegido con libssh sin tener que introducir ninguna contraseña.
Es aterrador porque SSH es probablemente el protocolo de acceso remoto más utilizado en todo el mundo.
Casi todos los servidores Unix y Linux emplean SSH para la administración remota y hay un montón de enormes granjas de servidores por lo que SSH está implementado en infinidad de lugares.
SSH significa secure shell, donde el termino shell, en el mundo Unix, se refiere al símbolo de sistema, el lugar donde la mayoría de la funciones de administración de sistemas en Unix tienen lugar, ya sean realizadas manualmente por un humano o automáticamente por un script.
Pero SSH se usa para muchas más cosas, a menudo se entiende como un túnel seguro para realizar conexiones cifradas entre dos dispositivos a través de Internet.
Otros usos habituales de SSH incluyen la transferencia de archivos entre servidores y la sincronización segura de datos entre centros de datos.
Por lo tanto los fallos en SSH son una pesadilla para la mayoría de los administradores de sistemas, y este seguro dará que hablar.
Las buenas noticias
La buena noticia es que la versión más utilizada de SSH es un producto de código abierto llamado OpenSSH, creada y gestionada por los competentes expertos de OpenBSD.
OpenSSh es una implementación completamente distinta a libssh, que ni incluye ni depende del mismo software.
Otras conocidas implementaciones de código abierto de SSH incluyen Dropbear (una versión mínima utilizada en muchos routers y dispositivos IoT), libssh2 (que es un producto totalmente distinto a libssh, no simplemente una versión de este) y PuTTY (utilizada habitualmente en Windows).
Ninguno de estos productos se ve afectado por este problema, por lo que mayoría de nosotros no tendremos que ponernos en alerta roja.
El único gran proyecto que sepamos que usa libssh como su servidor SSH, es el repositorio de código GitHub de Microsoft.
Y la buena noticia es que GitHub por un lado no se ve afectado por el problema en libssh y por otro lado ya ha implementado el parche, por lo que todo el mundo está a salvo.
Otra herramienta que también soporta libssh es cURL, una herramienta de transferencia de datos que se incluye en todos los Mac y en casi todas las distribuciones de Linux, además de ser muy utilizada en las cargas y descargas de dispositivos IoT.
Pero cURL no incluye libssh por defecto, si no que emplea libssh2 como primera opción si se necesita soporte SSH.
Las malas noticias
Las malas noticias es que cualquier conexión entrante SSH que utilice libssh tiene un gran riesgo de accesos no autorizados.
El bug es muy simple:
Cuando te conectas, el cliente pide al servidor que comience el proceso de autenticación, tras lo cual el servidor y el cliente intercambian contraseñas cifradas, y termina con el servidor aceptando la identidad del cliente, con lo que pueden comenzar a intercambiar datos.
Pero el bug consiste en que el cliente simplemente le dice al servidor que ha pasado todos los controles y el servidor se lo cree sin comprobar nada, pese a que lo normal es que fuese al revés, que el servidor otorgue los permisos. No se requiere ninguna contraseña.
¿Qué hacer?
- Si tiene un producto que incluya libssh, descarga e instala la última versión de libssh inmediatamente.
- Si utilizas un producto que lleve libssh incorporado necesitaras actualizar también ese producto.
- Si no estás seguro, consulta la documentación del producto y la comunidad online.
Para manteneros al día de las últimas amenazas haceros fans de nuestra página de Facebook o síguenos en Twitter para intercambiar experiencias en torno al mundo de la seguridad. Si deseas recibir nuestro boletín de seguridad en tu correo electrónico, suscríbete en la siguiente aplicación: