Protocolli in chiaro: cosa vedono gli aggressori

HTTP trasmette tutti i dati come testo ASCII in chiaro, senza crittografia. Quando invia un modulo di accesso tramite HTTP, il browser trasmette una richiesta POST contenente il nome utente e la password in chiaro. Chiunque si trovi sullo stesso segmento di rete, oppure qualsiasi router tra Lei e il server, può leggere l'intera richiesta, comprese le credenziali, i cookie di sessione e tutti i dati sensibili del modulo.

Telnet era il protocollo standard per i terminali remoti prima di SSH. Ogni tasto premuto in una sessione Telnet viaggia verso il server come un singolo pacchetto TCP non cifrato. Un attaccante che cattura il traffico di rete vede non solo il nome utente e la password inseriti al momento dell'accesso, ma anche ogni comando digitato e ogni riga di output visualizzata, consentendo il dirottamento completo della sessione senza alcuna barriera crittografica.

FTP esegue l'autenticazione con un comando USER seguito da un comando PASS, entrambi inviati come testo in chiaro sulla porta TCP 21. Una cattura dei pacchetti durante un accesso FTP mostra le credenziali esatte. Anche se il canale di trasferimento dei file è cifrato con FTPS, lo scambio iniziale per l'autenticazione rivela la password a qualsiasi osservatore. I server FTP legacy sono comuni negli ambienti aziendali e rappresentano obiettivi facili per la raccolta di credenziali.

POP3 (porta 110) e IMAP (porta 143) senza TLS inviano le credenziali email e il contenuto completo dei messaggi in chiaro. Quando un utente apre il proprio client di posta su una rete Wi-Fi di un bar con una configurazione non cifrata del server di posta, ogni email scaricata è leggibile da qualsiasi altro dispositivo sulla rete. L'uso di POP3S (porta 995) e IMAPS (porta 993) applica TLS fin dall'inizio della connessione.

I server di database come MySQL (porta 3306) e PostgreSQL (porta 5432) supportano per impostazione predefinita connessioni non cifrate. I server applicativi che si connettono al database senza imporre SSL inviano query e risultati, inclusi dati personali sensibili, come testo in chiaro attraverso la rete. Le reti interne sono spesso considerate affidabili, ma gli attaccanti che riescono a ottenere un qualsiasi punto d'appoggio possono iniziare immediatamente a intercettare il traffico del database.

LDAP (Lightweight Directory Access Protocol) sulla porta 389 trasmette in chiaro le query alla directory e le informazioni di autenticazione. Gli ambienti aziendali che usano Active Directory per l'autenticazione possono esporre le operazioni di bind LDAP, inclusi nomi utente e password, sulla rete interna. LDAPS sulla porta 636 usa TLS e STARTTLS sulla porta 389 può aggiornare la connessione, ma queste opzioni non sono sempre imposte.

Per impostazione predefinita, Redis è in ascolto sulla porta 6379 senza autenticazione e senza TLS. Un'istanza Redis esposta alla rete senza password consente a qualsiasi client di leggere tutte le chiavi memorizzate, eseguire comandi arbitrari e potenzialmente scrivere file di configurazione. Fino a Redis 6.0 (2020), quando è stato aggiunto il supporto TLS, tutto il traffico Redis, inclusi i dati della cache e i token di sessione, era completamente esposto in rete.

Memcached, un livello di caching ampiamente utilizzato, non dispone di un meccanismo di autenticazione integrato e invia tutti i dati come testo ASCII in chiaro sulla porta TCP 11211. Gli sviluppatori si affidano in genere ai firewall di rete per limitarne l'accesso, ma istanze Memcached configurate in modo errato ed esposte a Internet sono state utilizzate per attacchi DDoS di amplificazione e furti di dati. Tutti i contenuti memorizzati nella cache, inclusi i dati di sessione e le risposte API, sono visibili a chiunque possa raggiungere la porta.

Il syslog tradizionale usa la porta UDP 514 senza autenticazione né cifratura. I log di sistema inviati attraverso la rete possono essere letti, modificati o falsificati da chiunque si trovi lungo il percorso. Un attaccante che riesce a intercettare il traffico syslog può leggere gli eventi di sicurezza in tempo reale o inserire voci di log false per coprire le proprie tracce. RFC 5425 definisce il syslog su TLS, ma molti sistemi usano ancora il protocollo legacy in chiaro.

Da un singolo punto di osservazione della rete, un attaccante che cattura il traffico di protocolli in chiaro ottiene una visione completa dell'ambiente. Può vedere nomi utente e password di più servizi, token di sessione riutilizzabili senza la password originale, dati sensibili trasferiti e l'architettura interna della rete. Queste informazioni possono essere raccolte passivamente, senza interagire con i sistemi bersaglio.

Nonostante si conoscano da decenni i rischi del testo in chiaro, i protocolli non cifrati persistono a causa di sistemi legacy che non possono essere aggiornati, della complessità di configurazione negli ambienti di grandi dimensioni, dei timori relativi alle prestazioni sui collegamenti interni ad alto throughput e dell'ipotesi che le reti interne siano affidabili. La segmentazione della rete e i principi dell'architettura zero trust contrastano questa ipotesi, applicando al traffico interno lo stesso livello di attenzione riservato a quello esterno.

Quale delle seguenti combinazioni di protocollo e porta trasmette per impostazione predefinita le credenziali di autenticazione in chiaro?

HTTP, Telnet, FTP, POP3, IMAP, le connessioni dirette ai database, LDAP, Redis, Memcached e syslog trasmettono tutti i dati senza cifratura per impostazione predefinita. Qualsiasi osservatore lungo il percorso di rete può leggere credenziali, token di sessione e dati sensibili. Esistono equivalenti protetti da TLS per tutti questi protocolli. Le ipotesi di affidabilità della rete interna sono pericolose: i principi zero trust considerano tutto il traffico potenzialmente osservabile.