Posts Tagged ‘Juniper’

TCP Split Handshake Attack Explained

April 17, 2011 9 comments

Update May 12: TCP Split Handshake: Why Cisco ASA is not susceptible

Update May 11: The Never Ending Story

Update April 21: Other Considerations on TCP Split Handshake

Few days ago, independent security research and testing NSS Labs, issued a comparative report among six network security technologies. The controversial results created a comprehensible turmoil among the security vendors involved in the tests, and more in general inside the infosec landscape. As a matter of fact it turned out that that five of the six tested platforms were susceptible to TCP Split handshake attack.

As a security professional, I am pretty much involved with at least five of the six tested technologies, consequently, although I never heard about TCP Split Handshake before, I must confess I was really curious to learn which was the only platform capable of surviving the test (the answer is indirectly provided by the vendor – Checkpoint – missing from the list contained on the remediation report subsequently released). Fortunately the scientific side of me took over and instead of making judgments and drawing conclusions about the results, I decided to learn more about TCP Split Handshake and the reasons why a security equipment may be vulnerable.

TCP Split Handshake in RFC 793

Since TCP is a connection-oriented protocol, every connection begins with a “handshake” defined in RFC 793. The handshake defines three well defined steps and for this reason it is called “TCP Three Way Handshake.”

The host initiating the connection, referred as the client, send to its peer, referred as the server, a synchronization packet, or SYN. In order to correctly identify the beginning (and the subsequent “state” of the session, the SYN packet contains an initial Sequence Number (ISN) which corresponds to a pseudo-random number.

Upon reception of the SYN packet, the server acknowledges that, and generates its own SYN. This “SYN/ACK” packet contains both the server’s Initial Sequence Number, as well as an acknowledgment number equal to the client’s Sequence Number plus 1. The fact that the server sends a single packet to initiate the connection on its side and to acknowledge the initial SYN sent from the client is known as piggy-backing and, as explained later, is the fundamental aspect in which TCP Split Handshake differs from Three Way Handshake.

At this point, in order to establish the session, the client concludes the Three Way Handshake and acknowledges the server’s SYN/ACK, sending a packet with its own ISN incremented by one, as well as its acknowledgement number equal to the server’s ISN plus 1.

As mentioned above, in the second phase of the handshake, the piggy-backing allows the server to use a single packet to send its own SYN and to acknowledge the SYN packet received from the client (ACK). However, let us assume that the server could decide to split the second phase of the handshake and send a dedicated ACK packet to acknowledge the client SYN, and a further dedicated packet with its own SYN. This is exactly what is stated at section 3.3, page 27, of RFC 793, which introduces an intriguing four-step process:

1) A --> B  SYN my sequence number is X
2) A <-- B  ACK your sequence number is X
3) A <-- B  SYN my sequence number is Y
4) A --> B  ACK your sequence number is Y

As a consequence, one might expect that an RFC 793 perfectly compliant client be capable to silently accept packet two, explicitly ACK packet 3, and hence complete the handshake more-or-less normally. At least in theory…

In reality, in such similar circumstances, NSS test have shown that some network security devices, with the sole firewall function enabled, get confused and behaves in a stateless manner. In few words, if even the client behaves as stated in the RFC, that is it is able to correctly establish the session even if it accepts separated ACK and SYN packets from the server, the network security device, on receiving the SYN from the server (packet 2), loses the awareness of the session and lets the traffic flow without enforcing any security control as if it belongs to an uncontrolled session (in theory an unknown or out-of-state session should be blocked). This means that a malicious payload conveyed through a TCP Split Handshake intiated session could go through the firewall and as a consequence, an attack scenario is quite straightforward: an attacker could think to use a server-side malicious script to establish the session by mean of a TCP Split Handshake and consequently install an executable on the client (a very fashionable event in the last days), for instance, by mean of an ActiveX Buffer Overflow on the target client browser.

