Si sta diffondendo molto rapidamente Cryptolocker, un virus della categoria denominata ransomware (vedi spiegazione), che giunge normalmente come allegato di mail e che cripta i file del pc infetto ma anche delle cartelle di rete a cui i pc infetto è connesso, chiedendovi poi un riscatto in denaro per avere i vostri dati indietro. Attualmente non ci sono soluzioni certe, l’unica software house di antivirus che ha fatto qualcosa per porre un rimedio è Kasperky (link al tool), anche se le varianti del virus sono molteplici e lo strumento messo a disposizioni da Kasperky funziona solo per alcune ma non per tutte. I dati si possono ovviamente recuperare da Backup, per quelli più attenti e prudenti, sperando che il virus non abbia infettato anche i dischi dove viene fatto il backup !!

La soluzione alla disperata, sempre più frequente, è di pagare (mediante bitcoin: la moneta della rete anonima).  Pagare non significa però avere la certezza di riottenere i propri dati perché non sempre la chiave che viene fornita è valida: può essere scaduta oppure il link da cui scaricarla non essere più valido perché il server su cui era stata caricata è sparito o è stato messo nella blacklist da qualche polizia. Per capire meglio di cosa si tratta leggete questi due articoli di cronaca:

Allerta Polizia Postale

Avvocatessa di Treviso

In quest’ultimo articolo la malcapitata ha aperto la mail proveniente da un collega con scritto ALLEGATO URGENTE.  Il fatto che la mail con virus giungesse da un indirizzo mail di un collega, per cui non sospetta, è perché il virus ha infettato il pc del collega. Quando il virus si attiva, oltre a criptare files, per diffondersi, spedisce anche mail prendendo gli indirizzi ad esempio da outlook. Un’altro esempio di mail che potreste ricevere è questo:

In questo secondo caso è da osservare che non viene scritto il proprio Nome e Cognome nel saluto ma la mail esordisce con un impersonale Buondì. Un’altra regola principe, che non vale solo per Cryptolocker, è  non aprire allegati di mail che esordiscono con un saluto generico. Se si tratta di mail di banche, enti o istituzioni, queste, in genere, esordiscono sempre con un saluto personale per cui vedrete il vostro nome e/o anche il cognome.

Come difendersi quindi ? Semplicemente adottando delle regole nell’apertura degli allegati, che in generale valgono per tutti i virus, cryptlocker compreso. Ecco le mie indicazioni:

NON aprite DIRETTAMENTI gli ALLEGATI a mail anche se provengono da persone “fidate” ma salvateli su una cartella e poi con il tasto destro fate scansione con l’antivirus del file specifico. Se vi dà minaccia cancellatelo e svuotate il cestino. In più in via precauzionale consiglio, per chi usa Outlook, e ricordando un bug del passato, di togliere l’anteprima dei messaggi mail.

Ecco il breve tutorial che mostra i vari passaggi da seguire in pratica e applicare costantemente:

1. Salvataggio allegato in una cartella (NON SUL DESKTOP createvi una cartella in Documenti e nominatela AllegatiMail)

2. Scansione del singolo file con Antivirus nel caso l’antivirus segnali una qualsiasi minaccia eliminarla.

3. Togliete l’anteprima dei messaggi In Outlook

In questi giorni mi sono occupato di ottimizzare le performance di alcuni siti che ho realizzato in ASP.NET MVC. Mi ero già preoccupato di minificare e combinare insieme tutti i fogli di stile e i javascript inclusi nelle pagine. A seguito, però, di una verifica con l’estensione PageSpeed della web developer di Chrome mi sono reso conto che IIS, anche se non per tutti i siti, non effettuava la compressione Gzip dei css e js come si può evincere dal questo snapshot: nel response header della richiesta http per un file css non compariva l’intestazione Content Enconding: gzip che speravo di trovare e che avrebbe evidenziato il comportamento voluto da parte di IIS

.

Ho iniziato quindi a ricercare una possibile soluzione e googlando un po’ ho trovato qualcuno che suggeriva di inserire questa sezione nel Web.config dell’applicazione

Purtroppo però questa soluzione non va bene in medium trust, in quanto questa sezione del Web.config può essere inserita solo se si hanno i permessi e così non è in medium trust. Se si tenta di farlo viene generata una eccezione HTTP Error 500.19 – Internal Server Error quando IIS è in funzionamento .NET 4 e Integrated Pipiline. Ho quindi inizialmente contattato l’assistenza di Aruba aprendo un ticket e, dopo una dettagliata descrizione del problema, mi hanno così risposto:

“Gentile cliente,
le confermo che sui nostri server di hosting non è possibile utilizzare la compressione degli url. E’ necessario mantenere commentata tale riga di codice per  il corretto funzionamento del sito.”

Ho cercato allora di aggirare l’ostacolo e trovare una soluzione alternativa pensando che fosse possibile effettuare la compressione a livello di applicazione creando un modulo HTTP Handler. Mi sono messo alla ricerca nel web e ho trovato diverse possibili soluzioni. Nessuna andava bene, se applicata alla lettera, ma dopo diversi tentativi,  ne ho ricavata una mia arrivando al risultato sperato. Ho creato questo HTTPHandler:

Ad ogni richiesta HTTP che arriva all’applicazione controlla che nel Request Header ci sia nel “Accept-Encoding” la parola gzip e in quel
caso effettua la compressione dell’URL relativo. Fatto questo ho inserito le seguenti sezioni nel Web.config:

e ho verificato con web developer di Chrome che tutto funzionasse: