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