The bad news is that this kind of attack is not new, and a similar attack scenario was reported for the first time approximately one year ago (with different behaviours reported for clients and security devices). The strange side of the story relies on the fact that this behaviour may not be considered a real vulnerability, but rather an occurrence covered by RFC not correctly implemented or not enabled on the default configuration by security vendors (please consider that RFC 793 also includes a further method for establishing a TCP connection dubbed “TCP Simultaneous Open” in which two TCP hosts simultaneously attempt to open a connection to each other via a SYN packet).

Last but not least…

For the record, as previously stated, NSS Labs released a remediation report containing the indications needed to mitigate (where necessary) the occurrence of the TCP Split Handshake for the affected technologies. Moreover two vendors (Cisco and Fortinet) added some indications as reported in the following:

  • According to an official blog post, Cisco was not able to reproduce the issue occurred in NSS Labs Test and is further investigating the TCP Split Handshake attack on its devices.
  • According to an official response in a blog post, Fortinet is not susceptible to TCP Split Handshake attack if IPS and Antivirus protections are enabled. A special IPS signature has been developed and a firmware update is scheduled for May in order to block TCP Split Handshake attack with only firewall enabled:
  • For Juniper devices the line “set security flow tcp-session strict-syn-check” must be  inserted into configuration (this option affects all the traffic, so it must be set with caution);
  • Palo Alto is working to release an official fix between mid-April and early May;
  • For Sonicwall devices, the option “Enforce Strict TCP Compliance” must be enabled (also in this case this option affects all the traffic and must be set with caution).

Ne resterà soltanto uno… (Seconda Parte)

December 8, 2010 5 comments

Se immaginassimo per un attimo che non esista Antitrust, concentrandoci ad immaginare il framework di sicurezza ideale, potremmo suddividere un offerta completa di sicurezza in 6 domini:

  • Sicurezza degli Endpoint (EPP) che include le funzioni di Antivirus, Personal Firewall/Network Access Control, Host IPS, DLP, Cifratura per tutte le classi di dispositivi, mobili o fissi;
  • Sicurezza della rete e dei contenuti (NP) che include le funzioni di Firewall, IPS, Web and Email Protection;
  • Sicurezza applicativa  (AP) che include le aree di analisi del codice, WEB/XML/Database Firewall;
  • Compliance: che include le funzioni di assessment e verifica della sicurezza delle postazioni e delle applicazioni
  • Identity & Access Management (IAM) che include le funzi0ni di autenticazione, accesso sicuro ai dati, etc.
  • Gestione & Management che inclide la funzione di gestione unificata dei domini delineati in precedenza.

Rappresentando graficamente il modello, per ogni offerta di sicurezza da parte di un produttore è possibile associare tre livelli di conformità (conforme, parzialmente conforme, non conforme). Il modello di sicurezza unificato (che vede la sicurezza come un processo end-to-end) è quello a cui stanno tendendo i produttori:  se si mappano gli stessi in 3 livelli (Colossi,  Leader e Niche Player) è interessante notare come i vendor stiano tendendo verso il modello, ove possibile tramite prodotti interni, oppure mediante acquisizioni mirate a colmare eventuali lacune della propria offerta.

  • I “Colossi” sono produttori dotati delle capacità tecnologiche e finanziarie tali da poter costruire una offerta completa. Liquidità e capitalizzazione sono tali da poter acquisire una o più aziende per colmare un Gap all’interno della loro offerta. Rientrano in questa categoria aziende con capitalizzazione attorno o superiore a 100 miliardi di dollari, quali il nuovo arrivato Intel e vecchie conoscenze come Cisco, IBM, Microsoft, HP.
  • I “Leader”: rientrano in questa categoria i player focalizzati sulla sicurezza che offrono, nel proprio segmento, soluzioni best of breed. I player appartenenti a queta categoria sono di dimensioni tali da effettuare acquisizioni per costruire una offerta completa ma non abbastanza grandi per non essere loro stessi oggetti del desiderio dei colossi in una situazione di mercato complessa come l’attuale. Esempi rampanti sono le compiante McAfee e ISS (acquisite rispettivamente da Intel e IBM) e gli oggetti del desiderio Symantec e Checkpoint.
  • I “Niche Player: rientrano in questa categoria i produttori di Nicchia che ci sono specializzati in specifici segmenti in cui hanno raggiunto livelli tecnologici eccellenti e che di conseguenza potrebbero far gola a rappresentanti delle categorie sopra riportate. Rientrano in questa categoria ad esempio Kasperky, Trend Micro,  etc…

