Klez & linux (Vulnerabilità di linux ai virus)

Sat, 28 Jan 2006 15:10:15 GMT

Una delle forze di linux è sicuramente il fatto che sia invulnerabile ai tipici virus di windows: data la notevole differenza di architettura e di (migliore) progettazione, tutto sembrava avvalorare questa tesi.

Al contrario, qualche giorno fa ho letto su un portale dedicato alla sicurezza per sistemi linux (linuxsecurity.com) che la possibilità di essere infettati da virus per windows era possibile benchè si stesse utilizzando un sistema linux. Immaginate il mio stato d'animo! Da parecchi mesi utilizzo unicamente il pinguino, e quando mi arriva un allegato (anche se sospetto) io lo eseguo con un sorriso beffardo sulle labbra, ritenendo di essere praticamente invulnerabile: l'articolo a cui accennavo prima non si soffermava in analisi tecniche molto accurate, più che altro raccontava una storia accaduta ad un conoscente dell'autore; per questo motivo ho deciso di approfondire l'argomento, dato che ritengo che la questione sarà di massima importanza in futuro per la sicurezza di sistemi linux (in particolare desktop).

Per tentare di capirne qualcosa di più ho preparato due macchine, una che montava una Red Hat linux 7.3 con il Kernel 2.4.18, l'altra una Slackware 8.1 con il kernel 2.4.19 e l'SMTP (Symple Mail Transfer Protocol) disattivato durante l'avvio dell'infezione.

Analisi del virus:

Per effettuare questo test ho deciso di utilizzare Klez.h, prima di tutto perchè nell'articolo di cui parlavo prima l'infezione è stata causata proprio da questo worm, in secondo luogo per alcune sue caratteristiche tecniche (che ne fanno un "dumb" virus). In seguito potremo generalizzare le caratteristiche che rendono questo virus in grado di attecchire anche su sistemi linux e magari anche compilare una piccola lista di altri virus che ne sono capaci.

Il worm

Klez è molto diffuso in rete, è in grado di propagarsi via mail e tramite risorse condivise su rete locale: è un worm di tipo "companion", poiché infetta gli eseguibili creando una copia nascosta del file originale (con stesso nome ma diversa estensione) e sovrascrivendo quest'ultimo con una propria copia.

Come si propaga

Dopo aver infettato il sistema, klez cerca ulteriori indirizzi e-mail a cui spedirsi nella rubrica di Windows, nel database di ICQ e da vari altri files presenti sul sistema, che abbiano le seguenti estensioni:

*.mp8

*.exe

*.scr

*.pif

*.bat

*.txt

*.htm

*.html

*.wab

*.asp

*.doc

*.rtf

*.xls

*.jpg

*.cpp

*.pas

*.mpg

*.mpeg

*.bak

*.mp3

*.pdf

il worm invia una e-mail a tutti gli indirizzi trovati, con oggetto e corpo del messaggio assolutamente casuali, e in allegato una copia di se stesso; talvolta può accadere che siano inviati files del sistema ospite.

Una cosa molto importante da notare (ricavata dagli innumerevoli documenti disponibili in rete) è che:

IL WORM SI DIFFONDE VIA MAIL SFRUTTANDO UN PROPRIO MOTORE SMTP PER SPEDIRSI

Il perchè è importante lo vedremo in seguito.

Infezione

Una volta eseguito, il worm si copia nella cartella di sistema di windows, usando il nome Wink<caratteri_casuali>.exe , quindi modifica il registro di sistema creando la chiave

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run

oppure

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Wink[caratteri casuali]

e aggiungendovi il nome del file creato nella cartella di sistema, al fine di essere eseguito ad ogni avvio di sistema.

Test pratico su Red Hat 7.3 e Slackware 8.1

Nell'esecuzione di questa prova ho considerato i due maggiori veicoli di infezione, cioè tramite allegato e-mail e floppy disk proveniente da sistema (windows98se) infetto.

Infezione via e-mail

Dopo essermi ripetutamente inviato una copia del virus sul sistema di test, ho aperto l'allegato con i client di posta più comuni (Kmail ed evolution) al fine di notare se mi si fosse aperto un alert di qualsiasi genere che indicasse quanto sono furbo ad aprire un allegato eseguibile...

Questo è quello che è successo con Kmail:

