TACACS: vulnerabilità MD5, rischio accessi privilegiati
Molti apparati di rete critici, come router, switch e firewall, continuano a usare TACACS+ per centralizzare autenticazione, autorizzazione e accounting (AAA). Progettato da Cisco nei primi anni ’90, questo protocollo offre funzioni utili come la separazione netta tra auth, authz e accounting, oltre al controllo granulare per comando. Ma dietro questi vantaggi si nasconde un problema serio: scelte crittografiche datate che oggi rappresentano una vulnerabilità concreta. La combinazione di design obsoleto, implementazioni fragili e scarsa manutenzione delle infrastrutture crea ancora oggi superfici di attacco reali per chi vuole compromettere il controllo degli accessi privilegiati.
Origine e natura tecnica del problema in TACACS+
TACACS+ non nasce come protocollo standard IETF, ma come specifica proprietaria Cisco. Usa la porta TCP/49 e una logica di cifratura basata su MD5: il corpo dei pacchetti viene cifrato tramite XOR con blocchi derivati da MD5 applicato al segreto condiviso, al session ID e a contatori progressivi.
Questo approccio presenta tre debolezze strutturali:
- Non offre autenticazione dell’intero messaggio con un MAC moderno, come HMAC o cifrari AEAD.
- Dipende da MD5, algoritmo ormai considerato insicuro per molti scenari applicativi.
- Non implementa contromisure solide contro replay o problemi di sequenziamento, a differenza di quanto garantirebbe TLS.
La conseguenza pratica è che la cifratura risulta obsoleta e mancano garanzie moderne di integrità e autenticità. Questo rende più semplice analizzare, manipolare e in alcuni casi falsificare messaggi TACACS+ rispetto a protocolli che viaggiano su canali TLS con HMAC.
Va detto che storicamente i problemi più sfruttati non derivano sempre da un bug intrinseco del protocollo. Spesso la causa sono implementazioni difettose nel demone tac_plus o nei server vendor, configurazioni deboli con shared secret banali, backup non protetti, oppure comportamenti di fallback non sicuri sui dispositivi di rete.
Il paradosso della vulnerabilità invecchiata
Perché un difetto progettuale degli anni ’90 resta sfruttabile ancora oggi? Le ragioni sono diverse e si intrecciano tra loro.
- Lunga vita degli apparati di rete: molti switch e router restano in produzione per anni, a volte con firmware non aggiornabile o ormai in End of Life.
- Conservatorismo operativo: i team evitano cambi radicali sull’infrastruttura in produzione per non interrompere servizi critici.
- Gestione debole del ciclo di vita del software: inventari incompleti, patching irregolare e dipendenza da vendor che non sempre rilasciano aggiornamenti per versioni legacy.
- Segreti esposti: i dati di configurazione, inclusi i shared secret TACACS+, finiscono spesso in repository o backup senza cifratura adeguata, diventando chiavi “trapelabili”.
Il risultato è che, anche se la comunità di sicurezza conosce bene i limiti teorici del protocollo, l’ecosistema reale mantiene vettori d’attacco pienamente praticabili.
Come avviene un attacco tipico contro TACACS+
Un esempio realistico di catena d’attacco si sviluppa in tre fasi distinte.
Fase 1: ricognizione e compromissione iniziale
L’attaccante ottiene accesso a un server amministrativo, a un backup o a un repository di configurazioni dove sono memorizzati i secret TACACS+, oppure intercetta traffico su una rete di management non segmentata.
Fase 2: recupero e uso del shared secret
Con la chiave condivisa in mano, l’attaccante può impersonare il server TACACS+ rispondendo a richieste di autenticazione dei dispositivi, manipolare le risposte per accettare credenziali o elevare privilegi, oppure sfruttare una vulnerabilità di implementazione per ottenere esecuzione di codice remoto sul server.
Fase 3: automazione dell’attacco
Script o bot possono inviare richieste TACACS+ correttamente “firmate” con la shared key per creare sessioni amministrative su centinaia di apparati contemporaneamente. Da qui si arriva facilmente a modifiche di configurazione in massa, inclusa la creazione di backdoor o la disabilitazione del logging.
È importante notare che, in molte vicende reali, gli attacchi non derivano da un vero e proprio break crittografico del protocollo, quanto piuttosto da segreti esposti, implementazioni vulnerabili o reti di management insufficientemente isolate.
Perché questo rappresenta un rischio per le infrastrutture critiche
TACACS+ gestisce spesso gli accessi di tutti gli amministratori di una rete. Questo significa che una centralizzazione dei privilegi diventa anche un singolo punto di compromissione: se il sistema AAA viene violato, crolla la fiducia sull’intero controllo degli accessi.
Un attaccante con il controllo del sistema TACACS+ può modificare policy da remoto, creare account persistenti, disabilitare il logging e coprire le proprie tracce, tutto in tempi rapidi e su larga scala. Settori regolamentati come energia, telecomunicazioni e finance subiscono impatti particolarmente elevati: un attacco a livello AAA può essere il preludio a un blackout operativo o al furto di dati sensibili.
TACACS+ confrontato con RADIUS e le alternative moderne
RADIUS nasce per l’autenticazione e il controllo degli accessi in ambito dial-up e Wi-Fi. Usa UDP e ha un modello diverso, pratico ma con limiti propri: storicamente cifra solo la password nel pacchetto Access-Request e usa MD5 per parti del messaggio. Anche RADIUS, quindi, soffre di problemi analoghi sul piano crittografico se utilizzato senza protezioni aggiuntive.
Un miglioramento significativo arriva con RadSec, ovvero RADIUS veicolato su TLS, che porta il protocollo su un canale cifrato e autenticato, rappresentando un modello più moderno per risolvere i problemi di trasporto.
TACACS+ viene spesso preferito per il controllo per-comando e la separazione dei servizi, mentre RADIUS resta la scelta comune per l’autenticazione di accessi di rete e 802.1X. Nessuno dei due protocolli, però, è intrinsecamente sicuro senza un layer di trasporto moderno come TLS e senza pratiche operative robuste.
Checklist operativa per amministratori di rete
Ecco una serie di raccomandazioni pratiche per ridurre il rischio legato a deployment TACACS+ legacy.
Segmentazione di rete
- Isolare la rete di management e permettere connessioni verso TACACS+ solo da indirizzi e device autorizzati, tramite ACL, VRF o gestione out-of-band.
- Bloccare l’accesso alla porta TCP/49 verso il server TACACS+ da reti non autorizzate.
Hardening del server
- Eseguire aggiornamenti regolari del software tac_plus o delle appliance vendor, monitorando le advisory ufficiali.
- Usare solo versioni supportate, rimuovendo o isolando quelle in End of Life.
- Limitare i servizi esposti con firewall a livello host, accettando connessioni solo da IP conosciuti.
Gestione dei segreti
- Utilizzare shared secret robusti con rotazione periodica, evitando che finiscano in chiaro in repository o backup.
- Valutare canali autenticati e cifrati come RadSec, dove disponibili tramite implementazioni vendor.
- Introdurre autenticazione a due fattori per operazioni di management, come accessi SSH o console.
Monitoraggio continuo
- Centralizzare i log TACACS+ e impostare alert su pattern anomali, come molteplici tentativi di accesso o cambi improvvisi di privilegi.
- Configurare regole IDS/IPS per rilevare risposte TACACS+ fuori sequenza o tentativi di impersonificazione.
- Analizzare regolarmente i backup di configurazione per individuare modifiche non autorizzate.
Il debito tecnico come problema culturale
Il problema di TACACS+ non è solo tecnico, ma anche culturale. Scelte progettuali fatte decenni fa, motivate da compatibilità e semplicità, diventano oggi un vero e proprio debito tecnico che richiede investimenti per essere sanato.
Questo debito si manifesta in un aumento della superficie d’attacco, in costi di gestione e risposta agli incidenti più elevati, e in una crescente dipendenza da workaround e controlli compensativi. Mitigarlo richiede un inventario accurato degli asset, una pianificazione a lungo termine, budget dedicato al rinnovo delle infrastrutture e un processo sicuro per il ritiro dei sistemi obsoleti.
Conclusione
Non esiste una soluzione magica per questo problema. TACACS+ non è automaticamente insicuro in ogni implementazione, ma le sue radici progettuali, tra cifratura basata su MD5, assenza di standard TLS integrato ed ecosistema legacy, insieme ai numerosi casi di implementazioni o configurazioni vulnerabili, lo rendono un bersaglio appetibile per chi cerca accessi privilegiati.
Per le infrastrutture critiche è fondamentale non affidarsi alla sola percezione di sicurezza di un protocollo. Servono difese in profondità, gestione rigorosa delle chiavi, segmentazione di rete accurata, monitoraggio continuo e un piano credibile per aggiornare o sostituire i componenti legacy prima che diventino la porta d’ingresso per il prossimo incidente di sicurezza.