Una vulnerabilidad en el paquete GNU InetUtils afectó todas las versiones desde 1.9.3 hasta 2.7 inclusive.
Aparentemente, telnet ha quedado en el pasado junto con los módems y la conexión dial-up, pero de repente se ha convertido en la fuente de una seria vulnerabilidad. Se descubrió un bug en GNU InetUtils que permite acceder remotamente al sistema como root sin contraseña, simplemente enviando un valor de variable de entorno especialmente formado.
El problema afecta al servidor telnetd que forma parte de GNU InetUtils. Este transmite al programa login el valor de la variable USER recibido del cliente, sin ninguna verificación. Esto puede ser explotado si el cliente envía la cadena «-f root» como USER y se conecta con el parámetro telnet -a o –login. Como resultado, login interpreta esto como una bandera de servicio, omite el procedimiento estándar de autenticación y autoriza automáticamente al usuario como root.
La vulnerabilidad ha recibido el identificador CVE-2026-24061 y una calificación CVSS de 9.8. Todas las versiones de GNU InetUtils, desde 1.9.3 hasta 2.7 inclusive, están en riesgo. El bug ha estado presente en el proyecto durante casi 11 años, desde mayo de 2015, pero solo se ha identificado ahora. En esencia, este es un clásico ejemplo de una vulnerabilidad de la vieja escuela, donde una cadena peligrosa sin filtrar se pasa a una utilidad del sistema con privilegios de root.
Los autores del advisory recomiendan encarecidamente no usar telnetd, restringir el acceso al puerto telnet solo a clientes de confianza y aplicar un parche o actualizar a una versión donde se haya solucionado el problema lo antes posible. Una solución temporal podría ser deshabilitar completamente telnetd o utilizar una versión personalizada de login que no acepte el parámetro «-f».
La vulnerabilidad fue descubierta por el investigador Carlos Cortés Álvarez, y el parche fue preparado y revisado por los desarrolladores de GNU InetUtils en enero de 2026. Las correcciones incluyen la sanitización de todas las variables que se utilizan al formar el comando de llamada a login, para que tales ataques sean imposibles en principio.
La historia parece casi simbólica: un protocolo obsoleto, un servicio olvidado y un clásico error lógico llevaron a una completa violación del sistema. Otro recordatorio de que incluso las tecnologías 'antiguas' pueden seguir siendo una amenaza real si aún están funcionando en producción.
Justo después de la publicación de información sobre la vulnerabilidad, el equipo de investigadores desplegó sensores honeypot para rastrear los verdaderos intentos de explotación. Los atacantes no tardaron en aparecer. En 18 horas de observaciones se registraron 60 intentos de hackeo desde 18 únicos. direcciones IP. Según la plataforma Censys, alrededor de tres mil sistemas en todo el mundo resultaron ser potencialmente vulnerables, aunque una parte significativa de ellos probablemente también son trampas honeypot.
El análisis del tráfico interceptado mostró una imagen bastante colorida. El atacante más activo fue el que tenía la dirección 178.16.53.82, quien realizó 12 sesiones contra 10 objetivos diferentes. Sus acciones estaban completamente automatizadas: tras obtener acceso, se ejecutaba un conjunto estándar de comandos de exploración como uname -a, id, lectura de /proc/cpuinfo y /etc/passwd. Una característica notable fue el envoltorio de la salida de los comandos con marcadores especiales para su posterior análisis, lo que claramente indica un botnet o un sistema automatizado de recopilación de datos.
Un delincuente más sofisticado fue el que tenía la dirección 216.106.186.24. Se concentró en una subred específica e intentó establecer una clave SSH para acceso permanente, así como cargar y ejecutar un script de Python desde un servidor externo —presumiblemente, malware para criptominado o un botnet. Sin embargo, ambos intentos fracasaron: en el sistema objetivo no existía el directorio .ssh y también faltaban curl y python.
Un interés particular son dos atacantes con direcciones 167.172.111.135 y 165.22.30.48. A diferencia de los demás, no intentaron obtener acceso root de inmediato, sino que experimentaron con las cuentas nobody, daemon e incluso con una inexistente nonexistent123. Las demoras entre sesiones y la lógica de sus acciones indican que hay una persona real detrás del teclado. Probablemente, sean hackers más experimentados que conocen los sistemas de detección de intrusiones y tienen técnicas para elevar privilegios.
Algunos atacantes demostraron una sorprendente negligencia en la seguridad operativa. Por ejemplo, un delincuente con la dirección 67.220.95.16 utilizó la misma IP tanto para explotar como para alojar un servidor con malware. Otros revelaron accidentalmente los nombres de sus hosts a través de la variable DISPLAY: uno trabajaba desde un sistema llamado MiniBear, otro desde una máquina virtual shared-vm2.localdomain, y un tercero se conectaba directamente desde un entorno gráfico completo de Kali Linux.
En general, el nivel de los atacantes fue bastante bajo. De 18 fuentes de ataques, solo unas pocas mostraron signos de profesionalismo. La mayoría utilizó herramientas automatizadas muy simples o simplemente pulsaron las teclas siguiendo instrucciones de internet. El sistema de detección de intrusiones Suricata capturó con éxito el momento en que uno de los atacantes obtuvo acceso root, lo que reafirma la importancia de una protección y monitoreo de tráfico de red en múltiples niveles.
Los investigadores señalan que esta vulnerabilidad, por un lado, permitió a los hackers aficionados practicarse, y por otro, facilitó a los especialistas en seguridad recopilar datos valiosos sobre las tácticas y herramientas actuales de los delincuentes.
Más detalles: https://www.securitylab.ru/news/568478.php
Fuente: linux.org.ru