Perfetto, kmail mi avverte che l'esecuzione del programma è potenzialmente pericolosa, nonostante ciò decido di proseguire: nel sistema in cui è stato preso questo screenshot, kde non associa nulla alle applicazioni eseguibili di windows, per questo motivo viene mostrata l'opzione "apri con"; nell'altra distribuzione le applicazioni windows vengono aperte con wine, e posso quindi eseguire il file senza ulteriori intoppi (vedere screenshot che segue).

L'altro client di posta che ho deciso di considerare, Evolution, si comporta in modo leggermente differente: sebbene la configurazione di sistema fosse la stessa usata per kmail, Evolution non mi permette di eseguire il file dalla posizione corrente, e mi costringe di conseguenza a salvarlo sul disco ed eseguirlo da li, come dimostra il seguente screenshot.

Infezione tramite floppy

Per effettuare questo test ho utilizzato esclusivamente kde ed un comunissimo floppy contenente un eseguibile infettato da klez proveniente da un sistema windows98se.

Anche se i file *.exe su questo sistema vengono aperti di default con WINE, se noi clicchiamo sul file in konqueror dopo averlo scaricato in una cartella del mio sistema, non accade niente, l'unico cambiamento è presente nella barra degli indirizzi che viene modificata nel modo seguente:

ma come ho potuto constatare con un semplice `ps -aux` da root non risulta che alcun processo sia partito (in parole povere klez non è stato eseguito). Per avviare il virus bisogna cliccare con il pulsante destro del mouse sull'eseguibile e selezionare manualmente "wine" oppure digitarlo nella finestra "apri con".

Sebbene i due client di posta e konqueror si comportino egregiamente di fronte ad un allegato eseguibile ricevuto via e-mail, la sua esecuzione rimane comunque possibile... come? Con WINE, naturalmente!

WINE è il risultato del lavoro di un team di ottimi sviluppatori, che hanno creato un programma in grado di far girare moltissime applicazioni disegnate per windows: il risultato delle fatiche di questo team di sviluppo è stato così buono che WINE è in grado di riprodurre perfettamente un sistema windows, nel bene e... nel male!

Infezione

In un modo o nell'altro riesco ad eseguire klez: la prima cosa da fare per vedere se sono effettivamente infetto è controllare il registro... si, perchè wine dispone di un vero e proprio registro in tutto e per tutto uguale a quello di windows (l'unica differenza consiste nel fatto che è comprensibile): a meno che non si sia scelto in fase di configurazione di fare puntare il registro di wine a quello di un windows realmente esistente, la configurazione di default scrive nel file ~/.wine/system.reg la chiave HKEY_LOCAL_MACHINE, apro quindi questo file con vi e cerco una delle due chiavi che klez scrive quando attacca un sistema:

[Software\\Microsoft\\Windows\\CurrentVersion\\RunWinkpfg.exe]973650384

perfetto, il worm sembra aver messo radici nel sistema!

Per esserne veramente sicuro ho fatto uno script della shell che continuava a fare un `ps -aux`, salvando l'output su di un file di testo (temevo che il worm terminasse la propria esecuzione dopo aver svolto velocemente le proprie operazioni abituali), ecco il risultato:

hannibal 1505 2.7 7.2 14064 4480 pts/3 S 21:30 0:00 wine klez.exe

hannibal 1507 0.1 1.1 2508 696 ? S 21:30 0:00 wineserver

Diffusione

Avevo precedentemente inserito nei miei due sistemi di test files con varie estensioni (*.txt, *.htm)

che contenevano un particolare indirizzo di posta a cui il worm si sarebbe dovuto spedire. Effettivamente sono arrivate sull'account di posta indicato più mail contenenti il worm, adirittura in una era incluso un file di configurazione di xmms (!): la cosa spiacevole è che dai risultati di tcpdump (uno sniffer davvero ottimo) ho notato che il numero di pacchetti partiti è decisamente superiore al solito, non vorrei ad esempio che alcune mail siano state spedite ad alcuni sviluppatori di linux o kde (i cui indirizzi sono stati probabilmente pescati dalle credit list), se è così SCUSATEMI!!!

Figuraccie a parte, sempre grazie al tcpdump ho potuto notare una cosa abbastanza curiosa: ricordate che una delle due macchine era stata configurata con il server smtp momentaneamente disabilitato? Bene, nonostante ciò il worm ha inviato i messaggi che servivano alla sua diffusione, questa è un'ulteriore prova del fatto che klez utilizza un poprio motore SMTP per spedirsi.

Risultato

Ora so con certezza di essere stato infettato da klez.h, ma quali sono stati i danni reali al mio sistema?