In realtà ai colossi andrebbe aggiunta una ulteriore categoria, quella degli “outsider”. Gli outsider sono aziende dotate di vasta capitalizzazione ma ad oggi non sufficientemente focalizzate sulla sicurezza (ovvero potenziali colossi come era Intel sino a qualche mese fa) oppure fortemente focalizzate sulla sicurezza, ma con una capitalizzazione che le rende inappetibili ai Colossi. In queste personalissima classificazione appartengono alla prima categoria Oracle e EMC, mentre appartiene alla seconda categoria Juniper. Entrambi gli appartenenti a questa categoria potrebbero fare acquisizioni da un momento all’altro ma ad oggi hanno, nel modello di sicurezza unificata, più di due caselle rosse.

Esaminando la mappa delle acquisizioni dei colossi si può avere un quadro chiaro delle loro strategia: in rigoroso ordine alfabetico:


Punti di Forza: notevoli risorse e Ability to Execute, crescia esponenziale nella sicurezza di rete e dei contenuti.

Punti di debolezza: Gestione Frammentata, Strategia sull’Endpoint incerta, Offerta IAM Parziale


Punti di Forza: Disponibilità di Risorse per Acquisizioni. Presenza nell’Application Security con Soluzione Leader.

Punti di debolezza: Mancanza di copertura per l’Endpoint, copertura parziale nella sicurezza di rete (limitata all’IPS ma la strategia è incerta).


Punti di Forza: Dispnibilità di Risorse, Offerta completa su Sicurezza delle Applicazioni e su IAM.

