El CEO de Binance, Changpeng Zhao (CZ), ha dado la voz de alarma sobre un antiguo error de autenticación de OpenSSH que podría permitir a atacantes iniciar sesión en algunos servidores sin conocer la contraseña, y que ha permanecido oculto en los sistemas durante casi una década. Qué ocurrió: el 5 de noviembre, OpenSSH y Alpine Linux publicaron correcciones para una vulnerabilidad que permite eludir la autenticación y que, según los investigadores, se remonta a cambios realizados entre 2012 y 2016. CZ amplificó la advertencia en X al día siguiente e instó a los administradores a instalar los parches de inmediato. No dijo que Binance se hubiera visto afectada; los avisos no informaron de pruebas de que se hubiera producido una vulneración. Cómo funciona el error (versión breve): la falla afecta a OpenSSH en sistemas que usan musl libc (en particular, muchas compilaciones de Alpine Linux) cuando: - No se usa PAM para comprobar las contraseñas, - La autenticación mediante contraseña sigue habilitada y - Existen ciertas configuraciones de cuentas. - Un atacante puede eludir la autenticación enviando una única contraseña de tamaño excesivo (entre 257 y 1.024 bytes). Si el campo de contraseña almacenado de la cuenta objetivo contiene un asterisco (*) —que significa «sin contraseña» en la función de hash de musl— y otra cuenta local tiene un hash SHA-256 o SHA-512 compatible, el servidor podría aceptar erróneamente la contraseña de tamaño excesivo y conceder acceso. - Esto puede permitir el acceso a cuentas que los administradores creían configuradas para permitir únicamente inicios de sesión con claves SSH. Quiénes se ven afectados: - Potencialmente vulnerables: sistemas Alpine Linux que ejecutan OpenSSH sin PAM y con la autenticación mediante contraseña habilitada; algunas imágenes de Alpine para la nube o «tiny-cloud» cuando posteriormente se crean condiciones específicas. - No afectados: sistemas que usan PAM para verificar contraseñas, servidores con la autenticación mediante contraseña deshabilitada y contenedores sin un servidor SSH activo. - El problema también puede afectar a otras distribuciones de Linux que usan musl libc (algunas configuraciones de OpenWrt, Buildroot y Yocto). El SSH Dropbear predeterminado de OpenWrt no se ve afectado por este error. Descubrimiento y antecedentes técnicos: - El investigador de seguridad Özgün Kültekin (Wakefield) descubrió la falla y la bautizó «*sshole». La atribuyó al comportamiento de musl al generar hashes de contraseñas: musl devuelve un asterisco cuando una contraseña supera su límite de procesamiento de 256 bytes. Un cambio en OpenSSH de julio de 2016 (destinado a solucionar filtraciones que permitían descubrir nombres de usuario) puede hacer que sshd tome prestado el salt de otra cuenta al validar una cuenta que no tiene un hash válido. En conjunto, estos comportamientos permiten que un asterisco devuelto coincida con un asterisco almacenado y que la autenticación se complete correctamente. - El equipo de OpenSSH reconoció la vulnerabilidad, pero afirmó que la causa raíz está fuera de sshd; su versión del 5 de noviembre (OpenSSH 10.6p2) implementa una solución alternativa para bloquear el error de autenticación. Por qué es importante para los operadores de criptomonedas: muchas imágenes ligeras para la nube y opciones de infraestructura del sector de las criptomonedas usan Alpine Linux o compilaciones basadas en musl. El aviso de Alpine menciona las imágenes tiny-cloud de las versiones 3.18.11 a 3.24.3: su cuenta alpine predeterminada puede ejecutar doas sin contraseña y, si posteriormente se dan las condiciones para explotar la vulnerabilidad, un inicio de sesión exitoso podría elevar los privilegios a root. Aunque los inicios de sesión de root estén bloqueados de forma predeterminada, una cuenta administrativa vulnerada aún puede usarse para obtener privilegios elevados, lo que supone un riesgo grave para operadores de nodos, billeteras, validadores y servicios de custodia. Qué hacer ahora: - Actualizar: instala OpenSSH 10.6p2 o los paquetes corregidos de Alpine Linux (Alpine afirma que dispone de correcciones hasta la versión 3.16). Ten en cuenta que no basta con instalar las actualizaciones de los paquetes: debes reiniciar el proceso sshd después de actualizar. - Si no puedes actualizar de inmediato: como medida provisional, deshabilita la autenticación mediante contraseña estableciendo PasswordAuthentication no en sshd_config y reinicia sshd después de confirmar que el acceso mediante clave SSH funciona. - Revisar los registros: comprueba los registros de autenticación SSH para detectar inicios de sesión inesperados mediante contraseña en cuentas que no deberían aceptarlas. - Si no puedes descartar un acceso no autorizado, considera que la máquina está comprometida y sigue tus procedimientos de respuesta a incidentes. Parches y versiones: - OpenSSH publicó la versión 10.6p2 el 5 de noviembre. - Alpine identificó versiones de paquetes corregidas (entre ellas, 3.21.10, 3.22.8, 3.23.8 y 3.24.4) y afirmó que hay parches disponibles para las versiones actuales y las ramas anteriores hasta la 3.16. Contexto: la publicación de CZ es la más reciente de una serie de advertencias de seguridad que ha señalado públicamente (recientemente denunció un sitio falso de Trust Wallet utilizado para suplantar a usuarios). Dado el potencial de movimiento lateral desde una sola cuenta comprometida, los operadores de infraestructura de criptomonedas deberían dar prioridad a estas correcciones. En resumen: si ejecutas Alpine o cualquier sistema basado en musl con OpenSSH y la autenticación mediante contraseña habilitada, instala el parche y reinicia sshd ahora; o, como mínimo, deshabilita la autenticación mediante contraseña hasta que puedas aplicar la corrección y verificar tus sistemas. Lee más noticias generadas por IA en: https://app.chaingpt.org/news
