… e solo del 1981! Ma andiamo con ordine.

Qualche giorno fa, il (comatoso) mondo dei firewall è stato scosso dai risultati di un’analisi degli NSS Labs su un gruppo di prodotti recenti.

La storia in realtà è iniziata l’anno scorso, quando due ricercatori di Breaking Point hanno pubblicato un paper in cui, analizzando alcuni apparati, avevano scoperto che utilizzando una tecnica particolare di TCP handshake i firewall si comportavano in maniera strana.

Quei furbacchioni (in senso positivo ovviamente) di NSS hanno pensato bene di inserire questo tipo di test all’interno dei loro report periodici, e hanno scoperto che di questi prodotti analizzati:

•     Check Point Power-1 11065
•     Cisco ASA 5585
•     Fortinet Fortigate 3950
•     Juniper SRX 5800
•     Palo Alto Networks PA-4020
•     SonicWALL NSA E8500

Soltanto uno comprendeva correttamente l’handshake e lo rifiutava, gli altri erano potenzialmente a rischio. Ma, sarebbe da chiedersi, a rischio perché?

Il problema nasce dal fatto che l’RFC prevede, invece che un classico handshake in tre fasi (SYN-SYN/ACK-ACK) uno a quattro fasi, così composto:

    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

Iniziare una sessione in questo modo è assolutamente lecito, ma di fatto mai implementato nella realtà. Cosa succede quindi ad un firewall se ha a che fare con questo tipo di handshake? Succede che, come scoperto da NSS, il firewall si “confonde” sullo stato della sessione, e comincia a comportarsi in modo stateless. Questo potrebbe portare il firewall a non applicare i controlli di sicurezza e a non controllare il flusso della sessione. Per esempio un potenziale attaccante potrebbe, una volta fatto collegare ad un proprio server un client di una rete aziendale, eseguire questo attacco e invertire il senso della connessione, avendo potenzialmente accesso alla rete del client. Gli scenari possibili sono facili da prevedere poi…

Vorrei premettere una cosa però, questo tipo di test vale per il solo prodotto firewall, se c’è di mezzo anche un IPS, reale o funzionalità che sia, un handshake a quattro fasi viene bloccato come attacco… a meno che l’IPS non sia in grado di capire il verso della connessione. Molti apparati di intrusion prevention infatti bloccano le possibili minacce analizzando il verso (da fuori a dentro ad esempio). Qualora un attaccante riuscisse, tramite handshake a quattro fasi a confondere il firewall e ad invertire il verso, sarebbe possibile evadere i controlli e inviare il proprio payload a destinazione.

Tornando all’industria, NSS ha pubblicato subito un bel remediation report ma, ovviamente, nel frattempo è successo un casino.

Tutti i produttori si sono sbrigati a dire che o sono immuni (però con quel settaggio…. però con quella funzionalità…) o che ci stanno lavorando: Fortinet, Palo Alto (che dice che l’hanno passato mentre NSS dice che rilasceranno una patch.. mah), SonicWALL e anche StoneSoft, che non era tra quelli testati da NSS per vari motivi… di Juniper ho trovato poco.

In particolare vorrei segnalare che il PSIRT di Cisco ha dimostrato anche qui serietà e prontezza, come nel caso AntiEvasion. Hanno infatti dichiarato che analizzando nel laboratorio la questione non sono riusciti a riprodurla, qui il loro bollettino. Devo fare i complimenti per la chiarezza e la trasparenza.

In conclusione è stato un piccolo fuoco in un settore dell’industria infosec ormai comatoso appunto, perché c’è poco da fare ormai sul prodotto firewall. Lasciando perdere le sparate next/new-gen che sanno molto di marketing e poco di innovazione reale.

Chissà, forse per innovare bisogna tornarsi a leggere le RFC, visto che questo problema, di fatto, non è nemmeno una vulnerabilità!

Per avere ulteriori spiegazioni sul topic vi rimando all’ottimo articolo di Paolo Passeri sul suo blog, e all’analisi di Breaking Point che in effetti spinge a riflettere sul modo in cui vengono testati i firewall, forse troppo lontani dalla realtà. Ulteriori articoli interessanti sono anche quelli di WatchGuard, che suggerisce di farsi da se il test con lo script riportato nella ricerca, e di Technicolor.

Bye!

P.S.: se non avete capito chi sia stato l’unico a passare il test ve lo dico io: Check Point. Per gli addetti al troubleshooting non penso ci sia da stupirsi, visto quanto FW-1 rompe le scatole con il TCP-out-of-state…