Una vulnerabilità nel pacchetto GNU InetUtils ha interessato tutte le versioni dalla 1.9.3 alla 2.7 inclusa.
Sembrerebbe che telnet sia ormai un ricordo del passato insieme ai modem e al dial-up, ma incredibilmente è diventato la fonte di una grave vulnerabilità. È stato scoperto un bug in GNU InetUtils che consente di accedere al sistema come root senza password, semplicemente inviando un valore di variabile d'ambiente appositamente formato.
Il problema riguarda il server telnetd che fa parte di GNU InetUtils. Questo trasferisce al programma login il valore della variabile USER ricevuto dal client, senza alcun controllo. Può essere sfruttato se il client invia la stringa "-f root" come USER e si connette con il parametro telnet -a o –login. Di conseguenza, login interpreta questo come un flag di sistema, bypassa la normale procedura di autenticazione e autentica automaticamente l'utente come root.
La vulnerabilità ha ricevuto l'identificativo CVE-2026-24061 e un punteggio CVSS di 9.8. Sono a rischio tutte le versioni di GNU InetUtils, dalla 1.9.3 alla 2.7 inclusa. Il bug è presente nel progetto da quasi 11 anni, da maggio 2015, ma è stato scoperto solo adesso. Fondamentalmente, è un classico esempio di vulnerabilità di vecchia scuola, in cui una stringa pericolosa non filtrata viene passata a un'utilità di sistema con privilegi di root.
Gli autori dell'advisory raccomandano di non utilizzare affatto telnetd, di limitare l'accesso alla porta telnet solo a client fidati e di implementare il fix o aggiornarsi il prima possibile a una versione in cui il problema è stato risolto. Una soluzione temporanea può essere la disattivazione completa di telnetd o l'uso di una versione personalizzata di login che non supporta l'opzione "-f".
La vulnerabilità è stata scoperta dal ricercatore Carlos Cortes Alvarez, il patch è stato preparato e perfezionato dagli sviluppatori di GNU InetUtils a gennaio 2026. Le correzioni includono la sanitizzazione di tutte le variabili utilizzate per formare il comando di chiamata a login, in modo che tali attacchi diventino impossibili in linea di principio.
La storia sembra quasi simbolica: un protocollo obsoleto, un servizio dimenticato e un classico errore logico hanno portato a una compromissione totale del sistema. Un ulteriore promemoria che anche le tecnologie 'antiche' possono rappresentare una minaccia reale se continuano a essere operative in produzione.
Subito dopo la pubblicazione delle informazioni sulla vulnerabilità, il team di ricercatori ha implementato sensori honeypot per monitorare i tentativi reali di sfruttamento. Gli attaccanti non hanno tardato ad arrivare. In 18 ore di osservazione sono stati registrati 60 tentativi di attacco da 18 unici. IP addresses. Secondo i dati della piattaforma Censys, circa tremila sistemi in tutto il mondo sono risultati potenzialmente vulnerabili, anche se una parte significativa di essi è probabilmente anch'essa trappole honeypot.
L'analisi del traffico intercettato ha mostrato un quadro piuttosto variegato. L'attaccante più attivo è stato quello con indirizzo 178.16.53.82, che ha condotto 12 sessioni contro 10 obiettivi diversi. Le sue azioni erano completamente automatizzate: dopo aver ottenuto l'accesso, veniva eseguito un set standard di comandi di ricognizione come uname -a, id, lettura di /proc/cpuinfo e /etc/passwd. Una caratteristica distintiva è stata l'aggiunta di marcatori speciali all'output dei comandi per un successivo parsing, il che indica chiaramente un botnet o un sistema automatizzato di raccolta dati.
L'attaccante più sofisticato è stato quello con indirizzo 216.106.186.24. Si è concentrato su una sottorete specifica e ha tentato di stabilire una chiave SSH per un accesso permanente, oltre a scaricare e avviare uno script Python da un server esterno — presumibilmente un malware per il mining di criptovalute o un botnet. Tuttavia, entrambi i tentativi sono falliti: nel sistema target non esisteva la directory .ssh e mancavano anche curl e python.
Particolare interesse suscitano due attaccanti con indirizzi 167.172.111.135 e 165.22.30.48. A differenza degli altri, non hanno cercato immediatamente di ottenere l'accesso root, ma hanno sperimentato con gli account nobody, daemon e persino l'inesistente nonexistent123. I ritardi tra le sessioni e la logica delle azioni indicano una persona reale alla tastiera. Probabilmente, si tratta di hacker più esperti che conoscono i sistemi di rilevamento delle intrusioni e dispongono di tecniche per l'elevazione dei privilegi.
Alcuni attaccanti hanno mostrato una sorprendente negligenza nella sicurezza operativa. Ad esempio, un malintenzionato con l'indirizzo 67.220.95.16 ha utilizzato lo stesso IP sia per l'exploitation che per l'hosting del server con malware. Altri hanno rivelato casualmente i nomi dei loro host tramite la variabile DISPLAY: uno lavorava su un sistema chiamato MiniBear, un altro su una macchina virtuale shared-vm2.localdomain, mentre un terzo si è connesso direttamente da un ambiente grafico completo di Kali Linux.
In generale, il livello degli attaccanti si è rivelato piuttosto basso. Di 18 fonti di attacco, solo poche hanno mostrato segni di professionalità. La maggior parte ha utilizzato semplici strumenti automatizzati o ha digitato a caso seguendo le istruzioni trovate online. Il sistema di rilevamento delle intrusioni Suricata ha rilevato con successo il momento in cui uno degli attaccanti ha ottenuto l'accesso root, confermando ancora una volta l'importanza di una protezione multilivello e del monitoraggio del traffico di rete.
Gli ricercatori osservano che questa vulnerabilità, da un lato, ha fornito l'opportunità agli hacker dilettanti di esercitarsi, ma dall'altro ha permesso agli esperti di sicurezza di raccogliere dati preziosi sulle attuali tattiche e strumenti degli aggressori.
Maggiori dettagli: https://www.securitylab.ru/news/568478.php
Fonte: linux.org.ru
