Sarà ancora colpa di Turing?

Punto Informatico riporta una notizia simpaticissima, ossia un “attacco” un po’ farlocco alla firma digitale…

Pagina 2, “Il bug? E’ di Windows”:

L’attacco si basa sulla creazione di un file ad hoc che contiene sia un documento html sia una bitmap: i due file sono “accodati”, in un unico file. La bitmap è inserita nel commento di un file HTML, quindi non viene visualizzata se l’estensione del file è HTML, come è previsto per i tutti commenti. Al contrario se l’estensione è BMP, viene visualizzata solo la bitmap all’inizio del file e non il testo html contenuto in fondo al file.

Una veloce verifica di Punto Informatico ha appurato che il visualizzatore standard di altri OS, mostra i documenti in base al contenuto e questo fa sì che usando il file truffaldino su Linux venga mostrato sempre lo stesso contenuto, cioè la parte BMP, indipendentemente dall’estensione del file, rendendo inefficace la truffa.

Bene, ovviamente questo ha provocato una serie di commenti a raffica contro il male personificato, cioè windows. Naturalmente, giusto per decidere se per una volta PI ci aveva imbroccato, ho fatto anche io l’esperimento. Io non dico nulla, lascio che siano le immagini a parlare. Partiamo dal file rinominato come BMP:

Poi vediamo con il file html e Firefox cosa succede (ricordiamo che con FF “il contenuto viene visualizzato correttamente”):

E vediamo come si comporta FF aprendo il file rinominato come bmp:

A me le cifre sembrano diverse.

Ma, direte voi, hai usato la beta, FF di su, e questo di giù… Ok, facciamo la prova anche con Konqueror:

Update: nei commenti mi si dice che l’articolo dice che il “bug” funziona solo con ff. Vediamo come tratta konqueror il BMP:

Io mi chiedo solo con che coraggio vengono fatte certe affermazioni.
Ma si sa… la colpa è sempre di Turing.

-Miauz!

Tag Technorati: , , , ,