Punti di debolezza: Offerta su Endpoint, Compliance e Rete Parziale (Mancano Antivirus, DLP, e soluzioni di Content Security.


Punti di Forza: Gestione Unificata Estesa, Offerta Completa

Punti di debolezza: Strategia Incerta e Fantascientifica dopo l’acquisizione di McAfee (Focalizzazione sul Mobile o Antivirus Hardware Integrato sul processore), Difficoltà nell’integrare le acquisizioni, Offerta IAM Assente, Offerta Application Security Limitata.




Punti di Forza: Risorse Notevoli, vasta base di installato (!!) da utilizzare come punto di partenza

Punti di debolezza: Funzioni parziali su tutti i domini (‘Antitrust?).


Noi balliamo da sole

Di seguito le aziende di sicurezza che maggiormente suscitano l’attenzione degli analisti e puntualmente sono al centro di voci di mercato: Checkpoint, Fortinet e Symantec. Questi player partono da approcci opposti (rispetttivamente rete per i primi due ed endpoint per il terzo) e potrebbero far gola ad uno dei player sopra indicati (come accaduto a McAfee) oppure ad un Outsider. Anche se non perfettamente partinente in questa categoria è stata inserita anche Juniper. In realtà è praticamente impossibile che Juniper venga acqquisita da un colosso, tuttavia, come capitalizzazione è più vicina a questi player (pur valendo circa 20 volte Fortinet) che hai colossi.


Punti di Forza: Forte focalizzazione sulla rete. Modello di gestione unificata Esemplare. Precursore del modello di unificazione della sicurezza unificata sull’endpoint.

Punti di Debolezza: Stenta a imporsi come venditore di soluzioni Endpoint. Carente su Application Security, Compliance e IAM.


Punti di Forza: Forte focalizzazione sulla sicurezza di rete e dei contenuti.

Punti di Debolezza: Copertura deole degli altri domini.


Punti di Forza: Forte focalizzazione sulla sicurezza di rete e dei contenuti.

Punti di Debolezza: Copertura debole degli altri domini.


Punti di Forza: Forte focalizzazione sull’endpoint.

Punti di Debolezza: Strategia e focalizzazione sulla sicurezza da ricostruire dopo l’acquisizione di Veritas. Strategia Altalenante per la sicurezza di rete.



E quindi?

E quindi vederemo se i fuochi di artificio sono finiti qui o continueranno nel corso del 2011. Certo è che soprattutto  HP, IBM e la stessa Microsoft necessitano di una o più acquisizioni per riempire il gap rispetto al modello unificato ideale (all’inizio di novembre si è parlato di un interessamento, in seguito smentito, di IBM verso Fortinet), tramite una unica acquisizione, come fatto da Intel con McAfee o facendo shopping tra i produttori di nicchia.

Ne resterà soltanto uno… (Prima Parte)

December 5, 2010 Leave a comment

Il titolo di questo post riporta alla memoria la frase prinicipale del bel film “Higlander, L’Ultimo Immortale”, il capolavoro fantasy di Russel Mulcahy che nell’ormai lontanto 1986 rapì la mente di noi geek adolescenti con i suoi improbabili duelli tra le montagne scozzesi, duelli avvolti tra la bruma e la bellissima colonna sonora dei Queen (Who wants to live forever?). Se ripenso al film e guardo il mercato della sicurezza informatica direi che la frase  essenza si adatta perfettamente alla situazione attuale, con la sola non trascurabile differenza che ai tempi di Connor MacLeod, non esisteva l’Antitrust.

All’inizio erano il firewall e l’antivirus…

L’inizio del mercato della sicurezza informatica (si parla del termine degli anni ’90) vedeva tecnologie con ruoli ben distinti, rivolte alla risoluzione di problemi di sicurezza inerenti alla rete ed ai sistemi. Esisteva un modello di sicurezza informatica basato su un approccio “a silo”, ovvero un approccio che prevedeva tecnologie verticali e trovava la massima espressione nel firewall e l’antivirus (a sua volta declinato in antivirus di rete e antivirus di sistema). In quegli anni formidabili, nel 99% dei casi un progetto di sicurezza informatica poteva dirsi completo se prevedeva queste due componenti che con il passare del tempo erano anche in grado di dialogare tra loro (oggi diremmo in modo non efficiente, ma allora i protocolli di content vectoring erano il massimo che la tecnologia poteva garantire). Certo la gestione non era ottimale, ma con l’ausililo della tecnologia consentita dall’epoca, si ponevano le basi per un modello unitario.

Poi vennero gli IDS…

E si realizzò ben presto che il firewall e l’antivirus non potevano tutto: all’interno delle regole consentite era possibile veicolare minacce invisibili in grado di sfruttare le vulnerabilità dei sistemi. Di conseguenza fu necessario innalzare il livello di protezione mediante l’inserimento di sistemi di difesa dedicati in grado di scansionare il traffico ad un livello superiore rispetto a quanto consentito dai firewall. Sorsero così i primi produttori dedicati ai sistemi IDS. Questi produttori utilizzavano la tecnologia nata per scansionare i sistemi alla ricerca di vulnerabilità per proteggere i sistemi stessi. Con questo approccio nel 1998 Internet Security Systems mise in commercio i primi sensori di rete, sensori che con il passare degli anni divennero apparati dedicati, sempre più evoluti, in grado di estendere il proprio livello di protezione verso l’endpoint (Host IPS). Nel contempo, e in modo del tutto analogo, i produttori di dispositivi firewall si apprestavano, anche essi, ad aggredire gli endpoint con soluzioni di Personal Firewall. Endpoint che prima di allora sembravano appannaggio esclusivo dei produttori di antivirus.

E le applicazioni inscure e magari anche mobili…

Nella seconda metà degli anni 2000, la crescita prepotente del Web 2.0 e l’evoluzione tecnologica dei dispositivi mobili (che hanno allargato notevolmente il livello di esposizione dell informazioni) hanno reso necessaria l’introduzione di un ulteriore livello di sicurezza per la protezione delle applicazioni (al livello 7 della pila OSI direbbero gli esperti) e dell’utenza mobile. Questa piccola rivoluzione copernicana ha portato all’introduzione di soluzioni tecnologiche atte a focalizzare l’analisi su applicazioni WEB, database, transazioni XML e soprattutto, più in generale, ad introdurre la sicurezza nel ciclo di sviluppo del Software e nel processo di accesso alle informazioni. Nel contempo si è cominciato a guardare con interesse a soluzioni di protezione dell’endpoint fissi e mobili più evolute, in grado di garantire cifratura, protezione dei dispositivi rimovibili e, specialmente negli ultimi tre anni, dedicate ad impedire la perdita o il furto di informazioni (Wikileaks docet).

E alla fine la necessità di avere una gestione unificata

La crescita del modello di sicurezza end-to-end ha reso infine necessaria l’introduzione di un modello di gestione unificata (qualcuno una volta diceva “La Potenza è nulla senza il controllo”) poiché gestire in modo disomogeneo (per l’appunto con un approccio “a silo”) le numerose componenti è costoso, inefficiente e inefficace (ed è altrettanto improbabile che giustifichi investimenti cospicui in tecnologia di sicurezza). E’ importante inoltre considerare il problema dell’analisi dei dati: soluzioni di protezione eterogenee non devono offrire solamente un unico punto di amministrazione, ma anche un unico punto di raccolta e analisi dei dati.

La conseguenza del trend sopra descritto è stata che nel corso degli anni si è assistito a numerose scosse di mercato: i produttori di sicurezza (generalisti o verticali) dotati di adeguate capacità finanziarie, hanno avviato importanti campagne di acquisizione  e/o fusione con lo scopo di realizzare il modello di sicurezza unificato sopra citato ed utilizzare lo stesso come base per altre strategie, estendendo nel contempo la propria sfera di azione su segmenti di mercato non precedentemente coperti. Naturalmente in alcuni casi le campagne di acquisizione sono state effettuate anche per garantire crescite  di fatturato in un epoca di congiuntura economica non certo esaltante  (ma questa è un altra storia).

La conseguenza, per quanto riguarda i produttori di sicurezza informatica, è stato uno sconvolgimento del panorama tecnologico ed economico da parte di tre forze contrastanti:

  • I produttori provenienti dalla “sicurezza di rete” si sono estesi verso l’endpoint (approccio network-centric). Per questa classe di produttori la sicurezza dell’endpoint rappresenta l’estensione del proprio modello strategico che parte dalla rete: questa rileva le minacce che vengono utilizzate per proteggere gli endpoint, il tutto effettuato tramite una gestione unificata.
  • I produttori provenienti dalla “sicurezza dell’endpoint” si sono estesi verso la rete (approccio endpoint-centric). Per questi produttori l’estensione alla rete rappresenta il mezzo per realizzare un modello unico di correlazione delle informazioni di sicurezza a partire dai dati raccolti nei nodi terminali (siano essi fissi o mobili, client o server).
  • I colossi produttori di hardware, software e servizi hanno si sono estesi verso la sicurezza per realizzare un modello unico di che parte dallo sviluppo del software e dall’accesso sicuro alle applicazioni, e si estende verso la rete e i sistemi per offire un modello end-to-end.

La descrizione dello scenario è estremamente complessa e merita un capitolo a parte, per cui, dopo aver elencato le ragioni, nel prossimo post cercherò di far luce sulla mappa delle acquisizioni e le mie personalissime considerazioni sulle relative strategie.

Nel frattempo però prendo il mio Androide e mi cerco un bel posto per il brunch…


Get every new post delivered to your Inbox.

Join 3,710 other followers