L’idea che del malware possa avere una firma valida sembra mettere in discussione il senso stesso della firma del software, e forse di altro. È vero solo in parte, ed è bene quindi inquadrare correttamente il problema, per evitare generalizzazioni eccessive.

I problemi sono essenzialmente:

1. Chi certifica le chiavi opera in un mercato con una concorrenza basata sostanzialmente solo sul costo: non ci sono certificati migliori o peggiori, ci sono solo certificati; a chi li utilizza i certificati interessano poco (vedi punto 2) e una maggiore sicurezza vuole dire procedure più complesse, ovvero una garanzia di perdere clienti, mentre le responsabilità davvero minime che ha in pratica un certificatore non sono una motivazione sufficiente per preoccuparsi della sicurezza;
2. Chi utilizza delle chiavi di certificazione del codice, come confermato anche dalla presentazione di cui sopra, le considera sostanzialmente una “seccatura” necessaria, una sorta di tassa, e quindi se da una parte è interessato soprattutto a pagarle poco, dall’altra ne cura poco la sicurezza; anche qui, non mi è ben chiaro quali siano le responsabilità in carico al titolare delle chiavi in caso di uso fraudolento delle chiavi da parte di terzi, ma sospetto che siano molto poche;
3. parlando di responsabilità, alla fine ce ne sono molto poche, e nei confronti dei soggetti sbagliati; è una caratteristica generale dell’uso dei certificati: chi effettivamente se ne deve fidare, cioè l’utente finale, è l’unico che non ha nessun rapporto contrattuale al quale rifarsi in caso di problemi, mentre gli altri soggetti per la maggior parte hanno interesse a che non si faccia mai troppo rumore; ad esempio, se viene emesso un certificato per una società inesistente, utilizzato per diffondere malware, chi ha titolo per chiedere un risarcimento dei danni?
4. se è discutibile che in alcune configurazioni un oggetto/programma firmato venga installato silenziosamente solo per il fatto di avere una firma valida, anche l’idea di far scegliere all’utente, in base a messaggi che sono criptici anche per molti informatici, è poco realistica;
5. più sono le aziende che hanno bisogno di chiavi per firmare il proprio codice, meno sarà utile la firma per distinguere quelle che producono programmi puliti da quelle che producono malware.

E in realtà i punti critici sono proprio gli ultimi: cosa garantisce effettivamente una firma Authenticode?  Permette al produttore del codice di inserire informazioni, e all’utente di verificare l’integrità del codice, prendendo, secondo questa pagina, “decisioni più informate”. Tuttavia, la faq dice chiaramente:

Should I trust and download a piece of software just because it’s been signed?

Again, this decision relies on the end user’s own judgment; however, the certificate provides end users with the data they need to make a more informed decision about this piece of software. If the end user has a great deal of trust in a particular software publisher, then the end user may decide to automatically download any software from this publisher through the settings provided in the Authenticode Security Technology dialog box.

Anzi, qui si dice chiaramente:”Likewise, an invalid signature does not prove that the software is dangerous, but just alerts the user to potential problems. ” Tutto giusto, naturalmente, ma dimostra ancora una volta come noi informatici pensiamo e scriviamo come se dovessimo avere a che fare con degli informatici, anche quando sappiamo benissimo che quello che produciamo andrà in mano ad utenti finali. Tutta questa faccenda dello “user’s own judgement” è molto pilatesca.
Diciamocelo chiaramente: l’unico caso in cui la decisione dell’utente è (o dovrebbe essere)  ovvia, è se trova del software di aziende note tipo Micrsosoft o Adobe; negli altri casi, il meccanismo aiuta poco o niente. Il problema è aggravato dal fatto che il “nome” a cui è associato il certificato può non essere così chiaro: la presentazione di cui sopra dice chiaramente che produttori di malware sono riusciti ad ottenere certificati per nomi molto simili a quelli di grosse aziende, abbastanza simili da ingannare certamente la maggior parte degli utenti. La situazione sembra decisamente peggiore di quella dei certificati per i siti web, dove almeno in condizioni normali l’associazione fra un qualsiasi sito e il suo certificato sarebbe verificabile (il nome è decisamente più univoco di quello di una società). In conclusione: la firma del codice è utile quando c’è un canale fidato (da Microsoft, da una distribuzione Linux, e possibilmente con un certificato verificato, non tramite CA) per verificare che il software arrivi in modo integro da quel canale, senza nessuna ulteriore garanzia. Dare un valore particolare al software firmato in quanto tale è sbagliato dal punto di vista teorico e pratico.

