Ubuntu, malware in due screensaver su Gnome-Look. Ubuntu è diventato un sistema operativo insicuro?
11 dic2009
Questo articolo giunge su questo blog per gentile richiesta di Nico, che mi ha contattato via e-mail scrivendomi: "Salve, mi piacerebbe un tuo intervento in merito ai due trojan scoperti su gnome-look".
Il lettore non mi ha dato ulteriori ragguagli e quindi mi sono informato online, principalmente leggendo due thread sui forum di ubuntu, questo e questo e tramite i due articoli linkati su Slashdot.
Cosa è successo quindi? Si è scoperto che un paio di screensaver presenti su Gnome-look e distribuiti come eseguibili .deb (compatibili quindi con tutte le distribuzioni derivate da Debian, quindi anche Ubuntu) non erano dei veri screensaver ma in realtà erano dei cavalli di troia che si insediavano all'interno del computer dell'utente, scaricavano poi dei file da remoto ed utilizzavano questi file per effettuare attacchi DoS ad alcuni siti internet. Gli attacchi DoS servono sostanzialmente per rendere il sito irraggiungibile ed inutilizzabile.
Cosa è un cavallo di troia e che cosa lo differenza da un virus o un worm? Non vi farò lunghe filippiche cercando di spiegarvi in dettaglio le differenze, altrimenti vi annoiereste. In poche righe: il virus è un programma che deve necessariamente legarsi ad un altro eseguibile per sopravvivere. Di solito i virus infettano il boot sector del disco rigido, mentre molti vecchi virus per Dos spesso si annidavano all'interno del command.com. Il virus, per infettare un computer, deve essere eseguito dall'utente, magari inserendo una chiavetta USB o un disco infetto. I worm sono invece la categoria di malware più infida perché non hanno bisogno di attaccarsi ad altri programmi per sopravvivere e soprattutto infettano il computer dell'utente sfruttando vulnerabilità e bug del sistema operativo o dei programmi. L'utente quindi non deve fare niente per trovarsi il computer infettato. Questa categoria di malware è oggi la più diffusa ed anche la più difficile da eliminare (spesso anche gli antivirus falliscono perché i worm si replicano in modi diversi e continuano a rientrare nel pc ospite fintanto la vulnerabilità rimane aperta). Infine vi sono i trojan horse (o cavalli di troia) che, proprio come il mitico cavallo di legno che contribuì alla distruzione della città di Priamo, entra nel computer dell'utente ingannandolo e mascherandosi da qualcos'altro. Il cavallo di troia, per infettare il computer, deve essere esplicitamente eseguito dall'utente e proprio per questo si maschera da qualcos'altro. Una volta entrato nel computer dell'utente il cavallo di troia han potenzialmente il controllo della macchina e la utilizza per inviare spam, fare attacchi DoS, o trasformarla in un vero e proprio bot utile per azioni criminali.
Il malware che si insediava negli screensaver di gnome-look era proprio un cavallo di troia quindi, per infettare il computer dell'utente, necessitava dell'esplicita esecuzione del programma. In tal caso nessun sistema operativo può proteggere l'utente, così come le alte mura di Troia non poterono proteggere la mitica città dagli attacchi dei greci. Quale miglior inganno di un attraente screensaver, infilato dentro ad un sito che molti utenti Linux ritengono sicuro? Gli utenti hanno cliccato sul file .deb, hanno concesso al virus l'accesso root inserendo la password in fase di installazione e poi, invece di uno screensaver si sono trovati un cavallo di troia nel computer. La prima cosa che possiamo dire è che i computer non sono stati infettati a causa di una vulnerabilità di Ubuntu, chi non ha provato ad installare questi screensaver non ha alcuna possibilità di essere stato infettato. La seconda cosa: gli utenti a rischio sono coloro che usano distribuzioni che si avvalgono del gestore dei pacchetti APT (Debian, Ubuntu, Mepis), sono esclusi invece, ma solo da questo specifico attacco, gli utenti di Fedora, Mandriva, Arch Linux, Gentoo ed altre distribuzioni.
Naturalmente queste osservazioni non consolano gli utenti che si sono ritrovati il computer infettato e pensavano di utilizzare un sistema operativo invulnerabile. Oggi questi utenti hanno imparato che un sistema operativo totalmente invulnerabile non esiste. Il sistema operativo può essere più sicuro di altri, può offrire patch più velocemente ed avere programmi e sistemi di distribuzione degli stessi più o meno bacati e più o meno solidi, ma non potrà mai controllare al 100% ciò che l'utente fa con il proprio computer. Il tipo di attacco di cui stiamo parlando in questo pezzo ha utilizzato metodi di Ingegneria Sociale. Gli attacchi di ingegneria sociale sono più facili quanto più è standardizzato il comportamento degli utenti. Più un sistema operativo, un programma di posta, sono diffusi, più gli utenti che lo usano sono potenzialmente soggetti a tali attacchi, ancor di più quando gli utenti non sono molto attenti alle conseguenze dei loro comportamenti.
Eseguire un file di dubbia provenienza è sempre pericoloso, a prescindere dal sistema operativo che si sta usando. Quando poi questo file chiede la vostra password allora i pericoli diventano altissimi. Quando parlo di dubbia provenienza non mi riferisco certo al sito da cui state scaricando il file, che potrebbe essere benissimo un sito serio e molto conosciuto (come gnome-look o sourceforge) ma mi riferisco ovviamente all'autore del file in questione. In questi casi sarebbe bene effettuare un controllo in più, essere più guardinghi. Le distribuzioni Linux offrono tutte un sistema centralizzato per l'installazione di applicazioni, Ubuntu offre anche i PPA (Personal Packages Archives), quelli più utilizzati possono ritenersi abbastanza sicuri. Quando però si esce dal seminato e si cerca di installare un file eseguibile presente in un sito che offre migliaia di applicazioni allora il rischio di avere brutte sorprese cresce notevolmente e non c'è sistema operativo che tenga. Sta a voi vigilare ed evitare di installare programmi la cui provenienza è dubbia.
L'attacco ad Ubuntu però ci ha dimostrato quanto la comunità open source sia veloce nel rispondere a questi attacchi. Come riportato in questo messaggio sul forum di Ubuntu in pochissimo tempo dalla scoperta del trojan il forum di Ubuntu ha spiegato il metodo per eliminare il trojan dai computer infetti inoltre, in meno di tre ore, un altro utente ha preparato uno script per verificare la presenza del trojan nel computer e dopo pochissime ore i file infetti sono stati cancellati da gnome-look. La risposta è quindi stata velocissima, non è poco.
Di seguito il metodo per eliminare il trojan, nel caso abbiate scaricato questi screensaver da Gnome-Look:
Aprite un terminale e digitate:
sudo rm -f /usr/bin/Auto.bash /usr/bin/run.bash /etc/profile.d/gnome.sh index.php run.bash && sudo dpkg -r app5552
Questo comando in primis elimina gli script installati dallo screensaver e poi rimuove il pacchetto installato. Vorrei infine far notare come la semplicità di Linux, che gestisce tutto tramite file di testo, renda la rimozione di eventuali worm o trojan generalmente più semplice che in altri sistemi operativi. Molti malware per Windows infettano il registro di sistema e sono davvero difficilissimi da localizzare. Il registro di sistema di windows, a mio modesto parere, è una delle scelte di design più discutibili del sistema operativo Microsoft, non ne capisco i vantaggi ma ne comprendo benissimo gli svantaggi.
Se volete verificare la presenza o meno del trojan nel vostro PC usate questo scanner preparato da un utente Ubuntu:
#!/bin/sh
while :
do
check=`ps -o pid,cmd -A | egrep '\bwget\b|\bping\b'`
if [ -n "$check" ]; then
echo "!!-> pid $check <-!!"
fi
sleep 1
done
Aprite un editor di testo, copiato il contenuto riportato qui sopra, salvate il file in una cartella qualsiasi nominandolo scanner.sh, avviate il terminale, entrate nella cartella in cui avete salvato il file, infine digitate:
sh scanner.sh, se il virus è presente nel vostro computer allora vedrete apparire dei messaggi sul terminale, diversamente il terminale non eseguirà alcun output.
Leggi anche:
- Your Linux, Your Way. Crea il tuo sistema operativo su misura partendo da un cd minimale
- LogFaq: rivenditori Kubuntu/Ubuntu
- Upgrade del proprio sistema operativo: confronto tra il metodo Ubuntu ed il metodo Microsoft
- Esce oggi il vostro prossimo sistema operativo
- How-to: Come creare un sistema operativo "portatile", completo di interfaccia grafica, che si avvia da mini-cd o da penna-usb
(Gli utenti ritengono che questo articolo valga +3, hanno votato 3 utenti)
Loading ...- Blu-ray ed HD-DVD craccati per la seconda volta
- Blu-ray ed HD-DVD craccati per la seconda volta
- Diritti d'autore creativi: videoblog sulla proprietà intellettuale (puntata 5)
- Non avete una connessione a banda larga? Sappiate che è tutta colpa del Titanic
- Non avete una connessione a banda larga? Sappiate che è tutta colpa del titanic II
Articoli correlati
Warning: Cannot use a scalar value as an array in /home/doxaliber/webapps/doxaliber/wp-content/plugins/yet-another-related-posts-plugin/related-functions.php on line 43
Leggi anche:
- In: Informatica|LogFaq|Open source|Sicurezza|Software
- Tags: gnu/linux, Open source, Sicurezza, trojan, Ubuntu, virus, worm
Articolo scritto da Doxaliber per Doxaliber, vuoi partecipare anche tu?
Se questo articolo ti è piaciuto aiutami a diffonderlo.
Segnalalo sul tuo blog, invialo agli amici, segnalalo sugli aggregatori di news.
Se vuoi seguire Doxaliber con maggiore tranquillità iscriviti ai feed, trovi i link in alto a destra.
Intanto questo blog ha già:
senza contare i lettori dei feed per categorie e gli abbonati alla newsletter!
25 Risposte to “Ubuntu, malware in due screensaver su Gnome-Look. Ubuntu è diventato un sistema operativo insicuro?”
Rispondi
Doxaliber, blog di Salvatore Ingrosso, è distribuito con licenza Creative Commons. - Collegati -
Questo blog usa wordpress | Tema Evidens [White] realizzato da Design Disease per PremiumThemes.com, modificato, riadattato e tradotto da Doxaliber
ottimo articolo, grazie. Pensavo fossi già a conoscenza del problema ma come vedo hai trovato da solo i giusti riferimenti
Ti piace questo commento?
0 
0
Stavo giustappunto rispondendo alla tua e-mail per dire che avevo già scritto l'articolo.
Bene così. 
Ti piace questo commento?
0 
0
PS Ovviamente non ho messo il tuo nome nell'articolo per questioni di riservatezza, non tutti amano leggere il proprio nome. Se vuoi ti aggiungo con un link al blog.
Ti piace questo commento?
0 
0
un link non si rifiuta mai
Ti piace questo commento?
0 
0
Linkato, ciao!
Ti piace questo commento?
0 
0
e mi sentirei di aggiungere "PER FORTUNA che qualcuno ha spiegato a questi utenti come stanno le cose" visto che l'utente medio di linux vive con la sensazione perenne di usare il sistema operativo perfetto...
Linux come tutti gli altri kernel non è esente da bug...basta guardare i changelog tra le varie versioni per rendersene
conto...e il kernel in un S.O. è solo l'ultima ruota del carro...
il fatto che i virus per linux siano una minoranza rispetto a quelli di windows secondo me non vuol dire niente...ovviamente per una persona intenzionata ad infettare dei computer è meglio costruirne uno per windows che per un s.o. basato su linux, dato che il danno potenzialmente maggiore si ha infettando i sistemi windows (che sono di più)...e non mi sembra una coincidenza che in questo caso siano stati scelti i sistemi operativi che hanno a che fare con APT (tra cui UBUNTU, il sistema operativo probabilmente più utilizzato tra gli utenti linux).
Le falle in linux ci sono, non sono nemmeno poche...e c'è addirittura chi non usa un firewall...infatti:
http://phrack.org/ spesso se prende col pinguino...
http://www.securityfocus.com/ ha pubblicato oggi 4 bug del kernel tra cui uno di "privilege escalation" sulle versioni >= 2.6.11.4...
ITL (http://invisiblethingslab.com/) nel dimostrare un attacco alla memoria SMM ha mostrato come su linux fosse indubbiamente più facile portarlo a termine (e giusto per chi non lo sapesse: c'è il Ring3 dove vengono eseguiti i programmi...c'è il Ring0 dove viene eseguito il kernel e poi c'è la modalità SMM a cui neanche il kernel ha accesso!)
fin qui' niente di nuovo...però vorrei fare una piccola nota: gli aggiornamenti di ubuntu, ad esempio, vengono rilasciati da un sistema di aggiornamenti centralizzato sotto forma di pacchetti...per quanto possano essere veloci gli sviluppatori nel correggere gli errori, comunque passa del tempo dal momento in cui il bug viene scoperto al momento in cui il bug viene corretto e soprattutto al momento in cui l'update viene pacchettizzato e rilasciato...se si tiene conto che scrivere un exploit per linux è indubbiamente più facile che per windows visto che ci sono i sorgenti, si capisce quanto maggiormente linux, rispetto a windows, sia esposto in quel (seppur breve) periodo a potenziali infezioni/attacchi...
forse questo è uno dei pochi casi in cui la security-through-obscurity serve a qualcosa...
Ti piace questo commento?
0 
1
Ciao Ugo, non sono molto d'accordo con la maggior parte delle cose che hai scritto, tranne il fatto che il kernel di Linux (come qualsiasi software di questo mondo però!) non è esente da bug.
"il fatto che i virus per linux siano una minoranza rispetto a quelli di windows secondo me non vuol dire niente...o"
Secondo me vuol dire eccome. In Linux i virus sono esigui in numero e quasi nulli in fatto di pericolosità, questo è un fatto. Ciò non toglie che in futuro non possano esistere virus pericolosi per sistemi Gnu/Linux, tuttavia per ora non ce ne sono e questo è indubbio. Non si può dire: l'Italia sarebbe pericolosa come l'Afghanistan se un giorno qualcuno decidesse di bombardarla. Intanto per ora l'Italia non è sotto attacco e quindi è più sicuro vivere in Italia che non in Afghanistan.
Poi avrei da ridire pure sulla struttura dei due sistemi operativi, ma è un altro discorso, ci vorrebbe un intero articolo (e va detto che Microsoft è migliorata sotto questo aspetto).
In merito alle falle in Linux di cui parli vorrei link più diretti (mi interessano soprattutto i report di securityfocus e invisiblethingslab). Per ora su Secunia leggo, in merito ad Ubuntu 9.10, che ci sono 0 falle critiche
http://secunia.com/advisories/product/28063/
Il kernel invece ha dei bug non corretti ma nessuno di questi è critico:
http://secunia.com/advisories/product/2719/
"gli aggiornamenti di ubuntu, ad esempio, vengono rilasciati da un sistema di aggiornamenti centralizzato sotto forma di pacchetti..."
Il sistema centralizzato dei pacchetti, validati con chiave GPG, è uno dei punti di forza di Gnu/Linux. Molto difficile riuscire ad installare un virus su Ubuntu. Naturalmente i sistemi esistono (esisteranno sempre) ma installare pacchetti a caso dalla rete è decisamente più pericoloso (ed il caso dello screensaver di cui ho parlato oggi lo dimostra).
comunque passa del tempo dal momento in cui il bug viene scoperto al momento in cui il bug viene corretto e soprattutto al momento in cui l'update viene pacchettizzato e rilasciato...s
Di solito i sistemi operativi Gnu/Linux sono velocissimi a tappare le falle, Ubuntu non è da meno. Semmai, soprattutto in passato, sono stati altri sistemi operativi a rilasciare patch di sicurezza (anche importantissime) dopo mesi dalla loro scoperta. A volte è stato necessario aspettare i service pack dopo mesi o anni. Inaccettabile.
"e si tiene conto che scrivere un exploit per linux è indubbiamente più facile che per windows visto che ci sono i sorgenti"
Questa affermazione è decisamente discutibile. Chi cerca vulnerabilità nei programmi non ha bisogno di avere i sorgenti per scoprirle. Non è davvero pensabile che un malintenzionato si metta a studiare milioni di righe di codice alla ricerca di un algoritmo implementato male che possa portare ad una division by zero o a crash di sistema. Non è così che agiscono i cracker. Ed infatti i sistemi più bucati sono sempre stati i sistemi windows. Non solo per la loro diffusione ma anche perché alcune scelte progettuali discutibili li hanno reso tali sistemi estremamente vulnerabili. La security through obscurity ergo non serve a niente, anzi, spesso anzi è più difficile scoprire una falla. Per quanto ovviamente non basta avere il codice sorgente per accorgersi delle falle (parliamo di milioni di righe di codice, spesso piuttosto difficile da interpretrare!).
.e c'è addirittura chi non usa un firewall...infatti:
A cosa serve un firewall? Dipende da cosa fai con il sistema operativo. In primis molti router moderni, alcuni equipaggiati con Linux, svolgono già un lavoro di filtraggio dei pacchetti e chiudono anche le porte in uscita (infatti, ad esempio, moltissimi utenti ricevono un id basso su emule proprio perché le porte tcp e udp usate da emule sono bloccate dai router). La maggior parte delle distribuzioni Linux sono impostate di default per non accettare connessioni dall'esterno, bisognerebbe installare programmi per la condivisione del desktop o server perché vengano aperte porte verso l'esterno (CUPS, X e gli altri server sono impostati di default per non accettare connessioni dall'esterno). Il firewall quindi può servire, ma solo in determinati casi specifici. In questo caso non dimentichiamo che impostare regole in entrata ed in uscita, grazie a netfilter/iptables, è cosa piuttosto semplice, anche per questo Linux equipaggia molti router/firewall hardware. Windows invece, almeno fino alle prime incarnazioni di XP, lasciava aperto il mondo verso l'esterno e quindi il firewall software era necessario (per quanto a volte inutile perché incapacw di proteggere totalmente, soprattutto quando i worm sfruttavano RPC di Windows stesso).
Ti piace questo commento?
0 
0
aiuto!! ho lanciato il .sh su Ubuntu e ha trovato:
!!-> pid 3158 wget -q -N http://archive.ubuntu.com/ubuntu/project/ubuntu-archive-keyring.gpg <-!!
che devo fare?
Ti piace questo commento?
0 
0
Ciao Marino, il wget che leggo non sembra avere a che fare con il trojan? Hai installato quello screensaver da gnome-look?
Verifica che il tuo computer al momento non stia eseguendo altri applicativi che usano wget (installazione o aggiornamento di applicazioni? il Popularity Contest di Ubuntu?).
Il tuo link wget porta ad una chiave gpg degli archivi ufficiali di Ubuntu.... direi che puoi stare tranquillo. Verifica il comando mentre non stai installando applicazioni o disabilitando il Popularity contest.
Ti piace questo commento?
0 
0
mmmh no...direi che mi hai un po' frainteso, cercherò di spiegare meglio il mio punto di vista:
innanzitutto uno dei link che mi hai chiesto è http://invisiblethingslab.com/resources/misc09/smm_cache_fun.pdf (attacco alla mem. SMM)...per quanto riguarda Security focus non posso linkartelo, ma se vai su "Vulnerabilities" e cerchi "Linux" vedrai quello di cui stavo parlando. Phrack Mag. invece è offline da un po' (non so se li hai mai letti ad ogni modo qui' Wikipedia ne parla http://en.wikipedia.org/wiki/Phrack)..
(ma queste sono le cose più stupide che mi vengono in mente)
Indubbiamente è più sicuro vivere in Italia che in Afghanistan
...ma occhio che io non ho detto che usando Linux o usando Windows si è esposti nello stesso modo ad infezioni...quello che in realtà volevo dire è che i virus per linux sono pochi per una semplice "scelta progettuale" di chi scrive i virus...un virus di Windows ha più probabilità di fare danni (per via del numero di sistemi windows presenti), no?
Indubbiamente ci sono delle scelte progettuali di windows che fanno sicuramente discutere...così come, secondo me, ce ne sono per Linux...
Non ho capito a che serve questa propaganda ad APT ...io non ho mai detto il contrario
Non lo metto assolutamente in dubbio...però ovviamente passa comunque del tempo. Voglio dire...da quando si parla di un bug nella LKML a quando la patch viene rilasciata...a quando il kernel viene pacchettizzato da quelli di ubuntu e rilasciato alla comunità!
Per carità, come dici tu,il tempo è minimo, però il mio commento riguardava il fatto che proprio in questo periodo Linux è più esposto di windows a potenziali attacchi.
Bada bene che io stavo parlando di scrivere un exploit, non di trovare un bug. L'exploit normalmente lo si scrive quando il bug è già stato scoperto...ovvio che è praticamente impossibile riuscire a dedurre un bug semplicemente leggendo i sorgenti (eppure quei pazzi della ITL ci sono riusciti...trovarono un modo di far accettare un ad un BIOS EFI un upgrade non firmato con una falla del BIOS scoperta leggendo i sorgenti
)...però, appunto, nello scrivere un exploit si è aiutati tantissimo dalla presenza dei sorgenti...i dettagli sulle vulnerabilità della microsoft sono piuttosto riservati (e ad ogni modo per scrivere l'exploit bisogna fare il reversing degli update)...viceversa i dettagli sulle vuln. di linux sono estremamente dettagliati e cmq si ha a disposizione i sorgenti che ti aiutano tantissimo...questo equivale a dire che un exploit su linux, a partire da una vulnerabilità già nota, è di gran lunga più semplice.
beh no, evidentemente non siamo d'accordo su questo punto...per me un firewall è indispensabile in ogni contesto proprio perché, in caso di bug, è uno dei pochi strumenti in grado di darti un maggior livello di sicurezza...spero di essere stato un po' più chiaro!
Ti piace questo commento?
0 
1
Ugo, per quotare i miei commenti usa [blockquote]testo da quotare[/blockquote], sostituendo le parentisi quadre con "< " e ">", così capisco quali parti sono del mio discorso e quali del tuo...
Non sapevo che Phrack fosse stato chiuso.
Secondo me è anche più difficile scriverli. Un giorno magari scriverò un articolo su questo.
Parliamone..... anzi, scrivimi un articolo che lo pubblico volentieri qui su Doxa, così facciamo una discussione interessante.
Se vuoi, puoi inviarlo usando il form
Serve per dire che uno che scrive virus prima deve introdursi nei repository, il 95% del software installato passa da lì.
I BUG, purtroppo aggiungo, di solito sono noti e ben documentati, sia che siano windows e linux (proprio per questo è sempre stato piuttosto facile scrivere exploit per windows, non facevano in tempo a scoprire una vulnerabilità che subito veniva usata). Penso ad esempio al famigerato Sasser. Spesso (questo storicamente eh? La politica di patch di Microsoft è nota) quelli per Linux vengono chiusi molto più velocemente perché la velocità di sviluppo del kernel è notevolmente superiore. Un exploit per fare danni deve avvalersi di sistemi non patchati, su Linux la finestra è brevissima.
Sui firewall. Ripeto: oggi la maggior parte degli utenti usano router che sono già firewall, il firewall software non è paragonabile neanche lontanamente ad un firewall hardware. Su Linux il firewall è già nel kernel (netfilter/iptables) e di default tutte le connessioni dall'esterno sono chiuse, quindi il firewall è piuttosto inutile. Naturalmente se uno vuole può installarselo.
Ora mi leggo il report di invisiblethinglab.
Ti piace questo commento?
0 
0
Non credo che sia stato chiuso...credo che sia un problema temporaneo (anche se va avanti già da un bel po' devo dire).
Personalmente invece non credo...anche se devo ammettere che il settore degli exploit e dei virus non è proprio il mio campo
...però io stavo parlando del caso in cui un virus riuscisse a sfruttare una vulnerabilità nota, non del caso che un utente installi un sw contenente malware..
Mi spiace ma non posso darti ragione...
http://www.microsoft.com/technet/security/bulletin/MS09-071.mspx prendi questo "security bullettin" dove vengono descritti dei problemi di sicurezza...poi vai su kernel.org e consulta il changelog...c'è una descrizione molto più dettagliata con tanto di sorgenti a corredo...
Su windows per sfruttare le vulnerabilità di cui sopra devi fare un lavoro piuttosto consistente di reversing...su Linux no...hai già tutto quello che ti serve...poi tieni presente che i problemi di sicurezza su windows vengono resi noti quando è disponibile già una patch, su linux invece se ne parla ancora prima nella LKML.
...e su questo siamo d'accordissimo
...io stavo facendo un discorso generale...e un Firewall hw è pur sempre un firewall! 
Ti piace questo commento?
0 
1
Allora stavi parlando di worm ed io non avevo capito. I virus, come ho scritto nell'articolo, devono essere esplicitamente eseguiti dall'utente.
Ugo, non è così. I bollettini Microsoft sono sicuramente più oscuri ma le vulnerabilità agli hacker sono chiarissime (spesso le sfruttano senza avvisare nessuno). L'esempio di Sasser è lampante, Microsoft non è certo entrata nei dettagli quando ha descritto la vulnerabilità, eppure dopo pochi giorni Sasser era in giro ed ha provocato moltissimi danni. Si dice che abbiano fatto un lavoro di reverse engineering sulla patch Microsoft... ma anche no, non sempre è così. Pensa ad esempio ai security contest del CanSecWest dove sistemi operativi vengono craccati in pochi minuti (fece scalpore il caso di Apple l'anno scorso, il cracker sfruttò, se non ricordo male, una falla di Safari). I cracker con cattive intenzioni, conoscendo una vulnerabilità, non la segnalano di certo al produttore del software ed anche chi non ha cattive intenzioni spesso descrive la vulnerabilità pubblicamente senza aspettare che l'azienda distribuisca una patch. Spesso Apple e Microsoft, pur essendo a conoscenza di vulnerabilità non patchano i loro prodotti e lasciano l'utente inconsapevole. A volte per essere più sicuri basterebbe avvisare gli utenti in modo che non adottino comportamenti che favoriscano un cracker. Quando una vulnerabilità è descritta pubblicamente nel changelog metti forse il cracker a conoscenza di una vulnerabilità, ma nello stesso tempo metti i produttori di distribuzioni e gli utenti nella condizione di mettersi al riparo da certi attacchi.
Devi considerare infine un aspetto non secondario, molte vulnerabilità utilizzate dai cracker non sono sul kernel ma su altri software. I repository consentono aggiornamenti di sicurezza per tutto il parco software, mentre Microsoft può metterti in sicurezza soltanto per quanto riguarda il sistema operativo ma non per le altre vulnerabilità.
Ti piace questo commento?
0 
0
uhm si, il termine "scientifico" è worm...tuttavia ormai "virus" si usa indistintamente per indicare tutti i tipi di malware...del resto come ti ho detto non è proprio il mio settore quindi mi scuserai se non uso i termini appropriati
chiariamo: io ho sempre parlato di problemi di sicurezza "annunciati" pubblicamente dagli sviluppatori...poi non metto in dubbio che ci siano ricercatori indipendenti che scovano i bug per conto loro e gli sfruttano!
se non mi mettessi a fare il reversing della patch non lo saprei...ovvio che potrei avere un intuizione e capire al volo di che si tratta se ad esempio in passato ho reversato questo componente di windows (o per qualche ragione ne conosco intimamente il funzionamento)...ma in genere non è possibile andare a tentativi...non credi?
Volendo parlare di queste problematiche sarei portato a dire che sfruttarne una di linux è più facile che per windows...
I bollettini sulla sicurezza della MS, seppur troppo vaghi, sono comprensibili per un cracker...questo è vero...sono comprensibili per me che non mi occupo troppo di queste cose
Tuttavia un conto è comprendere di che si tratta e un conto è capire come sfruttarli...
prendi "MS-CHAP Authentication Bypass Vulnerability - CVE-2009-3677" (nell'ultimo security bullettin)...okkay, c'è un problema con IAS che fa si che sia possibile fornire credenziali non corrette...come faccio a sfruttarlo?
Ti piace questo commento?
0 
0
Ma infatti, nessun rimprovero, solo che non avevo capito.
Per il resto, ripeto, non è così che agiscono i cracker. Le vulnerabilità se le trovano da soli. Se poi io so che un servizio è vulnerabile non ho bisogno di molto altro per trovarne la vulnerabilità, non è necessario il reverse engineering, si fanno dei tentativi. Esistono tutta una serie di tecniche per trovare vulnerabilità e causare crash di sistema e per nessuna di queste serve il codice sorgente.
Buon week end.
Ti piace questo commento?
0 
0
Ok, buon per loro se le trovano da soli
solo che io sto parlando di vulnerabilità rese note da parte di chi sviluppa il sistema in questione..
beh ma...ogni servizio umanamente concepibile è vulnerabile...
sicuramente non serve il sorgente...ma io non ho detto che è indispensabile, intendiamoci...ho detto che AIUTA moltissimo nello sviluppare un exploit a partire da una vulnerabilità GIà NOTA...
cmq un po' mi occupo anch'io di reversing e non ho mai sentito parlare di metodi automatizzati per trovare i bug..potresti essere più preciso? E' una cosa che è stata ipotizzata, questo si, e sicuramente sono stati pubblicati dei proof-of-concept, ma dal dire al fare...del resto un modo di procedere di tipo euristico ha un indice di affidabilità piuttosto basso...
altrettanto
Ti piace questo commento?
0 
0
Leggere il sorgente per sviluppare un exploit è una pratica assurda. Posso accettare al massimo che uno vada a cercarsi casualmente chiamate di sistema per trovare un bug. Parliamo di diverse centinaia di file e di milioni di righe di codice. I bug, sia dagli sviluppatori vengono trovati utilizzando soprattutto i debugger. I cracker, visto che di solito cercano di attaccare computer in rete utilizzano tecniche di sniffing e spoofing e programmi come hping, nmap, traceroute. Esistono poi suite che testano la sicurezza del sistema e che possono essere utilizzate anche per tentare attacchi, vedi ad esempio Metasploit framework. I migliori continuano a crearsi le loro porzioni di codice da riutilizzare in più occasioni.
L'hacking è una tecnica che ha ben poco a che fare con la lettura del codice e molto con l'intuizione ed il caso (così vengono scoperti moltissimi bug nei software).
Ti piace questo commento?
0 
0
doxa, mi dispiace ma su questa cosa non siamo proprio d'accordo...dobbiamo farcene una ragione
Tuttavia se mi continui a dire che:
Mi sa che ancora non ci stiamo capendo...
non ho detto che è una cosa "saggia" leggere il codice per trovare i bug...è un vero suicidio e io me ne rendo perfettamente conto. Io stesso quando programmo, per correggere un errore, mi affido ad un debugger...e ti sto parlando di programmi di qualche centinaio di righe di codice al massimo! Non oso immaginare quanto possa essere stupido e contro producente un modo di procedere di questo tipo in un programma di una complessità che si avvicina a quella del kernel Linux.
TUTTO QUESTO SENZA NULLA TOGLIERE AL FATTO CHE:
se una falla è GIà STATA SCOPERTA da qualcun altro e questo "qualcun altro", nel rendere pubblico il bug, mi cita anche il sorgente interessato e le modifiche atte a colmare questo bug, scrivere ll'exploit diventa un gioco da ragazzi.
SE INVECE:
qualcuno mi segnala che c'è un bug in un componente X, adduce pochi dettagli e comunque non ho la possibilità di confrontare il sorgente per capire fino in fondo di cosa si tratta....l'unica strada sensata è quella del reversing...
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=4a58579b9e4e2a35d57e6c9c8483e52f6f1b7fd6
Questo è il bug di cui ti parlavo l'altro giorno di privilege escalation...
qui c'è una delle patch che corregge quest'errore
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blobdiff;f=fs/ext4/ioctl.c;h=b63d193126dbf759236a52f075af914bc921d40a;hp=31e5ee0c858fb40ad61a505cb664b0fb3c31fe23;hb=4a58579b9e4e2a35d57e6c9c8483e52f6f1b7fd6;hpb=b436b9bef84de6893e86346d8fbf7104bc520645
Li c'è tutto quello che mi serve....è chiaro perfino per me che non sono un kernel hacker...
la funzione long ext4_ioctl -definita in /fs/ext4/ioctl.c- non riesce a gestire correttamente come secondo parametro EXT4_IOC_MOVE_EXT...mi basterebbe studiare un po' il sorgente per capire come sfruttare questa vulnerabilità, senza avere anni e anni di esperienza di reversing e senza conoscere intimamente il kernel di linux...
Mentre invece prova a prendere il bug in IAS di qualche commento fa e dimmi come faccio a sfruttarlo...
poi, per carità..ubuntu in un niente mi propone la patch da installare...e infatti tra gli aggiornamenti ubuntu mi propone già la versione aggiornata del kernel che fixa questo bug (senza sapere che ho un kernel ricompilato e non ne ho bisogno)...ma io questo non l'ho mai messo in dubbio
Ti piace questo commento?
0 
0
No, credo anch'io che non saremo mai d'accordo quindi chiudiamo il discorso qui.
Aggiungo solo che, nella creazione di exploit è più importante conoscere gli "internals" del sistema operativo, la sua struttura (quindi i suoi punti di forza e le sue debolezze) che non il codice. Anche se i sorgenti di Windows sono chiusi esiste comunque moltissima documentazione che serve per lo sviluppo di device drivers (alcuni produttori hardware dispongono dei sorgenti windows ovviamente), si parla un gran bene di Mark Russinovich e del suo Windows Internals ad esempio. L'aspetto critico rimane comunque la velocità con cui si patcha il sistema e finché i bug saranno chiusi così velocemente il problema è minimo. I problemi grossi sono nei bug che esistono da tempo, che nessuno scova ma che in teoria possono essere già conosciuti da alcuni cracker che si guardano bene dal rilevarli. Il bug debian su openssl, quello si che è stato un baco clamoroso (e nonostante il codice sorgente nessuno se n'è accorto, dimostrazione che il sorgente lo guardano davvero in pochi! 
).
Ti piace questo commento?
0 
0
fa parte della mia biblioteca già da un pezzo (edizione 4 e 5)...insieme a "Understanding linux kernel" "understanding linux VMM" "bios disassembly ninjutsu uncovered" and many others
Ti piace questo commento?
0 
1
Come accennato nell' articolo, la sicurezza in più di linux sta nei repository centralizzati (e controllati) oltre che nella buona abitudine di preferire codice aperto e sotto gli occhi di tutti (un virus opensource è una contraddizione in termini) a quello chiuso.
Ti piace questo commento?
0 
0
mi pare che sia la stessa cosa successa qualche tempo fa, quando alcuni utenti Apple avevano scaricato un programma craccato dalla rete, che però conteneva anche un regalino inaspettato (e non gradito)!!
Ti piace questo commento?
0 
0
Ne è scaturita una discussione molto interessante.
Non sono un tecnico ma vorrei fare una considerazione:
Ugo dice che, quando si scopre un bug di linux (e tutto il resto collegato) si rende pubblico con il sorgente e tutto a disposizione. Un cracker quindi sa già da dove partire per sfruttare la falla ed è facilitato nel compito.
Questo per me è vero, però non credo che gli dia un gran vantaggio. Quando la falla viene scoperta ed è critica ci si lavora subito e viene chiusa abbastanza velocemente. Il cracker contemporaneamente alla pubblicazione prepara un worm. Mettiamo che ci metta pochissimo, tipo 12 ore, deve poi distribuirlo e fare si che molti utenti ne vengano a contatto.
Da quando viene distribuito a quando viene pubblicata la patch il tempo passato potrebbe essere troppo poco e quindi il numero di utenti infetti risibile.
Il gioco vale la candela? Se io fossi un cracker piuttosto che spendere qualche giorno di lavoro per infettare pochi utenti lavorerei per trovarmi i bug da solo...
Ovviamente il mio è un ragionamento da esterno, dite pure se ha qualche magagna...
Ti piace questo commento?
0 
0
Ciao ArTax, le tue conclusioni sono molto simili alle mie (ma infine anche a quelle di Ugo che, a quanto ho capito, parlava più in linea teorica che non in pratica).
Ti piace questo commento?
0 
0
[...] Ubuntu, malware in due screensaver su Gnome-Look. Ubuntu è diventato un... [...]
Ti piace questo commento?
0 
0