Il taccuino di Armando Leotta Rotating Header Image

Microsoft

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?

Hijacked account GMail, Hotmail, Yahoo! e Aol: malware, nuovo incidente o …

Era ottobre quando tutti i media riportavano la notizia della violazione di migliaia di account hotmail, gmail, aol e yahoo.

Microsoft dal canto suo aveva riportato di avere oltre 10.000 account compromessi tra msn.com, live.com e hotmail.com a causa di uno schema di phishing andato a buon fine per poi chiudere ufficialmente l’incidente (il perchè di tanto spam pubblicato nei commenti di quel post la dice lunga sull’attenzione posta sull’argomento).

Fin qui è storia già vissuta. Ma cosa c’è di nuovo allora?

Ho avuto modo di visionare stamattina una mail di gmail insolita: una risposta automatica, una sorta di “Out of Office” che l’utente non aveva mai settato.

Controllo la veridicità della mail: confermo il mittente google.com.

Verifico insieme all’utente le impostazioni e noto che vi è un inoltro automatico con oggetto:

Dear Friend:

e con corpo del messaggio di risposta automatica:

Dear Friend:
     Hey, what are you doing lately? I’d like to present to you a very good company that I knew.
     Its home page company: 
www.Elc-sky.com
     If you have any needs, please contact the company Email.
    They can offer all kinds of electronic products that you need, such as motorcycles, laptops, mobile phones, digial cameras, , x box, ps3, GPS, MP3 / 4, etc. Please take time to look at that there must be something you’d like to purchase.
Hope you have a good state of mind in buying your company!
Regards

E’ evidente che è stata manipolata l’impostazione dell’account: magari un malware.

Google è mio amico e scopro che il messaggio è solo una variante di tanti altri tipo

Hello
How are you doing recently?
I would like to introduce you a very good company which i knew. Their
website is   www.cnamake.com  They can offer
you all kinds of electronical products which you need,like Laptops ,GPS ,TV
LCD,Cell Phones,PS3,MP3/4,Motorcycles etc……..
Please take some time to have a check ,there must be something you ‘d like
to purchase .
Their contact E-mail: cnamake@188.com
Hope you have a good mood in shopping from their company !
Best Regards!!!

e altri ancora.

Quello che lascia pensare è questa testimonianza  di qualche settimana fa e questa risposta (vedi in basso “Last resolved a question on 31 Jan 31 2010“): stesso messaggio identico su piattaforma Microsoft.

Chi è tra i contatti di un account hijacked riceve una mail del tipo descritto sopra (e se hai un blog e pubblichi via mail…).

Tutte le evidenze sono di settimane o di pochi giorni fa: quest’ ultima porta la data di ieri.

Al momento non so se si tratta di qualche malware locale scritto per violare più piattaforme.

Personalmente ritengo credibile anche l’utilizzo tramite botnet e scansione massiva di quanto carpito mesi fa.

Ad ogni modo consiglio, nel dubbio, di verificare le impostazioni delle risposte automatiche del vostro account di posta gmail, hotmail, yahoo o aol che sia e di non aprire allegati apparentemente innocui pervenuti da sconosciuti o non richiesti (verificate sempre il mittente prima).

Stay tuned per gli aggiornamenti.

_____
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

Securitytool: ma anche no!

securitytoolSecuritytool? No, massima attenzione.

Fonti nazionali ed internazionali hanno rilevato una nuova ondata di una nuova variante di malware identificato con questo nome.

Essendo una variante non tutti i sistemi antivirus riescono ad identificarlo ed a proteggere la postazione.

Ancora una volta viene proposta tramite popup del browser web (o a seguito di aggiornamenti di codec video appositamente modificati) una scansione gratuita, fake, del vostro computer.

A questo punto verrà presentata una finta rilevazione che genererà risultati artefatti e la richiesta di acquisto di un tool di rimozione.

Ignorare ovviamente i messaggi di questo tipo.

Attenzione alle varianti non sempre rilevati dagli antivirus.

McAfee, ad esempio, al momento rileva solo alcune versioni (5833) (FakeAlert) mentre il prossimo DAT (5836) dovrebbe assicurare il detect (ed il remove) dell’ultima variante in circolazione.

Il comportamento è particolarmente invasivo per il PC vittima, ne rallenta le prestazioni e crea n file eseguibili sulla macchina impedendone in alcuni casi anche la gestione remota, utile negli scenari enterprise.

Massima cautela quindi, ed aggiornate prima possibile i DAT del vostro antivirus.

Per l’elenco degli eseguibili creati noti ad oggi…

(altro…)

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