Il taccuino di Armando Leotta Rotating Header Image

vulnerabilità

OWASP Top 10 -2010

Logo OWASP

Logo OWASP

Open Web Application Security Project (OWASP) ha rilasciato la TOP 10 per il 2010 ovvero le 10 vulnerabilità più critiche delle applicazioni web.

La lista, rilasciata in licenza Creative Commons Attribution ShareAlike 3.0 e scaricabile da sito owasptop10, si prefigge lo scopo di sensibilizzare amministratori, sviluppatori, architetti, manager ed organizzazioni sull’importanza delle conseguenze di uno sviluppo non accorto delle applicazioni web. La top 10 vuole essere una sintesi, uno spunto di riflessione nella speranza che possa portare consapevolmente verso lo sviluppo sicuro del codice.

Ecco la lista 2010 in sintesi:

  • A1 – Injection
  • A2 – Cross-site Scripting (XSS)
  • A3 – Broken authentication and session management
  • A4 – Insicure direct object references
  • A5 – Cross-site request forgery (CSRF)
  • A6 – Security misconfiguration (new)
  • A7 – Insecure cryptographic storage
  • A8 – Failure to restrict URL access
  • A9 – Insufficient transport layer protection
  • A10 – Unvalidated redirects and forwards (new)

Significativa la tabella comparativa con la precedente lista:

Tabella comparativa OWASP TOP 10 2007-2010

Tabella comparativa OWASP TOP 10 2007-2010 (fonte OWASP)

Nel documento trovate delle schede di dettaglio per ciascuna vulnerabilità. Inoltre, a ciascuna di esse è stato associato un fattore di rischio basato su statistiche ed esperienze OWASP.

Questa di seguito è la mappatura che ne deriva:

Top 10 risk factor summary

Top 10 risk factor summary (fonte OWASP)

Quanto espresso sopra va calato nel proprio contesto aziendale e nel più ampio processo di gestione del rischio.

Molte PA stanno inserendo nei vari capitolati di gara l’obbligo del rispetto della top 10 di owasp come baseline minima.

Vi segnalo inoltre il chapter italiano di OWASP.

Microsoft ad aprile snocciola 11 bollettini per 25 vulnerabilità

Bollettini di Aprile: sono 11 e sanano ben 25 vulnerabilità.

Il Microsoft Security Response Center, pur caldeggiando l’installazione di tutte le patch rilasciate, ha indicato MS10-019, MS10-026, e MS10-027 come top priority ed ha anche suggerito un ordine con cui applicarle (deployment priority).

April 2010 Deployment Priority (via MSRC)

April 2010 Deployment Priority (via MSRC)

Nei link sopra indicati potrete trovare tutte le informazioni ed i dettagli tecnici per aggiornare il vostro sistema microsoft e valutare gli impatti e la severità di ciascuna vulnerabilità.

Una considerazione di carattere organizzativo.

25 vulnerabilità in un mese che vanno dal client SMB al server Exchange, da una vulnerabilità su file avi a quelle su pagine web opportunamente create, sono una quantità enorme. Non parlo dell’utente privato che potrebbe persino sentirsi tutelato e coccolato da tanta attenzione. Mi riferisco ad una struttura aziendale che ha un parco macchine omogeneo, che sostiene dei costi per tenere in esercizio tutte le postazioni ad un determinato livello di sicurezza. E ancora, parlo di realtà enterprise in cui il deployment di una patch è solo il mero risultato di uno sforzo di mesi di verifiche formali e strumentali da parte di una struttura di laboratorio che controlla, testa e certifica le modifiche software da installare in esercizio.

In questo scenario di patch management ed ambienti d’esercizio, bollettini come questi di aprile sono devastanti da un punto di vista organizzativo e, conseguentemente, di processi, di sla da rispettare e di produttività da mantenere.

E’ realmente inevitabile questo flusso continuo di aggiornamenti su aggiornamenti? E’ realmente la soluzione più efficace ed efficiente? Che scontiamo ancora le logiche time to market?

O semplicemente sono l’unico a porsi certe domande?

Attacco Aurora ancora in corso e indagini ad una svolta. Ecco come funziona il malware

Aurora attackL’attacco in larga scala che ha colpito grandi aziende come Google e Adobe non cessa di fare danni e di far parlare di sè.  L’operazione Aurora (è questo il nome con cui McAfee ha denominato l’ondata di targeted attacks in questione) coinvolge molte più aziende delle poche decine stimate inizialmente.

Dmitri Alperovitch, vice presidente del threat research in McAfee, afferma di non essersi mai imbattuto in un attacco così sofisticato ai danni di aziende commerciali.

Esperti di computer forensic hanno identificato la Cina come provenienza dell’attacco ma stanno focalizzando le loro indagini sul malware utilizzato per sfruttare le varie vulnerabilità.

Di estremo interesse il threat report “Operation Aurora” pubblicato da HBGary, davvero ben fatto, dettagliato e completo per capire come funziona il malware, rilevarlo ed eliminarlo dalla propria azienda.

Mancano, volutamente, il dettaglio delle tracce lasciate dall’autore del malware che, a detta  di Greg Hoglund, fondatore e CEO  di HBGary, sono svariate, specifiche e tali da ricondurre presto all’identificazione di chi ha compilato e predisposto il malware.

Cyber Espionage: prendiamo familiarità con questo termine.

____
Clusit

Microsoft e sicurezza: ossimoro?

Senso di sicurezza avvertito dagli utenti Microsoft

