Anche i documenti testuali nascondono vulnerabilità
Transcript
Anche i documenti testuali nascondono vulnerabilità
Anche i documenti testuali nascondono vulnerabilità Codici maligni annidati in estensioni tipo .doc, .txt., .pdf, .odt possono compiere operazioni non volute dall’utente. Ecco come proteggersi. M.R.A. Bozzetti, OAI founder Come illustrato nei numeri precedenti di questa rubrica, i codici maligni, lo dice il termine, sono programmi che, se attivati per qualsiasi motivo (attivazione, scarico da Internet o da posta elettronica e relativa apertura, time-out, attivazione di altri programmi, ecc.) possono compiere operazioni non volute dall’utente, che possono causare modifiche e danni ai programmi e alle informazioni trattate. Con documenti testuali, tipicamente file con estensioni tipo .doc, .txt, .pdf .odt, esistono vulnerabilità e, se sì, quali? Le vulnerabilità nei documenti di testo Sì, esistono vulnerabilità che derivano principalmente da due diversi gruppi di cause: a) vulnerabilità presenti nei programmi di trattamento e/o di lettura dei testi (word processor, parser), quali Word in Microsoft Office, Adobe Acrobat, Acrobat Reader, Open Office, ecc.; b) vulnerabilità presenti nel file che contiene il testo stesso, in particolare quando sono usate macro e script. I programmi di trattamento testi, in quanto tali, possono presentare diverse vulnerabilità. Con il tempo questi programmi si sono evoluti diventando sempre più complessi, in grado di interfacciarsi e integrarsi in logica multimediale con altri programmi per poter includere nei testi oggetti dei più vari formati, da immagini a calendari e formule matematiche. E come ogni programma complesso e con milioni di linee di codice, hanno “fisiologicamente” errori e bachi che rappresentano delle possibilità di attacco per hacker/cracker esperti. Più tali programmi sono diffusi, poi, tanto più suscitano l’interesse degli attaccanti. Un 88 office automation ottobre 2010 esempio per tutti: Adobe Reader, programma di lettura (rendering) dei file .pdf, che grazie anche alla sua gratuità è tra i più diffusi al mondo. Esso è diventato un obiettivo per chi intende scrivere codici maligni basati su bachi del “parser” del linguaggio PDF e del parser di JavaScript (il linguaggio PDF supporta, includendolo, JavaScript). La tabella in fig.1 elenca alcune delle principali vulnerabilità classificate per Adobe da CVE, Common Vulnerabilities and Exposures (http://cve.mitre.org/), e, pur non entrando negli aspetti tecnici delle vulnerabilità elencate, evidenzia come nuove release del prodotto eliminino precedenti vulnerabilità, ma ne introducano di nuove. È preso come esempio Adobe, che tradizionalmente è considerato molto sicuro. Ma analogo discorso può essere fatto per tutti gli altri programmi di trattamento testi. Per il ben noto e diffuso Word di Microsoft CVE e NVD, il National Vulnerability Database statunitense, hanno classificato dal 1999 a oggi decine e decine di vulnerabilità nelle diverse versioni di Word, dalla 97 alla 2007 (le stesse case produttrici classificano e segnalano sui loro siti web le vulnerabilità riscontrate nei loro prodotti. Si è preferito in questo caso citare una fonte autorevole e indipendente). Sfruttare per attacchi le vulnerabilità dei programmi non è facile. Occorrono sofisticate competenze. I produttori poi forniscono patch e nuove versioni per i loro sistemi che rendono molti attacchi inefficienti, almeno per coloro che hanno aggiornato i prodotti stessi. Installare appena disponibili le patch e le nuove versioni del programma è il mezzo di protezione principale. Il secondo tipo di vulnerabilità, all’interno del testo stesso, risulta ancor più critico, anche perché la maggior parte degli utenti non pensa che un file di testo possa essere un vettore di codici maligni. Un file testuale, costituito da solo testo, non contiene co- Alcune delle principali vulnerabilità riscontrate su Adobe Reader e Adobe Flash Player • • • • • • • • • • • • Adobe Acrobat AcroPDF ActiveX control fails to properly handle malformed input; CVE-2006-6027 Adobe Flash Player 9.0.115.0 Flash File NULL Pointer Dereference Vulnerability; CVE-2007-0071 Adobe Reader 8.1.1 JavaScript Argument- Handling Buffer-Overflow Vulnerability; CVE-2007-5659 Adobe Reader 8.1.1 “Collab.collectEmailInfo()” Stack-Based Buffer Overflow Vulnerability; CVE-2008-0655 Adobe Reader 8.1.2 “util.printf” Stack-Based Buffer Overflow Vulnerability; CVE-2008-2992 Adobe Reader “Collab.getIcon()” Stack-Based Buffer Overflow Vulnerability; CVE-2009-0927 Adobe Reader 9.1 getAnnots() Function Buffer Overflow Vulnerability; CVE-2009-1492 Flash 10, Adobe Reader & Acrobat; CVE-2009-1862 Adobe Flash Player 10.0.22.87 ActionScript Virtual Machine 2 Integer Overflow Vulnerability; CVE-2009-1869 Adobe Flash Player 10.0.45.2 AVM2 Improper Enforcement of Data Structure Vulnerability; CVE-2010-1240 Adobe Flash Player 10.0.45.2 AVM2 Improper Enforcement of Data Structure Vulnerability; CVE-2010-1297 Adobe Flash Player 10.1.82.76 Unspecified Vulnerability; CVE-2010-2884 Fig.1 dice e dovrebbe essere quindi intrinsecamente sicuro. Vero, a meno che non si inseriscano nel testo, volutamente o non, dei codici di programma. Volutamente, quando ad esempio si usano macro. Involontariamente, quando l’attaccante sfrutta vulnerabilità dei programmi di lettura dei testi (parser) per inserirvi codici maligni, ad esempio con tecniche tipo heap sprying. Si considerino per prime le macro: sono un insieme di comandi (istruzioni) all’intero di un programma, che non richiedono vere e proprie capacità di programmazione per scriverle. Una macro consente l’esecuzione di una serie di operazioni con un solo comando. Grazie alle macro è possibile automatizzare determinate operazioni all’interno del programma utilizzato. Tipici e diffusi usi di macro nell’elaborazione di testi sono l’inserimento automatico di indirizzi, prelevati da una banca dati, da associare ad esempio a una lettera promozionale, oppure la formattazione automatica di numerose tabelle in un testo. Operazioni che in taluni casi richiederebbero, svolte passo a passo, anche ore, e che con una macro sono svolte in secondi o minuti. In ambito Office il tipico linguaggio per le macro è il Microsoft Visual Basic for Applications, VBA. Spesso per le macro sono usati degli script, uno dei più diffusi è JavaScript. Anche se le macro in un documento possono rappresentare punti di vulnerabilità, questo non significa che non debbano essere usare, ma che devono essere usate con precauzione, soprattutto se generate da persone/enti non noti. Tecniche tipo heap sprying consentono, senza entrare in dettagli tecnici, l’esecuzione di codici arbitrari (spesso script o pezzi di html), inseriti in locazioni fisse della memoria (heap) del pc. Considerando ad esempio Acrobat Reader, le vulnerabilità del parser del linguaggio PDF sono sfruttate per eseguire shellcode maligni, usando anche Javascript. Un tipico funzionamento di un file PDF maligno è il seguente: a) viene estratto dal file PDF un eseguibile; b) il codice estratto è salvato nella directory di Windows system32 (nel caso di un pc con sistema operativo Windows); c) viene eseguito il codice maligno estratto. Fonte: CVE Come proteggersi In conclusione, anche (presunti) innocenti file testuali possono includere codici maligni e/o essere sfruttati per attivarli. Come proteggersi? La prima difesa è scaricare e attivare tutte le patch e le ultime versioni del prodotto di trattamento testi usato. Una seconda protezione è l’uso di scanner antivirus. Ulteriori prevenzioni riguardano il rafforzamento (hardening) della sicurezza del pc e del sistema operativo, oltre che dell’applicazione di lettura e/o trattamento testi. L’hardening di una applicazione consiste soprattutto nel configurarla e nel personalizzarla in maniera sicura: tipici esempi escludere l’utilizzo di Javascript, di Flash e di altre opzioni che possono rappresentare un rischio su documenti sospetti. Un ulteriore mezzo di protezione è convertire il documento in un’immagine o in una stampa, trasformando il formato originale del documento. A sua volta il programma di conversione può avere vulnerabilità. Le misure indicate non sono comunque in grado di proteggere contro qualsiasi tipo di attacco, in particolare contro attacchi mirati (targeted attack), ove l’attaccante conosce molto bene l’ambiente informatico, le protezioni in essere e le informazioni e i sistemi da attaccare. La sicurezza assoluta, è bene ricordarlo sempre, non esiste. Si ha un documento riservato e critico? Protezione estrema: non archiviarlo e non trattarlo in ambienti connessi ad altri sistemi e a Internet. Partecipa al nuovo rapporto OAI 2010 compilando online il questionario su http://www.soiel.it/questionarioOAI2010/pagina1.html ottobre 2010 office automation 89