ISA-TMG ISAWPLB: COSA RAPPRESENTA? QUANDO VIENE UTILIZZATO? PUO CAUSARE POTENZIALI VULNERABILITA’?

Ciao a tutti,

Recentemente mi è capitato di gestire diverse richieste di supporto in cui mi si chiedevano delucidazioni in merito alle funzionalità del cookie ISAWPLB, rilasciato ai client in seguito a richieste di connessione a siti pubblicati attraverso reverse-proxy ISA/TMG.

Nello specifico, la preoccupazione maggiore risiede nel fatto che tale cookie non sia marcato come “sicuro” qualora se ne vadano ad esplorare le proprietà:

Ma partiamo dalle basi: cos’è realmente il cookie ISAWPLB?

ISAWPLB è un cookie che viene rilasciato da proxy quali ISA o TMG nel momento in cui la sessione in oggetto riguardi una regola di pubblicazione configurata per effettuare web-farm load-balancing.

Il Web-farm load-balancing è la configurazione grazie alla quale ISA/TMG bilancia il traffico in ingresso su due o più nodi interni,ovviamente contenenti il medesimo sito pubblicato.

Questo tipo di load-balancing rappresenta quindi un’alternativa “built-in” ad altri metodi quali HLB/NLB/DNS-RR, ed a tutti gli effetti il metodo piu corretto di balancing attraverso questi reverse-proxies.

Quando il meccanismo di balancing della Farm è configurato come “cookie-based”, per poter tener mappata la sessione di un client su uno soltanto dei nodi interni, il reverse proxy assegna al client un cookie specifico, perlappunto l’ISAWPLB.

Ma il fatto che questo cookie non sia marcato come sicuro rappresenta quindi un problema?

La risposta a questa domanda è: allo stato dell’arte, non abbiamo riscontrato alcun tipo di vulnerabilità legata a tale cookie, pur non essendo esso marcato come “sicuro”.

Il motivo è semplice: ISAWPLB non è un vero e proprio cookie di sessione.

ISAWPLB è strutturato in questo modo:

ISAWPLB{3983BFA5-2E80-4F79-8283-F3276BF70CB2}={0B4939A9-6C1D-4093-987D-275EDC6E83F5}

Il primo GUID è legato alla regola di pubblicazione che viene matchata sul ISA/TMG, mentre il secondo fornisce un riferimento in merito a quale server della farm interna debba essere considerato per l’inoltro della richiesta.

Esso non contiene alcuna informazione in merito all’identità del chiamante, nè alcun token di accesso in grado di bypassare i meccanismi di autenticazione.

Un cookie non marcato come sicuro può potenzialmente essere intercettato e/o modificato da codice malevolo, e allo stesso tempo può essere utilizzato dal browser su connessioni non sicure (HTTP), con tutti i rischi del caso.

Ma cosa succederebbe se ISAWPLB venisse “sniffato” da un MITM ?

Contenendo esso solamente informazioni relative al bilanciamento di sessione del reverse proxy, la risposta a questa domanda è: nulla.

Qualora il reverse-proxy sia configurato in modo da esigere pre-autenticazione per l’accesso ad un determinato sito pubblicato, la sola presenza di ISAWPLB nell’header di una richiesta non sarà sufficiente per farla passare internamente, in quanto al MITM viene comunque a mancare il vero e proprio cookie di sessione rilasciato in seguito all’avvenuta autenticazione dello user da parte del proxy stesso.

Tale cookie (il vero cookie di sessione) è – oviamente – sicuro.

Ad oggi, quindi, non abbiamo riscontrato necessità di modificare le proprietà del ISAWPLB, in quanto esso non rappresenta un punto di debolezza dal punto di vista della security.

Ciao a tutti e alla prossima!!

Daniele Gaiulli - MS Support Engineer