Il protocollo TCP (Transport Control Protocol) è uno dei pilastri della moderna infrastruttura telematica basta su modello IP.

E’ uno strumento incredibilmente usato e ben conosciuto nel panorama mondiale in grado di costituire circuiti virtuali logici tra differenti peer e permette l’interscambio di informazioni in modo affidabile con caratteristiche di adattamento, semplicità e priorità uniche. Pur con un aumento totlae del traffico UDP negli ultimi anni il protocollo TCP, nelle sue varianti, rimane saldamente sulla soglia del 90% del traffico totale internet.

Uno dei punti di forza del TCP risiedenel  “three-way-handshake”, codificato RFC 793, ovvero quel meccanismo in grado di creare una connessione tra un client e un server per l’interscambio informazioni in sequenza, per poi abbatterla una volta concluso il trasferimento.  Semplificando la procedura questa si basa sull’invio di un particolare pacchetto denominato SYN da parte del client, il server risponde con un pacchetto ACK+SYN e attende una conferma ACK dal client. Completando questo scambio di informazioni iniziali il flusso di dati tra server e client può iniziare regolarmente.

Questo meccanismo è, ad esempio, alla base di ogni connessione web HTTP/HTTPS dove il server rimane in ascolto sulla porta 80/443 mentre il client invia la sua richiesta con una porta random >1024. Il socket ovvero la coppia si completa cone le informazioni IP_SRC + PORT_SRC e IP_DST + PORT_DEST e tutti i dispositivi di rete intermedi tra i peer rispettano questa struttura.

L’intero comportamento è stato parzialmente messo in crisi da un differente approccio detto TCP Split Handshake ben descritto nel paper The TCP Split Handshake: Practical Effects on Modern Network Equipment 2010 creato da Tod Beardsley e Jin Qian. Con una semplice modifica al comportamento TCP della risposta del server è infatti possibile cambiare pesantemente la logica di connessione inducendo una connessione inversa. In pratica, anche se il client inizia regolarmente la connessione, il server rovescia le parti e in definitiva avviene una connessione al client con buona pace dei dispositivi di sicurezza, come i firewall, anche in configurazioni di NAT che in teoria dovrebbero vietare questo genere di comportamento.

Tale risultato potenzialmente favorisce vulnerabilità di tipo day-zero, la quale richiede di essere iniziata da un client interno verso un server esterno compromesso. Tale situazione ben si presta a tecniche di phishing dove l’ignaro utente cerca di accedere ad un sito che ritiene legittimo, ma che invece è una fonte di malware. La connessione inversa potrebbe permettere potenzialmente di prendere il controllo totale o parziale del client interno e vi sono già indicazioni di tool su mercato cinese, fortunatamente su piccola scala, che sfruttano questa vulnerabilità per i loro scopi.

TCP Split Handshake in azione

L’idea originale alla base del TCP Split Handshake risiede nella volontà di spezzare la sequenza ACK+SYN inviato dal server, a fronte di una richiesta iniziale di SYN da parte del client, in due differenti stati logici. Il pacchetto di ACK è inviato regolarmente con il valore numerico incrementato di uno mentre il pacchetto di SYN viene spedito senza il flag SYN settato.  Il client si aspetta la classica sequenza corretta e accetta entrambi i pacchetti, ma invece di inviare un ACK finale ed entrare nella condizione finale di ESTABLISHED completando così  il circuito virtuale TCP layer 4, invia a sua volta una sequenza ACK+SYN e si pone nella condizione di ESTABLISHED dopo solo l’arrivo dell’ACK da parte del server corrotto.

Una ulteriore semplificazione permette di ridurre il numero dei pacchetti trasmessi, tralasciando il pacchetto di ACK inziale che il client si aspetta come risposta dal server perché superfluo in questa configurazione. In figura sono evidenziati i passi usati da questa speciale connessione 4-way.

Questo meccanismo comporta il rovesciamento delle parte durante la connessione, non è più infatti il client locale che si connette al server remoto ma, al contrario è il server remoto compromesso che eseguire una connessione a Layer 4 verso il client locale. E’ però necessario che l’inizializzazione della sequenza segua il classico processo di connessione client-server.

Svariate prove sono state eseguite con differenti dispositivi consumer configurati con sistemi  operativi differenti come Windows XP, Windws Seven, Linux e Mac; tutti si sono comportanti nel modo descritto indicando che questa particolare caratteristica dello stack TCP è multi-piattaforma e multi-dispositivo e viene ritenuta una operazione legittima all’interno del mondo TCP.

Dal punto di vista della network security, questo meccanismo apre nuovi e interessanti scenari di possibili vulnerabilità e i primi test hanno evidenziato che sono veramente pochi dispositivi di sicurezza come Firewall o IPS in grado di rilevare come minaccia e bloccare o almeno evidenziar questa novità dell’uso del protocollo TCP. In particolare i classici statefull firewall ne favoriscono l’utilizzo proprio per la loro costruzione interna che permette il passaggio di traffico di ritorno in base a specifiche e ben definite tabelle di stato, le quali non tengono conto di una mutazione così particolare del protocollo.

L’immissione di modifiche al flusso o accorgimenti speciali come SYN COOKIE permettono comunque  di isolare questo genere di problema, avendo però come controindicazione un abbassamento generale delle performance dei dispositivi, cosa assolutamente inaccettabile in ambito enterprise.