Come ho potuto notare salvando diversi files che avevo inserito nei sistemi di test (2 *.txt, 2 *.mp3, 2 *.exe di windows, 2 programmi compilati sotto linux) su un floppy e quindi facendo uno scan con Norton Antivirus da windows, gli unici files che sono stati infettati sono stati gli eseguibili di windows: ne consegue che la struttura interna di linux è rimasta inalterata anche dopo ripetuti infezioni del worm, e che tutti gli altri files personali sono rimasti "puliti" (sebbene sia capitato che documenti personali siano stati inviati via mail). Un altro problema piuttosto serio è che klez ha raccolto vari indirizzi e-mail sul mio sistema, utilizzandoli per autospedirsi e quindi infettare altri sistemi: pur usando linux, non ho potuto in alcun modo evitare che il worm si spedisse ai miei contatti, contribuendo così alla sua diffusione.

Estendiamo il concetto ad altri virus/worm

Purtroppo allo stato attuale delle cose molti virus sono in grado di girare sotto linux tramite wine, ma devono rispondere a queste caratteristiche:

Se fra le istruzioni di un virus si trova anche quella di scrivere o settare delle chiavi del registro di windows, wine non porrà alcun ostacolo a questo, semplicemente non funzioneranno: l'esecuzione del programma continuerà senza intoppi.

Se il virus infetta dei files questi saranno necessariamente di un tipo conosciuto: saranno dunque colpiti i tipi di files più utilizzati sotto windows (come i .exe).

Se per propagarsi un virus deve cercare dei nuovi indirizzi nella rubrica di windows, di outlook, o di qualsiasi altro eseguibile non incluso in wine, non troverà mai niente e non sarà in grado di diffondersi.

Per propagarsi (a meno che non si sia in rete locale) un virus deve avere necessariamente un motore smtp proprio per spedirsi: contrariamente a molte voci che girano in rete, il registro di sistema di wine non associa di default `localhost`come SMTP server, almeno da quanto mi risulta dalla documentazione ufficiale per utenti e sviluppatori.

Come difendersi

Come nella maggior parte dei problemi di sicurezza il maggior rischio è rappresentato dall'utente, che sentendosi completamente al sicuro spesso compie gravi errori di valutazione circa gli allegati sospetti. A parte questo un consiglio pratico facilmente attuabile potrebbe essere quello di evitare assolutamente di associare di default wine agli eseguibili per windows , si può tranquillamente decidere di volta in volta con cosa aprire una mail, evitando così di ritrovarsi con klez in esecuzione dopo aver aperto un semplicissimo file immagine. Per evitare spiacevoli inconvenienti è possibile filtrare la posta direttamente sul server pop, riservando così un trattamento "privilegiato" agli allegati sospetti, con kmail è questione di pochi click.

Un altro consiglio (di meno facile attuazione, lo ammetto) è quello di realizzare una vera e propria sicurezza proattiva: bloccare gli allegati infetti prima che arrivino al sistema su cui si lavora, a questo scopo vi rimando agli ottimi documenti presenti sia su internet sia su alcune riviste dedicate a linux.

Rischi derivanti dalla situazione attuale

Stando così le cose, i virus realmente cross-platform (cioè in grado di attaccare più sistemi operativi) potrebbero diventare una realtà: ad esempio tramite una determinazione del tipo di file valida per i vari sistemi operativi (sostanzialmente il concetto del comando `file`), un virus-writer potrebbe essere in grado di infettare vari files e quindi danneggiare praticamente ogni sistema in cui si imbatta il proprio virus.

Ma un sistema così ben progettato come linux non permette di essere sopraffatto così facilmente da un semplice virus: infatti se un worm viene eseguito da semplice user i files danneggiati saranno più o meno solo quelli personali in /home (cioè quelli su cui lo user ha permessi adeguati), mentre se il worm viene eseguito da root i casi sono due:

1- l'amministratore di sistema deve essere arrestato

2- (facile se si tratta di un sistema desktop) l'utente si scarica la posta, o comunque naviga fra i files da root.

In entrambi i casi trova una ulteriore dimostrazione il fatto che la colpa di gravi danni al sistema è sempre dell'utente dello stesso.

Conclusioni

Questo documento è stato scritto con lo scopo di evitare i soliti sensazionalismi che imperversano di solito sulle notizie di sicurezza, conducendo un'analisi rigorosa di cause e di conseguenze: troppo spesso in questo periodo tutto viene ridotto a FUD (Fear, Uncentaity, Dubt: Paura, Insicurezza, Dubbio), ed è precisamente quello che ho voluto evitare.

