Qualche mese fa è stato divulgato attraverso un articolo su Panorama (numero 26, di giugno 2008) una recente indagine sulla firma digitale, che scopre una vulnerabilità del meccanismo utilizzato per generare e verificare i documenti firmati. Tale risultato è stato originariamente presentato nell’articolo A new Attack on Digital Segnature , autori Francesco Buccafurri, Gianluca Caminiti, e Gianluca Lax (Università di Reggio Calabria), apparso negli atti della “IEEE International Conference on the Applications of Digital Information and Web Technologies” (Agosto 2008). Sul sito www.unirc.it/firma possono essere trovate ulteriori notizie a riguardo.
Punto Informatico ha a suo tempo ripreso la notizia, attraverso un articolo di Diego Zanga, dal titolo: Firma digitale falsificata? È solo falsa la notizia . Svariati siti, successivamente, hanno riportato l’articolo di Zanga, che è quindi divenuto molto diffuso nel Web.
L’articolo tuttavia offre un quadro inesatto circa la natura del risultato, che, non per spirito polemico, ma solo per correttezza scientifica, ritengo opportuno correggere. Ciò soprattutto perché la descrizione di Zanga mortifica il valore del risultato scientifico e non chiarisce quale sia il problema che è stato affrontato.
Ma andiamo per ordine, descrivendo dapprima brevemente il risultato.
L’attacco, assolutamente mai documentato prima (inspiegabilmente Zanga nel suo articolo usa l’affermazione “anziano exploit” e si riferisce a presunti precedenti risultati sloveni di cui però nessuno ha traccia) si basa sulla considerazione che l’utente che firma un documento ne conosce il contenuto sulla base di ciò che è visualizzato sullo schermo del PC. Ovviamente, il documento (cioè il file) sottoposto a firma consiste dei bit di cui è composto, ma il significato del documento – che dipende dal modo con cui il documento è mostrato al sottoscrittore – dipende dal software usato per la sua decodifica. Quindi le informazioni che riguardano il tipo del documento (che dipende direttamente dal modo con cui le informazioni incluse nel documento sono codificate e, conseguentemente, dal formato del file e dal software capace di gestirlo) non sono prese in considerazione durante il processo di firma, e quindi non sono in nessun modo incluse nella busta crittografica.
Ad esempio consideriamo un utente che firma un file “contratto.bmp”. Dopo l’applicazione della firma digitale a questo file verrà generata la busta crittografica in formato PKCS#7 che sarà salvata con nome contratto.bmp.p7m, perché il software di firma aggiunge l’ulteriore estensione.p7m al nome iniziale del file. Se l’utente estrae il documento dalla busta crittografica, il nome del file firmato è ottenuto da quello della busta dopo la rimozione della seconda estensione (.p7m), visto che l’informazione relativa al nome del file non è memorizzata nella busta. Di conseguenza il software di verifica non può rilevare una eventuale modifica fatta al nome del file. Nel caso in cui il file contratto.bmp.p7m sia (per errore o volontariamente) rinominato, ad esempio in contratto.htm.p7m, la procedura di verifica della firma ha ancora successo, ed il file è estratto e rinominato in contratto.htm.
L’indipendenza della firma dal nome del file non è stata ritenuta mai una debolezza, in quanto relativamente al legame tra documento e firma, quest’ultima deve essere connessa solo ai bit contenuti nel documento. Ciò potrebbe non sembrare un rischio per la robustezza della firma digitale in quanto è prevedibile che una sequenza di bit significativa in un certo formato non lo è in un altro. Ad esempio, nel caso precedente, i bit del file contratto.bmp interpretati in formato HTML non producono alcun significativo risultato.
Alla base dell’attacco vi è la (palese) falsità di questa assunzione. Infatti, ovviamente, una prefissata sequenza di bit potrebbe essere interpretabile in formati differenti producendo contenuti molto diversi.
Vediamo come è realizzato l’attacco sul file bitmap considerato prima, supponendo che esso rappresenti il testo I . Con un editor esadecimale modifichiamo alcuni byte inserendo il tag HTML per l’apertura di commento ( <!–) (un commento ignorato dall'interprete HTML). Quindi creiamo un opportuno file HTML che include un testo T (il testo voluto dall’attacker). Inseriamo all’inizio del file HTML il tag HTML di chiusura di commento ( –>). Infine accodiamo il file HTML al file modificato dell’immagine. Il file risultante è visualizzato correttamente da un visualizzatore bitmap che mostra l’immagine I . Cambiando l’estensione da.bmp a.htm, il file verrà aperto dal browser che mostrerà il testo T anziché il testo I . Ciò avviene su qualsiasi Sistema Operativo che riconosce il tipo di file attraverso l’estensione, come Microsoft Windows, Linux/KDE, MacOsX, etc.
È da notare che l’approccio utilizzato è abbastanza generale. Infatti questa procedura di attacco è stata realizzata e testata, dagli autori del lavoro, con gli opportuni adattamenti, anche su altri formati quali.pdf,.tif,.ps,.rtf,.doc. È da notare che anche il formato.tif, ampiamente utilizzato nella conservazione sostitutiva, e suggerito come formato sicuro, può essere oggetto dell’attacco in questione. Si noti infatti che in generale i formati immagine sono considerati sicuri, in quanto non possono avere comportamenti dinamici derivanti dalla esecuzione di istruzioni (come invece accade per molti formati usati per i testi – primo fra tutti Word, che può includere macroistruzioni).
Cosa succede se Tizio firma il documento contratto.bmp e produce la busta crittografica con nome contratto.bmp.p7m? Poiché la firma è stata correttamente generata ed il documento non è stato alterato, il processo di verifica della firma ha ovviamente successo.
A questo punto si completa l’attacco semplicemente modificando il nome della busta crittografica da contratto.bmp.p7m a contratto.htm.p7m. Poiché la verifica della firma è fatta sulla base dei bit contenuti nella busta crittografica, che non contiene il nome del file, il cambio del nome del file non modifica l’esito della verifica. Infatti, la verifica effettuata sulla busta rinominata ha successo.
Ma cosa succede quando viene chiesto al software di verifica della firma di visualizzare il documento firmato? Se il sistema operativo riconosce il tipo di file sulla base dell’estensione, verrà automaticamente invocato il browser, in quanto il nome del documento “estratto” dalla busta è contratto.htm. Di conseguenza verrà visualizzato il testo T e non il testo I originariamente firmato da Tizio. Non siamo quindi di fronte ad una falsificazione di firma ma ad una alterazione di documento, quindi ad una tecnica che consente di realizzare falsificazioni di documenti informatici con una tecnica discretamente insidiosa. Si tenga conto anche del fatto che non è possibile stabilire quale dei due contenuti sia stato presentato all’utente all’atto dell’apposizione della firma. Pertanto tale tecnica potrebbe essere utilizzata anche per precostituire un ripudio.
Ribadiamo che l’attacco ha successo su qualsiasi Sistema Operativo che riconosce il tipo di file attraverso l’estensione, come Microsoft Windows, Linux/KDE, MacOsX, etc.
Cosa viene invece erroneamente affermato nell’articolo di Punto Informatico di Diego Zanga? Che il bug evidenziato “è di Windows”. Cioè che il problema non riguarda la firma ma “il visualizzatore di Windows”. E che Microsoft dovrebbe “correggere Windows”. Poi si riferisce anche ad un non meglio identificato “software di verifica made in USA” che sarebbe responsabile della vulnerabilità in quanto non compliant con la normativa europea (leggere per credere).
In realtà, invece, l’attacco è stato testato con software europei, in particolare con il software ufficiale del CNIPA oltre che con software di verifica di certificatori accreditati.
Per quanto riguarda invece le affermazioni che riguardano il Sistema Operativo, come visto prima, l’attacco ha successo non solo su Windows (che per altro è il più diffuso SO per PC al mondo), ma anche con altri Sistemi Operativi come Linux/KDE, free BSD/KDE e MacOSX. In secondo luogo l’attacco “sfrutta” una caratteristica comune a molti Sistemi Operativi (in quelli Unix-like la cosa dipende dal window manager) – e non certo una debolezza del visualizzatore – per la quale il tipo di file viene riconosciuto attraverso l’estensione. Di per sé essa non è ritenuta una vulnerabilità né in contesto scientifico né in contesto commerciale. Non si può quindi affermare che ciò che documentiamo nel lavoro sia una vulnerabilità dei Sistemi Operativi (men che meno solo di Windows).
Infatti un sistema software è sicuro se non è possibile sfruttare sue debolezze intrinseche o sfruttare caratteristiche dell’ambiente in cui è eseguito per determinarne un comportamento malicious.
La vulnerabilità che abbiamo rilevato riguarda il sistema di firma (non certo gli algoritmi e gli hash utilizzati – cosa che non è mai stata affermata dagli autori del lavoro), in quanto sfruttando le (lecite) caratteristiche dei Sistemi Operativi (l’ambiente in cui è eseguito) è possibile determinare un comportamento malicious.
Per convincersi di questo è sufficiente considerare la seguente metafora. Se il 90% delle strade del mondo presenta dossi (o buche), e viene progettata un’autovettura che appena incontra un dosso esplode, e per evitare questo sarebbe sufficiente una minima modifica nel progetto dell’autovettura, il problema riguarda la strada o l’autovettura? La risposta è immediata. Le strade, nella metafora, sono i SO su cui sono elaborati i documenti. Quelli su cui ha successo l’attacco coprono forse più del 90% dei PC in uso. L’autovettura è il sistema di firma. Che si intende non soltanto gli algoritmi, ma il modo con cui li usiamo. Perciò busta, software di generazione e verifica, etc.
Cioè ciò che rende diversa la teoria dalla pratica, che alla fine è quella che riguarda tutti.
Francesco Buccafurri
F.B è Ordinario di Sistemi di Elaborazione delle Informazioni presso l’Università Mediterranea di Reggio Calabria
Ti potrebbe interessare
10 set 2008