Pubblicato il giugno 26, 2008 su Informatica, Linux, Sicurezza, Software, Windows. Aggiungi ai preferiti il collegamento . 13 commenti.

  1. NON si verifica su SO centos…

  2. firefox adesso è un OS.
    ovvio.

    vai a pelar patate, vai.

  3. Strano, mi pareva che sull’articolo io avessi scritto che a mezzo browser il problema si presenta giusto con Firefox😦

    Anzi non strano, nell’articolo c’e’ proprio scritto🙂
    E’ a pagina due, proprio quando si parla di windows (non e’ nascosto chissa dove).

    “Pare che il trucco funzioni se il file viene visualizzato a mezzo Firefox, perchè lì l’identificazione del tipo di file è fornita dal server che lo invia al browser.”

    In effetti dovrebbe funzionare con OGNI broswer.

    Come spiegazione e’ un po spiccia, ma mi pare che tu l’abbia applicata: il problema e’ che la casistica sulle varie tipologie di file e’ un po piu’ lunga, che permettono di appliacre il trucco, pare un po lunga, e forse la sintesi che ho fatto e’ poco chiara😛

    Ritenta sarai piu’ fortunato.

    NB
    pensa che culo che ho🙂 oggi ho ricevuto una mail di tutt’altro avviso sullo stesso problema:
    “e’ inutile dire che su *nix non e’ un problema e lo e’ solo su windows, perche’ lo sanno gia’ tutti” …

  4. E’ OVVIO che non è un problema legato alla firma.
    Chi ha tempo.. potrebbe indagare il comportamento dei vari visualizzatori su SO diversi.

    Il punto è che HA voluto dare enfasi all’articolo (www.unirc.it/firma) come se ci fosse una intriseca debolezza della firma. E NON E’ COSI’.

    Tra l’altro il Presidente CNIPA ha di molto ridimensinato la cosa: http://www.cnipa.gov.it/HTML/rs/Lettera%20FP_PANORAMA_firma%20digitale_25giu08.pdf

    ALLA VANITA’ NON C’E’ MAI FINE….

    vedi pure l’ottimo articolo di Giustozzi http://www.interlex.it/docdigit/corrado39.htm

  5. @centos:
    Purtroppo non posso verificare la cosa per qualsiasi os.

    @naarani:
    ho appena editato. Potrai notare che il suddetto bug si verifica anche con konqueror. E vorrei pregarti di notare che la proof of concept dell’articolo chiede di scaricare il file e di visualizzarlo dopo averlo rinominato, quindi non vedo cosa possa c’entrare il server. Quanto alla discussione, il problema è che il trucchetto funziona anche sui sistemi linux, nonostante tu dica il contrario. Forse non su tutte le distribuzioni, ma almeno su una si. Inoltre dipende dalle impostazioni di sistema. Per essere chiari quella virtual machine su cui ho fatto la prova ha le impostazoini di base. Può darsi che potrò essere più fortunato la prossima volta, fatto sta che attualmente a me risulta che il tuo articolo citi una immunità che non c’è.

    @trolltech:
    Suppongo che tu da bravo troll non ti sia reso conto che le immagini si riferiscono ad un sistema linux. E che il mio articolo contestava il fatto che solo su windows esistesse il problema con la visualizzazione in base all’estensione.

    Infine, grazie per i link a centos.

  6. Magari l’onere di verificare il comportamento spettava proprio agli ingegneri di Reggio Calabria !!!

    MI chiedo (ma conosco già la risposta) come si possa pensare a chiamare “scientifico” un “articolo” del genere.

    Il punto è che il VANESIO continua a rilasciare interviste …

  7. Beh, la proof of concept di per sè, sebbene non fosse nulla di innovativo, ha un suo interesse in casi di eventuali tentativi di phishing.

    Ovviamente, un documento così artefatto è facilmente impugnabile, specie in caso di firma digitale, però è carino. In effetti è un caso, nemmeno troppo complesso, di steganografia. E ci sono modi decisamente più efficaci di farlo, ma è carino per fare qualche scherzetto🙂

  8. Francesco Buccafurri

    Intervengo in questa divertente discussione riportando
    alcuno chiarimenti inclusi
    nel sito
    http://www.unirc.it/firma

    dove molti dei dubbi emersi anche nei precedenti commenti
    penso possano essere chiariti.
    A “centos” dico che l'”ottimo” articolo del Sig. Giustozzi è pieno di affermazioni tecnicamente e scientificamente false come DIMOSTRATO nella mi replica che sono stati
    per cosi’ dire costretti a pubblicare e che si puo’ trovare pure
    sul nostro sito.

    Il discorso della steganografia (che è certamente accostabile)mi pare non applicabile al caso della firma. L’estrazione dell’informazione nascosta mediante steganografia deve essere fatta con tecniche ad-hoc, per cui questa informazione non puo’ mai essere imputata al firmatario.

    Blackstorm mi sembra che abbia detto una sacrosanta verità sulla scarsa qualità dell’articolo di Punto Informatico.

    L’errore più grossolano di quell’articolo è quello che associa la vulnerabilità ad un presunto “problema” di Windows.
    Il fatto che un tipo di file venga riconosciuto in Windows dall’estensione
    puo’ piacere o non piacere ma di per se’ non è una vulnerabilità. L’altro punto non trascurabile è che l’attacco funziona alla prefezione anche su Linux/KDE, BSD/KDE, MacOSX. Quindi NON E’ un problema di windows. Non so cosa intende il tal Lavarra con “file diversi”. L’attacco puo’ essere realizzato su diversi formati oltre BMP, come PDF, RTF, Postscript. Stiamo testando altri formati.
    Quindi si tratta di un attacco al sistema di firma digitale, e non una debolezza dei sistemi operativi.
    Sul sito http://www.unirc.it/firma, vi sono ampie argomentazioni a supporto che possono aiutare a comprendere la problematica.
    Diego Zanga (autore dell’articolo di PI) , attraverso comunicazione personale, dopo i miei
    ripetuti commenti, ha alla fine fatto ammenda dicendo
    che le verifiche fatte erano state molto superficiali,
    e che lui aveva confuso il problema da noi segnalato
    con un problema di windows sul quale stava lavorando.
    Ha ammesso quindi di avere preso un granchio.
    Questo granchio gira per la rete e nei blog
    che replicano queste affernmazioni totalmente infondate
    senza il minimo spirito critico.

    Seguono alcuni chiarimenti in forma di risposta alle obiezioni mosse nei riguardi dell’attacco

    1. Obiezione: “Il bug non è della firma ma è di Windows”

    (repetita iuvant)
    Innanzi tutto l’attacco ha successo non solo su Windows (che è il più diffuso SO per PC al mondo), ma anche con altri SO come Linux/KDE, free BSD/KDE e MacOSX. In secondo luogo l’attacco infatti “sfrutta” una caratteristica comune a molti SO (in quelli Unix-like la cosa dipende dal window manager) 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 SO (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, in quanto sfruttando le (lecite) caratteristiche dei Sistemi Operativi (l’ambiente in cui è eseguito) è possibile determinare un comportamento malicious.

    E’ interessante considerare la seguente metafora:

    Se il 99.99% 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 che ho elencato sopra 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, sw di generazione e verifica, etc.

    Cioè ciò che rende diversa la teoria dalla pratica, che alla fine è quella che riguarda tutti.

    2. Obiezione: “La firma digitale non è stata falsificata”

    In senso tecnico la firma non viene falsificata con questo attacco. Possono però essere realizzati dei documenti informatici “falsi”, cioè alterati. Non abbiamo mai affermato nella nostra ricerca che abbiamo falsificato la firma digitale, cioè che la debolezza individuata riguardi gli algoritmi di firma (hash inclusi) .
    Tuttavia essa è una debolezza degli strumenti di firma compliant alla normativa europea (nella quasi totalità). E’ un problema di rilevanza pratica perché l’attacco riesce, e questo è indiscutibile.

    3. Obiezione: “Questo attacco è noto da tempo”

    Fino ad Aprile 2008, e cioè fino al momento in cui il lavoro è stato messo a disposizione del CNIPA e inviato a conferenza, non risulta alcuna documentazione che dimostri tale affermazione.

    4. Obiezione: “Questo attacco è identico a quello basato su istruzioni incluse nei documenti (detti non–statici) già noto dal 1999”

    Certamente no. Quel tipo di attacco, che opera per esempio sui file di Word attraverso le macro-istruzioni, comporta la modifica di ciò che viene presentato all’utente, in funzione della modifica di variabili esterne (per es., la data del sistema). Quell’attacco è ben noto e ampiamente documentato, vi è anche letteratura scientifica circa le strategie di contrasto. Tuttavia, sebbene gli effetti di questo attacco siano simili a quelli del nostro, quest’ultimo agisce attraverso una tecnica profondamente diversa, in quanto nel documento compromesso è presente solo html con comportamento totalmente statico, compliant anche con la normativa europea più stringente (che è quella Slovena).

    Infatti, nel documento sloveno “Specifying the content and formal specifications of document formats for QES” è richiesto per l’HTML:
    “A document in HTML and XHTML shall contain only static objects and all necessary document components shall be directly in HTML and XHTML document, i.e. it shall not contain references on external resources that might change visualization. HTML and XHTML shall not contain other document types than defined in [19] and pictures which visualization is not unambiguous, i.e. animations and pictures with used lossy (irreversible) compression.”.
    Inoltre la normative tecnica Europea più stringente rispetto alle minacce basate sulla presenza di codice nei documenti è il documento CWA 14170:2004, che, prevede come “Security Requirement” “An SDP capable to make the signer sign only a static document format”.
    Il nostro attacco agisce anche su formati totalmente statici. Quindi anche se formalmente l’HTML incluso nel BMP del nostro attacco può essere denotato come “codice” presente nel documento, essendo esso STATICO, non riguarda le minacce fino ad oggi note.
    Che i due attacchi siano profondamente differenti dal punto di vista della modalità di funzionamento lo si comprende anche dal fatto che la nostra soluzione (inclusione di nome + estensione) negli “authenticated attributes” della busta PKCS#7, che è risolutiva nel nostro caso, non è efficace per gli attacchi basati sulla presenza di codice. Viceversa, la disattivazione dai formati che lo consentono dei meccanismi che prevedono l’inclusione di istruzioni al fine di dare al documento un comportamento dinamico (es. disattivazione delle macro di Word, javascript in pdf o html, etc.), lascerebbe inalterata la possibilità di condurre a termine con successo il nostro attacco.
    Una implicazione pratica di quanto detto prima è che, rispetto al rischio derivante dalla presenza di codice nei documenti, fino ad oggi nessuno avrebbe reputato pericoloso un documento sottoposto a firma di tipo bitmap (che, di fatto, non può avere contenuti dinamici, non ha riferimenti a risorse esterne, animazioni e immagini con compressione lossy), visualizzabile correttamente con un viewer di immagini. D’altra parte i formati immagine e i formati txt sono stati considerati gli unici totalmente esenti dal rischio di comportamento dinamico fino ad oggi.

    5. Obiezione: “Il livello di pericolosità è trascurabile”

    Non direi trascurabile, anche se sicuramente non è alto. Tutto dipende dall’uso della firma, dalla quantità di documenti firmati gestiti dal singolo utente, dal fatto che la firma venga usata nel contesto del commercio elettronico o meno, dal livello di alfabetizzazione delle vittime, da tanti fattori. Se firmo un form Web, e magari non visualizzo neppure le estensioni, e poi “uploado” il form (html) firmato, se la parte con cui opero è l’attaccante, può successivamente modificare l’estensione e poi contestarmi un pagamento con un contratto BMP… Magari dopo molti mesi. Conoscere l’attacco può aiutare a contrastare le minacce.

    6. Obiezione: “La truffa verrebbe subito smascherata”

    Ciò è tipico delle alterazioni di documenti (sia cartacei che informatici). Non per questo non dobbiamo preoccuparci di contrastare il rischio.

  9. ERRATA CORRIGE:

    la frase:

    “Non so cosa intende il tal Lavarra con “file diversi”. ”

    è stata erroneamente inserita (cut&paste fuori controllo…),
    mi scuso per il disguido.

    Aggiungo che l’attacco funziona anche sul
    sicurissimo ed usatissimo formato TIFF.

    Saluti

  10. Grazie mille Francesco, hai portato una analisi molto interessante. Se mi permetti, la riporto direttamente in un post su questo blog. Interessante anche la soluzione proposta, anche se non ne so molto di buste crittografiche, per cui mi dovrò documentare un po’ per riportare i link che ne spiegano l’uso. Ho una domanda, però: hai detto che l’attacco può essere contrastato attraverso la busta PKCS#7, ma che questa non protegge dagli attacchi a codice dinamico. Questo vuol dire che serve una doppia crittografia? O è sufficiente che il documento crittografato sia a norma delle disposizioni di legge in materia di firma digitale, che, mi pare di capire vietano l’uso di codisce dinamico in tali documenti?

  11. la busta PKCS#7 è quella che è comunemente usata per i documenti firmati. Essa contiene il documento, la firma, il certificato (ed altri elementi). Ha un formato standard, semistrutturato. La soluzione che accennavo è quella di includere nel campo “attributi firmati” della busta anche il nome o meglio ancora il mime-type del file, di modo che non ci possa essere ambiguità sull’applicazione che viene invocata per visualizzare il documento. Questa soluzione non avrebbe certamente alcun effetto sul problema dei documenti “dinamici”. Gli attacchi basati su questi metodi continuerebbero ad avere successo.

    E’ chiaro che se il documento è a norma di legge non sorgono problemi, ma è quasi tautologico. Il problema è rilevare per tempo (cioe’ prima di un eventuale uso fraudolento) i documenti che non sono a norma di legge…

    Saluti

  12. Si, in effetti mi sono espresso male. Quindi bisogna usare la PKCS#/ per questo nuovo attacco, e ovviamente combinarla con strategie per contrastare gli attacchi dinamici, giusto?

  13. PKCS#7 con inclusione del mime type e strategie per contrastare gli attacchi dinamici, ok.

Lascia un commento

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...

%d blogger cliccano Mi Piace per questo: