Quest’estate un post ha particolarmente attirato la mia attenzione. Sottolinea come sia possibile trovare del malware firmato digitalmente in un modo assolutamente legittimo. L’articolo è uscito quando si stava parlando anche dell’inizio dell’effettivo deployment di DNSSEC, che è basato principalmente sulla firma dei record DNS, di PEC e di non ricordo quale altra iniziativa anch’essa riconducibile alla firma elettronica. Vale soprattutto la pena di leggere la presentazione a cui il post si ispira. È da notare che la presentazione identifica alcune strade per firmare il malware che per quanto percorribili, non sembra siano ancora state sfruttate. Un esempio è il furto di chiavi Authenticode, cosa che non risulta ancora ai ricercatori, ma che le cattive pratiche di aziende che utilizzano queste chiavi sembrano rendere possibili.
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:
- 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;
- 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;
- 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?
- 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;
- 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…
E senza lasciare tracce!