in collaborazione con http://spaces.msn.com/grazitaly/

steganografia in linux

Sat, 28 Jan 2006 14:55:01 GMT

::: primo tempo :::

Requisiti:
sistema linux ( mi pare ovvio :P )
dovete essere root ( su - < invio > e poi digitate la vostra root passwd ( spero non 12345678 ) )

file jphs-0.3.tgz http://www.cstr.ed.ac.uk/download/rjc/tarfiles/libjpeg-6a.tar.gz

file libjpeg-6a.tar.gz ftp://ftp.gwdg.de/pub/linux/misc/ppdd/jphs-0.3.tgz

#Perl script dei requisiti mentali minimi
$qi = <STDIN>;
chomp $qi;
if (qi = 80) {print "bravi potete farcela" };
else { print "siete fregati" };
#non so se mi sono spiegato

per prima cosa scompattate il file libjpeg-6a

tar -zxvf libjpeg-6a.tar.gz

rinominate la dir che lo scompattamento ha creato

mv directoryname jphs

ora vi ritroverete la directory rinominata in jphs

cd jphs

ora vi ritroverete nella directory appena rinominata

./configure

avete lanciato il configure ... attendete che finisca

make

tramite make compilerete i file necessari ... attendete finisca anche il make

::: secondo tempo :::

scaricate da link il secondo file jphs-0.3.tgz

copiate il file nella directory precedente jphs

cp jphs-0.3.tgz /jphs

ora dovete patchare il makefile con quello messo a disposizione dall'ultimo archivio
... posso leggere nei vostri sguardi terrore e disorientamento ... non vi preoccupate digitate
quanto segue

patch < makefile.patch

ok avete patchato quello che dovevate patchare ... ora non vi resta che compilare lanciate un

make

ok ora e' tutto installato, copiate per comodita' i files eseguibili jphide e jpseek in /usr/local/bin

cp jphide jpseek /usr/local/bin

bravi ! Ora siamo pronti ad usare jphs sulla nostra linux box :)

i vostri due file appena copiati in /usr/local/bin e' inutile dire che hanno due funzioni differenti.
Il file jphide, come facilmente si puo' dedurre se si conosce il corrispondente italiano del termine hide, serve a "nascondere" un file tra i byte di un immagine jpeg, mentre invece jpseek, al contrario serve a recuperare i dati "nascosti" all'interno del vostro file immagine. Jphs si riufiutera' di fare il merge di file se uno dei due contiene codice malefico, e questo e' importante specificarlo, in quanto lo scopo di jphs, non e' quello di distruggere ne niente ne nessuno, ma ha come compito il permettere lo scambio di informazioni in modo sicuro e protetto da occhi indiscreti, e' un po' la filosofia che ruota intorno a ssh o gpg se preferite :)

allora incominciamo con lo spiegare la sintassi di jphide:

jphide maddy.jpg maddyspecial.jpg readme.txt

jphide => uno dei due file copiati in /usr/local/bin

maddy.jpg => il file immagine di imput

maddyspecial.jpg => il file output ( file immagine contenente readme.txt )

readme.txt => il file da "inserire" nel file immagine

dopo aver digitato la riga di comando con il vostro file immagine e il vostro file di testo, jphs vi chiedera' una passwd con il quale proteggera' il contenuto reale del file immagine steganografato.
In poche parole vi ritroverete un file maddyspecial.jpg contenente il file readme.txt o meglio il suo contenuto, lasceret in questo modo inalterato nei contenuti il file imput immagine maddy.jpg.

Come dicevo prima, i programmatori che hanno ideato questa meraviglia della natura, hanno inserito anche un file jpseek, che ovviamente ha una funzione altrimenti che ci sta' a fare?!
Vediamo la sintassi del file jpseek:

jpseek maddyspecial.jpg fixeddata.txt

cosa fa questa riga di comando ?! ... bhe mi sembra ovvio. In questo modo jpseek estrarra' dal file immagine il contenuto del file readme.txt che avevate "nascosto" precedentemente ... potrete trovarne il contenuto nel file di output fixeddata.txt.

!< ricordate che per estrarre i dati dal fle immagine avrete bisogno della passwd con la quale questi dati sono stati steganografati>!

Grazie a http://grazitaly.spaces.live.com/

Una Debian è per sempre: Sviluppo

Klez & linux (Vulnerabilità di linux ai virus)

steganografia in linux