Per fortuna oggi tutti, compresa Microsoft, stanno sviluppando soluzioni a tutti i livelli (browser, s.o., macchine virtuali) che basano la sicurezza del codice scaricato da fonti incerte sulla segregazione e non sulla firma. Ma l’idea che quello che è firmato sia più sicuro anche quando non se ne conosce l’origine, resiste…

Negli ultimi anni la sicurezza delle reti SCADA è un tema piuttosto di moda: si è discusso molto di come i sistemi SCADA siano stati man mano connessi alle reti locali delle aziende e di qui ad Internet, e di come i sistemi di controllo siano sostanzialmente i soliti Windows, spesso non aggiornati e con applicativi fortemente insicuri (il worm utilizza una password che è “hard-coded” nel codice dell’applicazione e che è nota da anni). La sicurezza di questi sistemi è stata spesso basata sull’isolamento fisico, e questo isolamento se n’è andato senza che la sicurezza venisse adeguata.

Il punto che mi interessa però è la raccolta di informazioni: abbiamo un worm che non ha lo scopo di raccogliere password da utilizzare in modo semplice e immediato: il worm raccoglie informazioni che vanno poi vendute a clienti interessati. Se qualche anno fa abbiamo avuto l’evidenza dell’incontro fra il mondo dell’”hacking” (in senso negativo) e quello delle frodi, adesso abbiamo l’evidenza dell’incontro con quello dello spionaggio industriale, e ci possiamo aspettare un’evoluzione altrettanto rapida e decisa di questo rapporto.

È utile allora vedere la cosa dal punto di vista dell’Europa, e dell’Italia in particolare. Da noi, le PMI sono una componente importante dell’economia, e com’è noto hanno “grosse difficoltà” con la sicurezza informatica, anche perché spesso non ne sentono la necessità. Se però lasciamo la prospettiva della singola PMI, e guardiamo il settore nel suo complesso, abbiamo un settore importante per la nostra economia, in cui risiede una parte importante del know-how con cui dovremmo competere nel mercato globale, che è particolarmente vulnerabile allo spionaggio industriale. Potremmo magari credere che quando una PMI abbia qualcosa di valore curi di più la propria sicurezza, ma per quanto ho visto, le cose non stanno così: primo, una PMI può non riconoscere il valore che le informazioni nei propri sistemi possono avere, o la presenza stessa delle informazioni (ad esempio nei sistemi SCADA). Secondo, sempre che si renda conto della presenza e vulnerabilità di quelle informazioni, è probabile che affronti il problema chiedendo semplicemente qualche protezione in più a chi si occupa della manutenzione ordinaria dei sistemi. Le competenze di queste figure sono le più varie, non hanno una relazione con il valore delle informazioni trattate in azienda, e l’imprenditore del resto non è in grado di valutarle. Terzo, se anche provano a cercare un supporto specialistico, avranno difficoltà a trovare un’offerta adeguata, sia per i costi, sia perché le piccole aziende sono un numero enorme rispetto all’offerta di specialisti, sia perché per questi ultimi può non essere facile affrontare le particolarità di aziende fuori dai contesti in cui operano abitualmente.

Il risultato è che rischiamo seriamente di portarci dietro uno svantaggio competitivo dato dalla maggiore facilità con cui, statisticamente,  i paesi nostri concorrenti (ok, diciamo le loro aziende) potranno accedere al know-how delle nostre aziende. In questa prospettiva, è chiaro che non basta aspettare che le singole PMI si accorgano delle proprie esigenze di sicurezza e le affrontino, ma è necessario alzare il livello medio di sicurezza e soprattutto di consapevolezza dei rischi che, nei prossimi anni, saranno sempre più reali.

Infine, l’ultimo passaggio, quello più preoccupante: da un worm che permette di leggere una rete SCADA a un worm che permette di controllarla o manipolarla il passaggio è breve. Non dimentichiamo che le reti SCADA sono quelle che controllano non solo le fabbriche, ma anche le dighe, gli inceneritori, i semafori, i binari…