Ancora non si fermano le polemiche sulle vulnerabilità di IE, sul ruolo che sembra aver ricoperto nel braccio di ferro Google Vs Cina.

Dapprima era confermata solo per IE6, poi è stato reso noto un Proof of Concept per IE7 tanto da spingere Microsoft ad ipotizzare un rilascio straordinario (out of band).

Mentre in Italia fonti ufficiali (SPC CERT) e auterevoli confermano che al momento IE8 è immune da questa vulnerabilità, Francia (CERTA) e Germania (BSI) consigliano di utilizzare un browser alternativo.

A questo scenario già abbastanza confuso e critico, si aggiunge il full disclosure di Tavis Ormandy, security engineer presso Google.

Per mantenere il supporto legacy per le applicazioni 16-bit, dal 1993 tutti i sistemi Microsoft si portano dietro questa vulnerabilità.

La cosa interessante è che la stessa Microsoft, a detta dello scopritore della vulnerabilità, fu informata il 12 giugno 2009 la quale confermò la ricezione 10 giorni dopo.

Nessuna patch o workaround ufficiale. Un silenzio che ha portato l’autore alla pubblicazione della vulnerabilità.

Curioso tempismo o meno resta un momentaccio per gli utenti microsoft.

_____
Clusit

La chiave privata di PayPal? Pubblica!

Man in the middle - fonte OWASP -

Man in the middle - fonte OWASP -

Dopo alcuni mesi (Moxie Marlinspike e Dan Kaminsky, Defcon e Blackhat) si riparla di una vulnerabilità alle implementazioni SSL (API crittografiche) che, di fatto, prestano il fianco ad un attacco di tipo man in the middle nonchè a tecniche di phishing.

Perchè se ne riparla dopo poco più di due mesi? E’ proprio di questi giorni la pubblicazione di un certificato (e chiave privata) attribuito a PayPal carpita proprio grazie alla vulnerabilità descritta da Moxie Marlinspike al BlackHat USA nel luglio di quest’anno (vedi video dell’intervento al defcon 17).

Frutto di tecniche di parsing datate e usate nelle librerie crittografiche dei client che implementano e usano lo strato SSL (per cui non solo browser web ma anche client di posta, instant messaging, client irc,VPN SSL, etc) e di tool appositi (sslsniff).

In particolare, questa vulnerabilità sfrutta la struttura del certificato X.509 del certificato e le informazioni in esso contenute usandole a proprio piacimento in quel procedimento di validazione a cascata della fiducia.

La catena di fiducia tra il sito interessato e la Certification Authority (CA) funziona come descritto sotto

Root CA -> Intermediate CA -> Intermediate CA -> .. -> Intermediate CA -> esempio.com

Cosa dovrebbe avvenire:

  1. verifica che il nome del nodo foglia è lo stesso del sito a cui ci si sta collegando
  2. verifica che il certificato è valido, non è scaduto, revocato, etc
  3. Controllo della firma (signature)
  4. Se tale firma della CA appartiene alla nostra lista di una Root CA trusted il processo di conclude positivamente altrimenti si ripetono nuovamente gli step dopo aver risalito la catena di un livello.

Questo è lo scenario incriminato:

Root CA -> Intermediate CA -> Intermediate CA -> .. ->Intermediate CA -> sitomalevolo.com -> esempio.com

Purtroppo, questo scenario, nelle condizioni di vulnerabilità indicate nel paper di Marlinspike al Blackhat di Las Vegas, sembra essere del tutto lecito: le firme sono validate, i certificati non sono scaduti/revocati, il procedimento indicato di verifica si conclude con una Root CA trusted “embedded” incorporata nel browser.

Questo significa però che abbiamo costruito un certificato VALIDO per esempio.com ma che in nessun modo rappresentiamo in quanto siamo legati a sitomalevolo.com

Affinchè questo funzioni, viene sfruttata la debolezza di una codifica del CN (Common Name) Subject del PKCS #10 in cui il campo (stringa) viene “chiuso” da un particolare valore null (\0).

Quando viene effettuato il controllo 1), in questo scenario vengono confrontate due stringhe di lunghezza potenzialmente diversa.

Tenendo conto che la stringa si conclude con il carattere \0, il parsing considera solamente i primi n caratteri fino al valore null (\0).

Quindi se in un certificato X509 è specificato di essere www.esempio.com\0sitomalevolo.com le verifiche vengono effettate sulla precedente stringa (fino al campo \0) e l’indirizzo a cui vogliamo collegarci (www.esempio.com).
A questo punto si hanno tutti gli elementi per effettuare un MITM che generi il certificato apposito e si interponga trasparentemente tra le parti (molte CA rilasciano dei certificati se il richiedente è l’owner specificato DOPO il valore null).

Per quanto riguarda Mozilla, i security advisor riportano di avere chiuso la falla a partire dalla versione di firefox 3.5 e 3.0.13 (vedi variante attacco su 3.0.11 vulnerabile), Thunderbird dalla 2.0.0.23, SeaMonkey dalla 1.1.18 e NSS dalla 3.12.3

Al momento sembra che le crypto API di windows siano vulnerabili.

Ci sono ripercussioni e impatti anche nel campo delle applicazioni mobile.

PayPal ha nel frattempo sospeso l’account di Moxie Marlinspike.

Raccomandazioni: massima attenzione sulle transazioni in https e scrivere manualmente il link sul browser (possibilmente firefox, aggiornato) e mai fidarsi di link specialmente contenute in messaggi di posta elettronica.

****************UPDATE*********************

Meglio tardi che mai http://www.microsoft.com/technet/security/bulletin/ms09-056.mspx