Ancora sull’Application Security : SSL è superato dalle specifiche WS-* ??

Artikel
06/22/2009

Non credevo di suscitare tanto interesse con questo mio precedente post :-) ma ne sono contento perchè questo conferma una buona sensibilità verso l’application security.

Ho ricevuto molte email riguardo l’uso di SSL alcune delle quali mi chiedevano se tale protocollo è da considerarsi ancora sicuro. Vedo di sintetizzare un po’ di miei pensieri… sperando di continuare il dibattito :-)

**SSL è superato dal WS-*?**

Assolutamente NO... e ci mancherebbe altro! Sono due mattoni importanti per la messa in sicurezza di un sistema. Sono complementari anche se hanno molte "funzionalità" in comune. Infatti, in alcuni contesti devono essere utilizzati obbligatoriamente entrambi, come ad esempio durante lo scambio di un UsernameToken definito dalla specifica WS-Security:

<xsd:element name="UsernameToken">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="Username"/>
<xsd:element ref="Password" minOccurs="0"/>
</xsd:sequence>
<xsd:attribute name="Id" type="xsd:ID"/>
<xsd:anyAttribute namespace="##other"/>
</xsd:complexType>
</xsd:element>

Infatti, in questo caso durante lo scambio del token il network si deve fare carico dell’encryption del canale! Volendo schematizzare le affinità e le differenze tra l’uso di SSL e lo stack WS-*:

Affinità:

- Entrambi garantiscono Autenticazione, Integrità e riservatezza sebbene lo stack WS-* tramite XMLENC e XMLDSIG sia molto più espressivo.

- E’ sempre il sistemista che interviene sulle configurazioni del server per SSL come può intervenire sulle policy del servizio per modificare le caratteristiche dei messaggi SOAP (+ o -).

Differenze:

molte! Prima di tutto WS-* prevede il supporto a SOAP mentre SSL no, WS-* NON è applicabile in tutti i contesti di Web-Applications invece SSL si.

SSL è implementato al livello 5 della famosa pila mentre i WS-* sono in quello definito “nuovo layer 8”. Questo comporta alcune considerazioni di sicurezza importanti..prima tra tutte che il livello 4 (TCP) e 5 da un punto di vista di sicurezza si occupano solamente del mittente. Non è una cosa da poco. Si pensi agli scenari SOA e SaaS. SSL è semplicemente un canale cifrato tra due end-point e non è possibile estendere il conteso di cifratura ad altri server (intermediari) creando possibili “vulnerabilità” nel flusso dei dati. Il contesto di sicurezza dell’applicazione NON è la sommatoria dei singoli contesti. WS-Security & family, al contrario spostando le informazioni di sicurezza direttamente all’interno dell’header del messaggio SOAP, consente di avere un numero arbitrario di intermediari e di protocolli di rete anche non sicuri garantendo però il contesto di sicurezza dell’applicazione.

SSL è un protocollo“state-full” ovvero deve mantenere uno “stato” tra il client e il server; il client instaura una connessione con un determinato server e il suo flusso non può essere deviato ad altri server (l’handshake tra il client e il server ha lo scopo di scambiarsi delle chiavi simmetriche – tramite delle chiavi asimmetriche - che entrambi utilizzano per cifrare il canale) perchè non sono in possesso delle corrette chiavi simmetriche per decifrare i dati. In questo scenario è indispensabile ricorrere ad un intervento sistemistico impostando i valori di “affinity” che associano un client sempre allo stesso server riducendo notevolmente la scalabilità applicativa. Al contrario WS-Security, basando interamente la propria struttura a livello del messaggio può usufruire di scelte infrastrutturali più scalabili.

Se ci spostiamo su WS-SecureConversation, lo scenario cambia nuovamente, ritorniamo alla necessità di avere una chiave simmetrica condivisa, o meglio, un contesto di sicurezza condiviso (SCT- Security Context Token).Per risolvere la ridondanza dei servizi si hanno 3 opzioni:

1) Sistemistico tramite affinity proprio come SSL.

2) Misto:tramite un database di SCT condiviso da tutti i server bilanciati.

3) Applicativo, estendendo lo schema del SCT. (possibili problemi di compatibilità con terze parti o comunque con software non aware del nuovo schema)

Considerazioni su SSL

SSL è un ottimo protocollo crittografico ma per quanto riguarda la sicurezza (non la crittografia) siamo ben lontani !! Innanzitutto il meccanismo di protezione non è efficace per quegli utenti “distratti” che non vanno a verificare TUTTE LE VOLTE l’URL nel browser con l’indirizzo specificato nel certificato. Inoltre, il famoso warning di incongruenza di dati del certificato viene sempre ignorato (= OK) permettendo, se va male, l’attacchi basato su ip-spoofing,ecc... E’ anche vera una riflessioncina : a prescindere da tutto, se un amministratore di un sito gestisce così il protocollo SSL c’è da chiedersi come gestisca l’intero sistema ...Mah..

A questo proposito a partire da Windows Vista è stato introdotto il supporto agli Extended Validation SSL Certificates https://www.microsoft.com/windows/ev. Sicuramente utile ma prima di tutto devono essere adottatti largamente dai gestori dei siti!!!!

SSL fonda la sua sicurezza pesantemente sulla robustezza dei cifrari asimmetrici e simmetrici utilizzati (come anche WS-*), cambia spesso la chiave di sessione (5min di default) e mitiga il reply tramite il Connect_id.

A questo punto volendo schematizzare i pro e i contro nell’ uso di SSL :