E sempre riguardo al “chiarire la situazione” , dato che ho sentito delle interpretazioni un po’ semplicistiche della sentenza relativa alla detenzione di programmi illecitamente copiati, la sentenza non dice assolutamente che è lecito installare programmi abusivamente copiati, anzi, sembra suggerire che il giudice di primo grado avrebbe potuto approfondire meglio questo aspetto. In effetti, si potrebbe dire (mio pensiero, non della Corte di Cassazione) che installare un programma senza licenza rientri nella fattispecie della copia abusiva, che la sentenza non indica assolutamente come attività lecita. È solo la detenzione, presumibilmente a seguito di un’installazione fatta da altri, che non è illecita. Sicuramente è questo il caso trattato dalla sentenza, e bisogna sempre ricordare che anche le sentenze della Cassazione si riferiscono sempre a casi specifici, e che l’estensione dell’interpretazione a situazioni “simili” può essere del tutto sbagliata (lo è in generale).

Update: per evitare di nuovo fraintendimenti, la sentenza dice che se c’è stato reato, il sito di indicizzazione contribuisce. Non dice, mi pare, che un sito di indicizzazione commetta un reato per il solo fatto di indicizzare (ovvero, aggiungo io: il reato da parte del sito di indicizzazione c’è se effettivamente è stato provato lo scambio di  materiale in violazione della norma, ma su questo la sentenza non si è espressa).

Ed a proposito di percezione sbagliata della crittografia, segnalo questo interessante algoritmo di voto. È molto bello dal punto di vista crittografico (ma non bisogna farsi ingannare dal post: “sorveglianza ovunque” non vuole dire che il singolo votante non possa preparare il proprio voto libero da pressioni e osservatori ). Tuttavia, questi algoritmi mostrano come questo tipo di ricerca, con le sue ipotesi così assolute sul contesto, la complessità (non in senso computazionale) dei protocolli  e  le capacità computazionali dei singoli attori, sia ancora ben lontana dall’offrire soluzioni praticabili. La percezione che si ha spesso della crittografia è invece che applicando qualche algoritmo crittografico alle comunicazioni in un sistema di voto tradizionale si risolva qualcosa.

Forse vale la pena di spiegare la questione della normativa CEE, che trovate commentata qui, nella quale mi ero già imbattuto occupandomi di firma elettronica in ambito europeo con il progetto R4eGov. Si tenga presente che non sono un giurista, quindi qualche termine o concetto può essere impreciso. Ogni paese può emanare delle normative tecniche il cui rispetto è obbligatorio per l’offerta di beni e servizi sul suo territorio.  Ad esempio, una caldaia deve rispettare determinati requisiti tecnici ed avere determinate certificazioni che ne garantiscono la sicurezza. Tuttavia i criteri tecnici possono essere una “scappatoia normativa” per far passare delle regole restrittive della libera circolazione delle merci e dei servizi: un paese potrebbe imporre che tutte le caldaie vendute  rispettino dei requisiti, magari di certificazione, che possono essere di fatto rispettati solo da prodotti di quel paese, magari perché incompatibili con quanto viene fatto in tutti gli altri paesi. Per evitare questo rischio, le normative tecniche devono essere preventivamente sottoposte all’UE, che può anche eventualmente bloccarle. Per il contrassegno SIAE, a quanto pare questo non è stato fatto, e si potrebbe quindi ipotizzare che tale obbligo  sia restrittivo della circolazione delle merci e dei servizi. Conseguentemente, le norme che vi fanno riferimento non possono essere fatte valere.

Invece, credo che la cosa si possa vedere da un punto di vista diverso: se servono meno amministratori per gestire dei server virtuali, rispetto ai corrispondenti server fisici, allora sono meno le persone di cui è necessario fidarsi, e diminuisce quindi la probabilità che, magari per mancanza di scelte migliori, uno di questi sia propenso a copiarsi i dati .

Thanks! I have been looking for this info all day now.
My pc is not running like it should and I need to figure out how
to fix it soon. I have bookmarked your post so others can find it too on reddit.

Stavo per approvarlo, poi mi sono voluto togliere la curiosità di vedere cosa aveva trovato di utile in quel post, ed ho visto che:

• il mio post è interamente in italiano, il commento è in inglese
• nel mio post non ci sono indicazioni relative a trucchi, patch o codice che possano essere “leggibili” anche in un’altra lingua
• il mio post però cita i nomi di diversi prodotti della “categoria” degli antivirus

