Telnet
Pur essendo attualmente poco diffusi tra gli utenti dell’internet pubblica, oggi gli applicativi che permettono di guadaganre il controllo remoto di altre stazioni rappresentano i diretti discendenti dei primi servizi fruibili attraverso le reti dati.
Non dimentichiamo che la rete ARPANET è nata, oltre che per condividere file tra utenti, per consentire l’esecuzione di elaborazioni su sistemi remoti e la fruizione condivisa dei risultati da tali elaborazioni prodotte.
Oggi sono classificati come applicativi per il controllo remoto sia servizi tradizionali come Telnet, Rlogin, Rsh e Rexec (essenzialmente orientati alla trasmissione di caratteri di testo), sia i servizi introdotti in tempi più recenti per un accesso ai sistemi in modalità grafica (come PCAnywhere, CarbonCopy, VNC, Remote Desktop Protocol).
Indipendentemente dalla tipologia del servizio, i requisiti di base per la sicurezza sono comuni a tutti questi applicativi: l’accesso ai sistemi remoti deve essere preceduto da un efficace controllo accessi, i comandi e le informazioni restituite devono essere protette contro alterazioni (data integrity) e intercettazioni (data privacy).
Il servizio Telnet, definito già nella RFC 854, nasce per consentire di interfacciarsi in maniera standard a sistemi remoti e poter fruire dal proprio client delle risorse della stazione server raggiungibile via rete.
Con il Telnet, gli utenti accreditati sul server, possono accedere a una propria area di lavoro (login shell) come se fossero direttamente connessi alla stazione tramite un terminale locale.
Per stabilire l’identità del richiedente, il servizio Telnet attua il trasferimento delle credenziali utente tramite il paradigma username/password.
Le credenziali dell’utente vengono generalmente memorizzate in un file della stazione remota, in modo che possano essere controllate dal server al momento della richiesta di servizio.
Il file con le credenziali può essere protetto tramite trasformazioni crittografiche non reversibili (password memorizzate sottoforma di hash code), onde evitare che un amministratore locale e/o un attaccante possa ricavare tutte le password dalla semplice lettura del file stesso.
Per la validazione delle credenziali passate dal client, il sistema remoto applica la funzione di digest ai dati ricevuti e poi verifica che quanto prodotto localmente coincida con le informazioni memorizzate.
Una volta superata la fase di autenticazione, l’utente legittimo può digitare sul proprio client Telnet tutti i comandi riconosciuti dalla propria shell e vederli eseguiti sulla stazione remota.
In risposta, il server Telnet restituisce al client l’output derivante dall’esecuzione dei comandi all’interno della shell.
Sono generalmente trasmessi al client tanto i caratteri relativi all’interfaccia stdout (standard output) quanto quelli relativi a quella stderr (standard error).
Il servizio Telnet si basa sul tradizionale paradigma di interazione client/server.
La connessione TCP aperta tra client e server consente il passaggio in entrambe le direzioni di dati di natura generale e di comandi specifici del protocollo.
I comandi specifici del protocollo Telnet prevedono codici di un solo byte e sono tutti preceduti dal valore esadecimale 0xFF.
Tale valore indica all’entità ricevente di interpretare il successivo byte trasferito come comando invece che come dato utente.
La porta riservata all’applicazione Telnet è la 23/tcp.
Il ruolo fondamentale del protocollo Telnet è quello di implementare un servizio trasparente, per mezzo del quale terminale utente e server possono scambiarsi comandi e visualizzarne il risultato anche quando i sistemi risultano eterogenei.
Per riuscire a nascondere questa eterogeneità, il protocollo Telnet converte tutti i comandi digitati dall’utente in un formato standard, noto come formato NVT (Network Virtual Terminal) e li invia al server remoto.
Per i dati di ritorno, è responsabilità del server remoto eseguire la stessa conversione sulla stazione remota.
Attraverso la rete vengono inviati solo dati e comandi nel formato NVT.
Per la natura del servizio offerto, un client Telnet può essere utilizzato anche come gateway applicativo per accedere ad altri servizi.
Per accedere a protocolli come SMTP o HTTP tramite Telnet, è sufficiente specificare il numero di porta del server remoto e rispettare la sintassi, la semantica e la temporizzazione dei comandi previsti dal protocollo che si intende emulare.
Una simile funzionalità può essere utilizzata da un amministratore per testare i propri server, ma può tornare utile anche a un hacker come strumento elementare per effettuare tentativi di penetration test.
La vulnerabilità principale del protocollo Telnet, però, non consiste nella possibilità che esso venga utilizzato come strumento per emulare altri protocolli.
Sono a disposizione degli hacker strumenti ben più pericolosi.
È assai più preoccupante la possibilità che, attraverso il Telnet, un hacker possa accedere alle risorse di una stazione remota e lanciare una serie di comandi come se fosse direttamente collegato a essa.
Poichè solo gli utenti precedentemente accreditati sul server possono richiedere il servizio Telnet, la sola prevenzione possibile è limitare il numero di utenti ammessi a fruire del servizio e mantenere riservate le credenziali utente.
Purtroppo la versione standard del protocollo prevede che username e password vengano inviate in chiaro sulla rete.
Per evitare che un hacker, intercettata la coppia username e password, la utilizzi per un Replay Attack, è indispensabile che ciascuna coppia possa essere utilizzata una e una sola volta (soluzione OTP).
In alternativa è possibile sostituire il protocollo Telnet con un altro servizio, più orientato alla sicurezza, dove si preveda una procedura di autenticazione fondata su un paradigma più robusto (esempio challenge/response).
L’altra pesante limitazione attribuita al protocollo Telnet è la trasmissione in chiaro di ogni comando e output generato in seguito all’esecuzione del comando stesso.
Potendo trasferire solo dati e comandi nel formato NVT, il Telnet non si presta bene alla trasmissione di informazioni riservate.
Le funzioni crittografiche trasformano infatti i dati di ingresso in generici messaggi binari, non codificabili direttamente in formato NVT.
Per superare questa limitazione è necessario operare una conversione di formato intermedia, riconducendo il risultato delle funzioni crittografiche al set di caratteri ASCII stampabili. Questa operazione introduce un fattore di perdita di trasmissione in quanto provoca l’espansione delle dimensioni del messaggio originario.
Inoltre per assicurare data privacy e data integrity all’interno del protocollo Telnet non basta prevedere l’introduzione di soluzioni crittografiche in grado di cifrare ogni messaggio trasmesso.
Il protocollo Telnet infatti è orientato alla trasmissione di dati non strutturati (data stream).
Se si vuol essere sicuri di scongiurare anche le forme di attacco più ostinate (per esempio tramite man-in-the-middle), occorre prevedere una soluzione tra client e server all’interno del flusso.
Al fine di verificare l’integrità della sequenza di dati trasmessi, è indispensabile crittografare tutto il flusso di dati, concatenando ciascun byte a quello che lo precede e a quello che lo segue.
Solo in questo modo è possibile garantire che nessuna parte del flusso dati sia stata alterata da parte di un attaccante.
Per superare queste limitazioni sarebbe necessaria una riscrittura completa del protocollo Telnet, con conseguente perdita di semplicità e compatibilità con i sistemi non provvisti di crittografia.
Per aggirare questo inconveniente tutte le versioni crittografiche del protocollo Telnet oggi disponibili, sono basate sull’instaurazione preliminare di un canale sicuro su cui trasmettere successivamente tutti i messaggi previsti dal protocollo standard.
La porta riservata per il Telnet over SSL è la 992/tcp.
Nel caso si preferisca l’adozione dello standard SSH, la porta riservata è invece la 22/tcp.