*SSL PRO*	*SSL CONTRO*
Standard	Dispendioso per la CPU
Autenticazione, integrità e riservatezza	Session oriented
Nessun vincolo di linguaggi di programmazione	Implementazione solo su HTTP (non per motivi tecnici o di specifica).
Nessun vincolo di pattern di sicurezza applicativa	Valido solo su singolo hop
“Gratis” per chi disegna ed implementa le applicazioni.	Non assicura i dati una volta arrivati al server.
	NON ESONERA GLI SVILUPPATORI DALLO SCRIVERE CODICE SICURO J

Attacchi e Contromisure

Di SSL ormai si sa (quasi) tutto. Gli attacchi principali al protocollo SSL sono noti mentre per lo stack WS-* se ne conoscono ancora relativamente pochi.

Per quanto riguarda SSL l’ultimo in ordine di tempo è l’ attacco basato sul BVO(Bad-version Oracle) . (nulla a che vedere con il famoso produttore di Database :-) )

SSL/TLS utilizza l’encoding PKCS#1 (v1.5) per l’encryption del pre-master-secret (valore utilizzato per la derivazione delle session keys).Un hacker che riesce a recuperare il premaster-secret può decifrare l’intera sessione SSL.L’attacco principale è una derivazione dell’attacco di Bleichenbacher per il PKCS#1.Parte dal presupposto che il meccanismo di versioning del PKCS#1 permette di creare un side-channel che permetta di invertire l’encryption recuperando il premaster-secret e/o firmarndosi come server!Questo attacco riesce entro le 54 ore con chiavi asimmetriche a 1024.

Inoltre, se si dispone di proxy server sarebbe consigliato configurare l’analisi dei primi passi del traffico dell’handshake di SSL per evitare che venga fatto del tunneling di un protocollo non autorizzato su una porta aperta (443 di default).

Per quanto riguarda le contromisure agli attacchi a SOAP/WS-* siamo messi (forse) peggio! Già durante la WPC 2007 ho presentato un sunto di vari attacchi a partire da SOAP fino alle specifiche più complesse come WS-Security e spero a breve di riuscire a sintetizzarli in uno o più post !! In questo articolo prendiamo in esame uno degli aspetti più importanti di WS-Security : la dipendenza da XMLENC e XMLDISG ( per sapere come sono fatti leggete qui e qui ). Infatti da alcuni anni orami sono noti vari attacchi di tipo DoS a queste strutture. L’attacco verte sulla funzione di verifica/decrypt dei dati. Ad esempio in XMLDSIG l’elemento Reference raccoglie l’informazione da firmare. Lo schema di Reference :

mostra chiaramente che il contenuto da firmare non è il documento stesso, ma bensi l’hash del documento (DigestMethod e DigestValue) più le informazioni di rappresentazione.

Poichè il processo di verifica della firma prevede il ricalcolo dell’hash dell’oggetto firmato, cosa succede se l’URI del Reference indica ad esempio il SP1 di Windows 2003 ?? Il Thread di IIS che sta processando il codice applicativo si scarica 315 Mb per poter calcolare l’hash... moltiplichiamo la richiesta n volte e, etvoilà...HABEMUS DoS Attack...

Contromisure? Beh, applicative e di content analisys da parte dei firewall. In alcuni contesti è possibile implementare alcuni pattern di sicurezza come il Message Validator oppure dedicare uno o più Perimeter Service Router applicativi.

In sintesi le contromisure per gli attacchi a SSL sono di competenza dei sistemisti :-) mentre quelli a livello applicativo spesso sono distribuiti tra sistemisti e architetti/sviluppatori.

E’ però importante sottolineare che per quanto riguarda la messa in sicurezza di una applicazione l’uso di SSL o WS-* non significa NULLA o quasi. Gli attacchi applicativi tipo Buffer Overrun, SQL-Injection, XSS, Code-inj.,Canonicalization attacks, Ecc... avvengono ne più ne meno...perchè il 95% di codesti attacchi è riconducibile ad un unico antipattern tipico di chi sviluppa : (mancanza) di INPUT VALIDATION !!!!

Qunidi, alla domanda più ricorrente che ci sia in questo ambito :”quando una applicazione può esserer considerata (più) sicura? non posso che rispondere in questo modo : quando è stata sviluppata seguendo il processo di SDL fin dal principio :-)

--Mario

PS : Se volete saperne di più sulla sicurezza applicativa, da cosa è composta e come dovrebbe essere affrontata leggete questo mio post dal titolo : Perchè la sicurezza applicativa è così ostica ?

Comments

Anonymous
June 23, 2009
Ciao Mario, Nel caso di UsernameToken può essere utilizzato anche il meccanismo del digest. In questo caso (almeno il profilo) prevede l'utilizzo di un "nonce" e quindi l'uso di SSL non diventa così indispensabile. Certo il MITM è sempre possibile... L'unica cosa che mi disturba di SSL è la negoziazione della chiave di sessione che la prima volta richiede un tempo non indifferente. Se poi consideriamo che non è una navigazione Web ma la richesta di un servizio... Cosa ne pensi in merito?
Anonymous
June 29, 2009
CIao Roberto, Il nonce è opzionale nella specifica e alcune implementazioni di differenti vendor trattano diversamente le impostazioni di default. Personalmente se si tratta di due endpoint e non ci sono instradamenti tramite soap-routers preferisco abilitare SSL (se possibile) perchè aiuta a mitigare il MITM e mi rende più confidente rispetto agli aspetti di operation. In effetti la negoziazione della chiave di sessione è l'aspetto più oneroso del protocollo. Da quanto vedo anche nelle successive specifiche dei Web Services la cosa non migliora (anzi!) come ad esempio in WS-SecureConversation dove la negoziazione avviene tramite protocollo SOAP !! Purtroppo è un pegno da pagare se non si vuole avere dell'hardare dedicato (e costono) al supporto di SSL. --Mario

Freigeben über