Noto allora che il commento è estremamente generico e si adatterebbe a qualsiasi post. Vedo allora che l’autore, con un nome inglese,  indica come proprio sito web un sito che parla, già nel nome, di “spyware removal”. Visito il sito, che è altrettanto generico del commento, composto di tre o quattro pagine ch e parlano di un “prodotto” scaricabile per disinstallare spyware. Di questo prodotto, o di link per scaricarlo però non c’è traccia.

A questo punto, faccio una scommessa: secondo me, l’autore cerca di inserire a tappeto riferimenti al proprio sito su blog che parlino di antivirus e antispyware, in modo da raccogliere link, “autorevolezza” e ranking nei motori di ricerca. Poi, aggiungerà al proprio sito i link per scaricare il suo tool, che sarà invece uno spyware.

Io intanto tengo lì il commento da approvare, come promemoria: ogni tanto andrò a verificare. Se mi sono sbagliato e l’autore legge questo post (in italiano ), mi scriva pure per dirmi che mi sbaglio

Quando un anno fa Lycos Europe ha improvvisamente chiuso, non ho scelto Network Solutions per la sua qualità, anzi: dato che da sempre il dominio telmon.org è registrato da loro, sospettavo che potessero esserci problemi, anche se non così gravi. Mi è capitato spesso di ricevere da mailing list messaggi come questo:

Hi. This is the qmail-send program at xxxx.net.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

<xxxx@telmon.org>:
Sorry, I couldn't find any host by that name. (#4.1.2)
I'm not going to try again; this message has been in the queue too long.

che sono un indicazione di irraggiungibilità/malfunzionamento del nameserver di telmon.org. Certamente mi sarò perso anche qualche messaggio da singoli corrispondenti, oltre che da mailing list. E dire che la posta elettronica dovrebbe essere uno dei servizi di base più resilienti ed affidabili che ci siano…

Tuttavia, a gennaio non avevo molto tempo per cercare un provider che mi convincesse di più, ed in fondo anche altri provider potrebbero avere ogni tanto lo stesso problema. Adesso il tempo l’ho dovuto trovare, perché un altro anno con Network Solutions non lo avrei sopportato. Del provider attuale avevo già sentito parlare bene, ma non avevo avuto tempo di valutarlo. Adesso, appena completato il trasferimento,  spero che le cose vadano meglio. Se doveste notare dei malfunzionamenti, vi prego di farmeli presenti. Grazie.

Purtroppo non posso provare l’attacco sul mio router ADSL perché non è configurato per fare affidamento sul NAT   (inizialmente sembrava che l’attacco funzionasse, ma in realtà stava funzionando un altro tipo di rimappatura, legittima).

Il problema è, in poche parole, che i moduli che implementano il NAT per i protocolli con contrattazione dinamica delle porte devono interpretare il protocollo applicativo e rimappare le porte di cui è stata richiesta l’apertura dal client sulla rete protetta: in qualche caso, ad esempio per l’ftp “attivo”, anche connessioni entranti. Tuttavia, questi moduli sono “minimali”, non capiscono l’intero protocollo: nel caso specifico, non capiscono se il traffico verso la porta 6667 è effettivamente traffico irc o è http: tutto quello che fanno è “intercettare” una stringa corrispondente, in irc, ad un comando che richiede l’apertura di una porta, e rimappano di conseguenza, aprendo un canale verso l’interno.

L’attacco dimostra dicevo, un principio importante: il NAT non è un meccanismo di sicurezza. Tutto quello che viene di sicurezza viene per caso e non in modo affidabile, e comunque non è molto. L’altra cosa dimostrata dall’attacco è il problema di “indovinare” il protocollo in base alla porta destinataria: vale per il NAT ma anche per i meccanismi di proxy trasparenti.

Infine, dimostra che da un firewall non bisogna aspettarsi più di quanto esplicitamente dichiarato: se il prodotto dichiara di permettere il funzionamento di irc attraverso il NAT, non è legittimo dedurne che impedirà connessioni entranti. È vero che qui stiamo parlando di prodotti molto di base, ma il principio di non ipotizzare per un firewall capacità oltre a quelle esplicitamente dichiarate vale in generale, particolarmente quando si tratta di interpretare protocolli applicativi.