Uma vulnerabilidade no pacote GNU InetUtils afetou todas as versões de 1.9.3 a 2.7 incluídas.
À primeira vista, o telnet parece ter sido superado por modem e discagem, mas ele repentinamente se tornou a fonte de uma séria vulnerabilidade. Foi descoberto um bug no GNU InetUtils que permite o acesso remoto ao sistema como root sem senha, simplesmente enviando um valor de variável de ambiente especialmente formado.
O problema afeta o servidor telnetd, que faz parte do GNU InetUtils. Ele transmite para o programa login o valor da variável USER recebido do cliente, sem qualquer verificação. Isso pode ser explorado se o cliente enviar a string "-f root" como USER e se conectar com o parâmetro telnet -a ou –login. Como resultado, o login interpreta isso como um sinalizador especial, ignorando o procedimento padrão de autenticação e autorizando automaticamente o usuário como root.
A vulnerabilidade recebeu o identificador CVE-2026-24061 e uma pontuação de CVSS: 9.8. Todas as versões do GNU InetUtils, desde 1.9.3 até 2.7 incluídas, estão em risco. O bug está presente no projeto há quase 11 anos, desde maio de 2015, mas foi identificado apenas agora. Essencialmente, é um exemplo clássico de vulnerabilidade antiga, onde uma string perigosa é passada para uma utilidade do sistema com privilégios de root sem filtragem.
Os autores do aviso recomendam expressamente não usar o telnetd, restringir o acesso à porta telnet apenas a clientes confiáveis e instalar a correção o mais rápido possível ou atualizar para uma versão que resolva o problema. Uma solução temporária pode ser desativar completamente o telnetd ou usar uma versão personalizada do login que não suporte o parâmetro "-f".
A vulnerabilidade foi descoberta pelo pesquisador Carlos Cortes Alvarez, e o patch foi preparado e aprimorado pelos desenvolvedores do GNU InetUtils em janeiro de 2026. As correções incluem a sanitização de todas as variáveis usadas na formação do comando de chamada do login, de modo a tornar tais ataques inviáveis em princípio.
A história parece quase simbólica: um protocolo obsoleto, um serviço esquecido e um erro lógico clássico levaram à completa compromissão do sistema. Mais uma lembrança de que mesmo tecnologias 'antigas' podem permanecer uma ameaça real se ainda estiverem em produção.
Logo após a publicação da informação sobre a vulnerabilidade, a equipe de pesquisadores implantou sensores honeypot para monitorar tentativas reais de exploração. Os atacantes não demoraram a aparecer. Em 18 horas de observação, foram registradas 60 tentativas de invasão de 18 fontes únicas. endereços IP. Segundo a plataforma Censys, cerca de três mil sistemas em todo o mundo se tornaram potencialmente vulneráveis, embora uma parte significativa deles provável também seja iscas honeypot.
A análise do tráfego interceptado revelou um quadro bastante variado. O atacante mais ativo era do endereço 178.16.53.82, que realizou 12 sessões contra 10 alvos diferentes. Suas ações eram totalmente automatizadas: após obter acesso, um conjunto padrão de comandos de reconhecimento era executado, como uname -a, id, leitura de /proc/cpuinfo e /etc/passwd. Uma característica notável foi a encapsulação da saída dos comandos com marcadores especiais para posterior análise, o que claramente aponta para um botnet ou um sistema automatizado de coleta de dados.
Um invasor mais sofisticado estava no endereço 216.106.186.24. Ele se concentrou em uma sub-rede específica e tentou estabelecer uma chave SSH para acesso permanente, além de baixar e executar um script Python de um servidor externo — presumivelmente, um malware para mineração de criptomoedas ou um botnet. No entanto, ambas as tentativas falharam: o diretório .ssh não existia no sistema alvo, assim como faltavam o curl e o python.
Dois atacantes com os endereços 167.172.111.135 e 165.22.30.48 despertam especial interesse. Ao contrário dos demais, eles não tentaram imediatamente obter acesso root, mas experimentaram com contas nobody, daemon e até uma inexistente nonexistent123. Os atrasos entre as sessões e a lógica das ações indicam a presença de uma pessoa real atrás do teclado. Provavelmente, são hackers mais experientes que conhecem sistemas de detecção de intrusão e têm técnicas para elevar privilégios.
Alguns atacantes demonstraram uma negligência surpreendente na segurança operacional. Por exemplo, um invasor do endereço 67.220.95.16 usou o mesmo IP tanto para exploração quanto para hospedar um servidor com malware. Outros revelaram acidentalmente os nomes de seus hosts através da variável DISPLAY: um trabalhava em um sistema chamado MiniBear, outro — em uma máquina virtual shared-vm2.localdomain, e um terceiro se conectava diretamente a partir de um ambiente gráfico completo do Kali Linux.
De modo geral, o nível dos atacantes foi bastante baixo. Entre 18 fontes de ataque, apenas algumas mostraram sinais de profissionalismo. A maioria usava ferramentas automatizadas básicas ou simplesmente digitava aleatoriamente, seguindo instruções da internet. O sistema de detecção de intrusões Suricata conseguiu identificar o momento em que um dos atacantes obteve acesso root, o que confirma mais uma vez a importância de uma proteção em múltiplas camadas e do monitoramento do tráfego de rede.
Os pesquisadores observam que essa vulnerabilidade, por um lado, deu oportunidade para hackers amadores praticarem, e por outro, permitiu que especialistas em segurança coletassem dados valiosos sobre táticas e ferramentas atuais dos invasores.
Saiba mais: https://www.securitylab.ru/news/568478.php
Fonte: linux.org.ru
