Malware e architettura

Da tempo speravo di dedicare un post alla questione malware, la cui definizione è più fumosa di quanto si possa immaginare. Si è trovato in difficoltà persino il grande Mark Russinovich quando ha dovuto decidere se la protezione usata da Sony fosse un rootkit o meno. L’approccio generale su cui una buona maggioranza di persone sembra essere d’accordo è una questione praticamente tecnica.

Ad esempio se una applicazione nasconde dei file al sistema è di fatto un rootkit, indipendentemente dal fatto che l’applicazione lo faccia per il bene dell’ubatteriofagotente o meno. Notare la sottile differenza tra “nascondere dei file al sistema” e “nascondere dei file all’utente”.

La stessa cosa si potrebbe fare per definire malware: tutto ciò che gira di “nascosto” rispetto all’utente. Wikipedia è molto chiara:

Malware, a portmanteau from the words malicious and software, is software designed to infiltrate or damage a computer system without the owner's informed consent.

Una volta definito cos’è il malware possiamo cominciare a fare una distinzione tra due tipi fondamentali di malware:

  • malware che richiede l’interazione dell’utente con un inganno (clicca qui per vedere il porno)
  • malware che non richiede nessuna interazione dell’utente

Questo va combinato con un’altra distinzione:

  • malware che si replica
  • malware “statico”

Ed infine un’altra ancora, molto artificiale ma valida:

  • malware che richiede permessi amministrativi per portare a compimento la sua opera
  • malware che non richiede nessun permesso speciale
  • malware in grado di fare escalation di privilegi

Combinando tutte le possibili permutazioni si ottengono 12 tipi diversi di malware. Però con l’espediente della suddivisione si tratterà di capire cosa si può fare discutendo un numero inferiore di casi.

Nel caso della prima distinzione, un OS può fare ben poco. Di fronte all’intenzione dell’utente di eseguire un “free porn” il sistema non ha nessun’altra scelta che eseguire. Questo indipendentemente dal sistema. Quindi qualsiasi affermazione che *nix sia sotto questo aspetto migliore di Windows è palesemente falsa. Per il malware che non richiede nessuna interazione dell’utente (worm) si può fare qualcosa (ad esempio usando un processo di scrittura del software che riduca la possibilità di bachi wormable) ma l’utente ha ancora un grosso peso nell’ecosistema. Se non installa tutte le patch disponibili in maniera tempestiva la battaglia è persa. TUTTE le più grandi pandemie informatiche degli ultimi anni sono state causate da bachi già sistemati diverse settimane prima delle prime avvisaglie di problemi.

Anche nel secondo caso un OS può fare molto poco. L’unica strategia è quella di contenere in qualche modo l’infezione riducendo in qualche modo la superficie di attacco. In questo senso Vista/*nix è molto meglio di XP nella configurazione “standard”. Vale la pena notare che “configurazione standard” non ha niente a che vedere con le “capacità del sistema” (le tanto fomentate fondamenta). Ovvero loggarsi sotto Linux come root ha gli stessi effetti di loggarsi sotto XP come amministratore, ma con una fondamentale differenza: per XP loggarsi come amministratore è l’impostazione di default per motivi totalmente irrilevanti al contenuto di questo post. Un esempio lampante dell’impossibilità dell’OS nel limitare i danni è tutto quel malware che sfrutta le macro di Office/OpenOffice per diffondersi ad altri documenti.

Nel terzo caso però un OS ed i setting di default possono fare tutta la differenza del caso. Perché nel caso in cui il malware arrivi sul PC con l’inganno o quasi (bachi nel browser) il sistema può limitare i danni di parecchio. L’idea va all’uso di UAC (Vista/OSX/Linux) e di sandbox (IE7 su Vista, Chrome) quando si opera con applicazioni che si interfacciano con Internet, browser in primis.

Pertanto la seguente affermazione è palesemente falsa:

The Mac is designed with built-in technologies that provide protection against malicious software and security threats right out of the box.

Non solo il design di MacOS non ha niente di speciale rispetto a qualsiasi Windows/Unix/OS moderno. Ma alcuni setting di default sono molto spostati verso il massimo dell’usabilità rispetto alla sicurezza e il pensiero va a Safari in primis per svariati motivi:

  • decisione di scaricare automaticamente i file sul desktop; basta scaricare una applicazione con l’icona di “My Computer” per gabbare alcuni utOnti
  • decisione di scompattare automaticamente i file compressi scaricati. Basta un file .zip malizioso ed un baco nel codice di scompattamento e la remote execute è servita
  • decisione di montare automaticamente i file immagine (ISO, DMG, ecc.) per lo stesso motivo di cui sopra

Questo atteggiamento ricorda tanto la funzionalità AUTORUN introdotta con Windows95: basta inserire un CD appositamente preparato per far partire l’applicazione designata. Molto comodo per gli utOnti (inserisci il CD e segui le istruzioni) ma molto molto comodo per gli scrittori di malware. Nel frattempo sono passati 13 anni e dal rilascio di Windows XP SP2 l’applicazione non parte più automaticamente senza l’intervento dell’utente. Apple con i setting di default di Safari fa quasi[1] la stessa cosa di Windows 95.

Un’ultima nota storica: il malware è cambiato tantissimo negli ultimi 25 anni. Parlare di 160 milioni di miliardi di virus oltre ad essere storicamente irrilevante è perlomeno inaccurato. Però vorrei spezzare una lancia in favore della piattaforma Apple: qualcuno dice che scrivere malware per MacOS è tecnicamente più difficile. Tale affermazione – per le mie impressioni personali – pecca per difetto. In generale scrivere software per Mac è tecnicamente più difficile e quindi lo è anche scrivere malware. Ho provato a cercare informazioni su come scrivere un Keyboard hook per Mac ed i risultati sono desolanti: non un singolo pezzo di codice che si possa copia/incollare, ma forse sono solo incapace di cercare nella maniera giusta

Rimango dell’idea che un antivirus sia inutile sia su Mac che su Windows se e solo se si usa la testa. Se si passa a Mac per smettere di usarla è un altro paio di maniche.

-quack


[1] Non ho ancora esplorato le possibilità di AutoRun di MacOS però questo sembra promettente: MacOSX does allow you to set a background image (you can even use a pdf) so you could create a nice welcome screen at least. (fonte)

Potrebbero interessarti anche:
Commenti (45): [ Pagina 1 di 2  - più vecchi ]
16. wisher
venerdì 5 dicembre 2008 alle 11:41 PM - unknown unknown unknown
   

Come ho già scritto in precedenza, ormai gli attacchi ai vari sistemi operativi (Ben configurati, s'intende) sono davvero ostici da portare a termine, senza la "collaborazione" dell'utonto.

Purtroppo si sta diffondendo del malware che sfrutta le social networks per diffondersi. Vista la natura delle social network gli effetti potrebbero essere devastanti e addirittura potrebbero essere messi a rischio i dati che l'utente ha sulla rete sociale, rendendo di fatto inutile ogni protezione a livello di sistema. Che sia ora di avere una nuova tipologia di malware?

In questo mio post spiego un po' più nel dettaglio la mia : utvv.blogspot.com/.../...ing-towards-facebook.html

   
17. 0verture
sabato 6 dicembre 2008 alle 12:22 AM - unknown unknown unknown
   

A proposito di codici maligni (virus, malware, worm, trovatelo voi il termine più esatto) stavo pensando ad una cosa che secondo me potrebbe fare molto danno ad un sistema *nix usato da una persona senza troppo cervello.

 

Se un programma (che ovviamente andrà avviato a mano, ma ci vuole poco a botte di free porn) facesse queste cose:

- modifica la path dell'utente corrente e gli nasconde da qualche parte una cartella che avrà funzione analoga a /sbin

- in questa nuova cartella ci butta una copia modificata di sudo (ed eventuali simili per le applicazioni grafiche, sempre ammesso che non richiamino direttamente lo stesso sudo) atta a keyloggare e memorizzare la pass digitata

- modifica gli alias dello stesso utente e fa in modo che quando questo richiama sudo in realtà punta a quello nuovo

- poi inscena qualche finto casino così da spaventare l'utente e spingerlo ad indagare come root guarda caso chiamando sudo

Una cosa del genere potrebbe portare ad una scalata di privilegi capace di portare a casini senza fine alla faccia delle "solide e mistiche fondamenta unix" ? O esistono dei sistemi di controllo che verificano l'autenticità di sudo ?

   
18. Blackstorm
sabato 6 dicembre 2008 alle 12:54 AM - unknown unknown unknown
   

@Overture:

Mi risulta però che sudo non sia un alias. Ossia, esattamente cosa andresti a sostituire? E dove nascondi la dir sbin farlocca? Perchè se non hai i diritti di root non riesci certo a modificare dir di sistema. Forse può esserci una variante. una semplice applicazione che faccia promptare una shell di terminale, nella quale si richiede la pwd di root, una volta ottenuto eseguire in maniera silent la creazione di un utente root alternativo e andare a sostituitre con quelle credenziali il sudo di cui sopra. Ma onestamente la fattibilità mi pare un poco azzardata....

   
19. EnricoC.
sabato 6 dicembre 2008 alle 12:59 AM - unknown unknown unknown
   

@ Overture

Buffo, davvero buffo.

- modifica la path dell'utente corrente e gli nasconde da qualche parte una cartella che avrà funzione analoga a /sbin

Ah si? E come faresti di grazia? Sono molto interessato. Scommetto che mi vai a modificare /etc/profile. Blackstorm ti ha già risposto

   
20. 0verture
sabato 6 dicembre 2008 alle 1:33 AM - unknown unknown unknown
   

Fondamentalmente l'idea è fare tutto dentro le cartelle del pirla che cerca free porn quindi sia gli alias che la path modificati sarebbero quelli di questo utente ed il finto sudo sarebbe in una cartella sempre nella home di codesto personaggio (per semplicità la chiamo ~/.fakebin ma è ovvio che in un contesto reale potrebbe essere anche una cartella già esistente tipo .gnome).

 

Una cosa che mi pare di ricordare della path è che la ricerca del binario è legata all'ordine con il quale vengono segnalate le cartelle dentro questa voce quindi basterebbe anteporre la finta cartella con i binari tarocchi a quelli originali così che in fase di digitazione di un comando:

sudo --> fake sudo in fakebin

ls --> ls in /bin

 

Di fatto l'attacco si svilupperebbe in due tempi: nella zona del pirla per preparare il terreno e dopo, una volta catturata la pass, oltre così da poter fregare anche gli altri utenti ed il sistema stesso. In fin dei conti le catene si spezzano dall'anello più debole...

Nell'ordine troviamo il pirla che invece di lavorare cerca free porn, alias e path della bash locale (i quali non si lamentano di certo se si cercano di modificarli e se un alias punta a programmi esterni a /bin e /sbin), eventualmente in azienda un admin pirla che suda senza pensarci due volte ed infine il mondo (furti di dati, accedendo come root in archivi a parte possibilmente non criptati -cosa possibilissima-, zombie...)

   
21. Enrico FOLBlog
sabato 6 dicembre 2008 alle 9:21 AM - unknown unknown unknown
   

@Paperino

Ubuntu/Kubuntu/Edubuntu/Xubuntu + qualche migliaio di customizzazioni fatte in casa. Non è remunerativo.

In realtà forse basterebbe scrivere qualcosa che vada bene per Debian, perchè funzioni anche su tutti i derivati. O sbaglio?

Avrei alcune domande da fare.

@whisher

Purtroppo si sta diffondendo del malware che sfrutta le social networks per diffondersi.

Il tallone d'Achille in quel caso mi sembra il browser.
Non è sufficiente rendere più robusti e meno Safariani i browser (vedi protected mode IE su Vista UACked o Chrome Iron sandbox)?

@Paperino

1) inserire codice in un'immagine è roba che anche un alunno di terza elementare sa fare.
Mi chiedo se è eltrettanto semplice poterlo utilizzare quel codice.
E se sia possibile installare un malware in una certa maniera, per poi fargli eseguire "quel" codice, magari anche con privilegi diversi.
Esempio: installo un malware che non fa nulla senza "quel codice"; l'installazione non richiede privilegi di admin; il codice nascosto nell'immagine invece si; ma l'elevazione dei privolegi sarebbe richiesta al momento dell'apertura dell'immagine.
Si potrebbe indurre l'utonto a concedere l'elevazione dicendo che l'immagine è protetta (in qualche modo).

2) Vista 64bit è più sicuro di Vista 32bit?

 

@EnricoC

Ah si? E come faresti di grazia? Sono molto interessato.

Sei insopportabile.
Non riesci a rispondere in grazia di Dio nemmeno a chi fa una domanda.
Pensi veramente che tutti siano come te.

Blackstorm ti ha già risposto

E allora mi spieghi l'utilità di questa tua indisponente risposta se non quella di fare un po' di trolling?
Su persone come te, ho scritto un articolo.
Cieco come sei hai avuto anche il coraggio di commentarlo, ovviamente sempre dall'alto della tua cattedra e sempre con la tua solita spocchia.
Possibile che non ci sia discussione che non tenti di rovinare con i tuoi interventi inutili e provocatori? Non c'è tua domanda che non sia un tentativo di glorificare, a volte in modi anche ridicolmente bizzarri, qualsiasi cosa non-Microsoft.
Ma non hai altro da fare?

   
22. sirus
sabato 6 dicembre 2008 alle 9:31 AM - unknown unknown unknown
   

Per "l'attacco" pensato da Overture non serve neppure replicare l'intera directory /sbin, credo sia sufficiente agire sugli alias impostabili nel file ~/.bashrc presente nella home di tutti gli utenti. Considerando che su Ubuntu tutti utilizzano l'utente creato in fase di installazione (ossia quello che una volta inserita la password ha la possibilità di fare tutto) potrebbe rivelarsi piuttosto dannoso.

Ad ogni modo, come sempre, contro l'ignoranza dell'utente non c'è nulla da fare e soprattutto non c'è sistema operativo che tenga.

   
23. Sergio DeiCorrenti
sabato 6 dicembre 2008 alle 10:05 AM - unknown unknown unknown
   
   
24. Gabriele
sabato 6 dicembre 2008 alle 10:12 AM - unknown unknown unknown
   

@0verture

L'attacco che hai prospettato è fattibile.

Certo che se si ha a disposizione un utente pollo e un "admin pirla" il SO non c'entra nulla.

La differenza la fa

1. Il fatto che i privilegi di amministratore siano usati solo quando necessario e solo da personale che si suppone sappia cosa fa

Questo in *NIX esiste da trent'anni, con Microsoft è arrivato in parte con Vista (e tristissimamente l'UAC si può disabilitare). Notare che di default non ci si può loggare come root dall'interfaccia grafica in molti DE, nè fare accesso come root con SSH. A casa mia si dice che il mal voluto non è mai troppo

2. Il software che viene da un repository di una distribuzione è firmato crittograficamente. Nulla impedisce all'amministratore di aggiungere repositories di provenienza dubbia, ma si ricade nel punto 1.

In più vieni avvertito quando installi qualcosa da un repository che non firma i pacchetti o di cui l'amministratore non abbia dichiarato affidabile la chiave. Se accetti esplicitamente di installare il software cavoli tuoi. (vedi punto 1.)

Ovviamente questo non ha un corrispettivo nel mondo Windows, tranne che per gli updates, che sono firmati e dovrebbero provenire da fonte sicura (mi fido della documentazione...).

3. I servizi girano al livello minimo di privilegi e lasciano i privilegi di superutente appena possibile. Questo chiaramente non vuol dire che non sia possibile fare privilege escalation, ma solo che l'impostazione è sicura.

Anche qui Vista avrà migliorato qualcosa, in XP è un vero colabrodo

4. C'è qualcuno competente che ha accesso ai software, per dare un'occhiata a cosa fa il sorgente. Se un amministratore è paranoico può anche fare tutto in casa, controllare il sorgente e ricompilarlo.

5. La protezione di rete è più facile. L'amministratore può configurare a piacimento un firewall software come iptables senza dover ricorrere a tool di terze parti a codice chiuso che funzioneranno anche ma mi devo fidare dell'oste che dice che il vino è buono

Ora fino a XP e Windows Server2003 le impostazioni di default sono molto permissive, tutti in sostanza possono fare tutto. Tutti scrivono nel registro, anche i non amministratori. Tutti o quasi possono modificare i files di sistema.

Certo posso io amministratore paranoico tappare qualche buco ma il sistema operativo è costruito in un modo che non mi permette troppa sicurezza.

In Vista qualcosa è cambiato e mi auguro che la strada venga perseguita senza un occhio di riguardo al malware di cui al post che ... poverino, gli si rompe la backward compatibility

   
25. Phenix
sabato 6 dicembre 2008 alle 10:47 AM - unknown unknown unknown
   

30 minuti di applausi...

 Sottoscrivo! Bellissimo intervento Paperino!

P.S.: Il 30 minuti di applausi è preso da Fantozzi?

   
26. Enrico FOLBlog
sabato 6 dicembre 2008 alle 10:52 AM - unknown unknown unknown
   

@Gabriele

In più vieni avvertito quando installi qualcosa da un repository che non firma i pacchetti o di cui l'amministratore non abbia dichiarato affidabile la chiave. Se accetti esplicitamente di installare il software cavoli tuoi. (vedi punto 1.)

Ovviamente questo non ha un corrispettivo nel mondo Windows

Mi sono interrogato sul motivo.
Tu pensi sia veramente fattibile?
Chi deve "certificare la qualità" dell'applicazione? Microsoft (perchè il s/o è suo) o chi altri?
Sinceramente troverei la cosa inaccettabile, per gli stessi motivi per cui trovo inaccettabile la politica di Apple relativamente alle applicazioni su AppStore, il killswitch etc.
Repository e certificazione di affidabilità vanno bene solo ina ambiente opensource dove non c'è "uno che decide per tutti" e chi ha questo compito è severamente controllato dal resto della comunità.

C'è qualche lacuna nel mio ragionamento?

@EnricoC

Gabriele:

@0verture

L'attacco che hai prospettato è fattibile.

Sirus:

Per "l'attacco" pensato da Overture non serve neppure replicare l'intera directory /sbin

A naso dovresti aver fatto un bel botto a cadere dal pulpito sul quale ti eri auto-innalzato?
Qualcosa di rotto? O, come sempre, solo tanto rumore per nulla?

 

   
27. Enrico FOLBlog
sabato 6 dicembre 2008 alle 10:53 AM - unknown unknown unknown
   

@Paperino

Mi scuso per averlo dato per scontato (ci hai abituati troppo bene): complimenti per il post anche da parte mia.

   
28. Gabriele
sabato 6 dicembre 2008 alle 11:53 AM - unknown unknown unknown
   

C'è qualche lacuna nel mio ragionamento?

Direi proprio di sì.

Non viene certificata la "qualità" dell'applicazione ma il fatto che sia proprio quella e non una versione "taroccata"

Nessuno ti obbliga a scaricare/usare quella applicazione ma vorresti essere sicuro che ciò che installi sia proprio ciò che volevi.

Se una applicazione non è pacchettizzata ti puoi proporre come mantainer del pacchetto, ossia colui che compila l'applicazione e costruisce un "pacchetto" che si installi in quella distribuzione.

Nulla impedisce a chi produce software di distribuire anche l'hash md5 e pacchetti crittografati, anche sotto Windows. Però non tutti lo fanno.

Secondo me sarebbe fattibile anche in ambiente windows con delle api aperte che permettano di installare/disinstallare applicazioni. Possibilmente integrate con un sistema di controllo degli aggiornamenti centralizzato.

Ossia io produttore del software X uso le api di MS per installarmi sul sistema e dichiaro come controllare se ci sono aggiornamenti. Questo ovviamente faciliterebbe anche la disinstallazione dato che il sistema dovrebbe tenere traccia delle modifiche fatte.

Chairamente funzionerebbe solo se le API fossero davvero aperte, non sotto licenza "ti prometto che se le usi non ti fo causa per violazione di brevetti, ma mi riservo il diritto di cambiare idea".

Inoltre l'accesso alle API dovrebbe essere facile da implementare anche per il programmatore della domenica, per esempio integrato nei msi.

My 2 cents

   
29. Enrico FOLBlog
sabato 6 dicembre 2008 alle 12:52 PM - unknown unknown unknown
   

@Gabriele

Direi proprio di sì.

Non viene certificata la "qualità" dell'applicazione ma il fatto che sia proprio quella e non una versione "taroccata"

Chiarissimo, grazie.

Secondo me sarebbe fattibile anche in ambiente windows con delle api aperte che permettano di installare/disinstallare applicazioni. Possibilmente integrate con un sistema di controllo degli aggiornamenti centralizzato.

Le mie perplessità riguardano il punto evidenziato.
API aperte non significa introdurre un punto di vulnerabilità (o delle facilitazioni in tal senso)?
Non scordiamoci che, in attesa venga realizzato il s/o perfetto, la piattaforma più diffusa sarà sempre il bersaglio preferito da chi sviluppa malware.

Ossia io produttore del software X uso le api di MS per installarmi sul sistema e dichiaro come controllare se ci sono aggiornamenti.

Se non ho capito male con Windows 7 sarà così.
Ho il dubbio che questa possibilità se esista già con Vista o meno.

   
30. Enrico FOLBlog
sabato 6 dicembre 2008 alle 12:54 PM - unknown unknown unknown
   

Copia incolla mal riuscito:

Ho il dubbio che questa possibilità se esista già con Vista o meno.

Ho il dubbio se questa possibilità esista già con Vista o meno.

   
31. Straf
sabato 6 dicembre 2008 alle 1:07 PM - unknown unknown unknown
   

Ciao Paperino,

l'autorun su Mac esisteva (fino alla 9.x), ed era una "feature" legata a QuickTime. L'autorun è stato fortunatamente eliminato da Mac OS X.

kb.adobe.com/.../viewContent.do

Qualche altro elemento utile alla discussione:

1. Safari salva di default sul Desktop i file scaricati fino alla 10.4. Dalla 10.5, la cartella di default è diventata /Users/(utente)/Downloads. Non so cosa faccia Safari su Windows.

2. OS X 10.5 dispone di un meccanismo di quarantena per i file scaricati da Internet. Viene proposto un avviso la prima volta che si tenta di eseguire un'applicazione che proviene dall'esterno.

A un curioso come te può interessare questo:

Mac OS X Security Configuration (PDF)

Spero di essere stato utile.

Ciao!

Gabriele "Straf" Falcioni

   
32. EnricoC.
sabato 6 dicembre 2008 alle 1:08 PM - unknown unknown unknown
   

@ Enrico FOLBlog

Guarda che il mio tono non era assolutamente offensivo. Penso (e spero) che Overture l'abbia capito.

Certo che sei veramente l'avvocato difensore di sto .... .Preoccupati degli affaracci tuoi invece di intervenire sempre con le tue frasi in latino da intellettuale spocchioso

@ Overture

Forse avevo capito male, intendevi un attacco esterno o scaricando un programma con l'autorizzazione dell'utente? Pensavo volessi fare danni ai file ownati da root direttamente, forse ho capito male.

No perchè forse qui non è chiara una cosa (o forse si). Con l'autorizzazione dell'utente su qualsiasi S.O. puoi fare i danni che vuoi. Anche su Ubuntu ad esempio con un esemplice eseguibile puoi tarpare tutta la HOME dell'utente quindi il discorso ci può stare (sempre se l'utente è un utOnto).

Precisazione. sudo sta in /usr/bin non in /usr/sbin. L'idea da te prospettata si può fare perchè basta modificare $HOME/.bash_profile e sostituendo due semplici stringhe:

PATH=$HOME/fakebin:$PATH

export PATH

a questo punto basta piazzare un fake sudo nella fakebin dell'utente e chmoddarlo come a+x. All'interno del fake sudo poi puoi sbizzarrirti..

E' anche per questo che RHEL non utilizza sudo di default (è installato ma non abilitato). E' comodo ma troppo pericoloso

   
33. Enrico FOLBlog
sabato 6 dicembre 2008 alle 1:37 PM - unknown unknown unknown
   

@EnricoC

Forse avevo capito male, intendevi un attacco esterno o scaricando un programma con l'autorizzazione dell'utente? Pensavo volessi fare danni ai file ownati da root direttamente, forse ho capito male
bla bla bla bla

Patacrack!
Fatto male?

E, tanto per puntualizzare, non stavo difendendo proprio nessuno.
0verture si saprà difendere benissimo da solo quando sarà il caso.
Mi divertivo ad osservare la tua propopopea, la tua boria ed il tuo solito, invariabile atteggiameto da troll.

   
34. Enrico FOLBlog
sabato 6 dicembre 2008 alle 1:40 PM - unknown unknown unknown
   

@EnricoC

scusa mentre mi sganasciavo dalle risate mi è partita qualche P di troppo.

propopopea
prosopopea


   
35. EnricoC.
sabato 6 dicembre 2008 alle 1:56 PM - unknown unknown unknown
   

Ah, dimenticavo.

Rimane comuque il fatto che se si vuole tentare un escalation del genere attraverso uno script di shell, mettiamo che questo sia un certo "InstallCodec.sh" il file dev'essere reso eseguibile dall'utente per poter sperare di fare qualche danno

@ Enrico FOLBlog

No comment XD.

   
36. 0verture
sabato 6 dicembre 2008 alle 2:33 PM - unknown unknown unknown
   

Beh il programma è chiaramente il solito client civetta che promette accesso a siti porno, versioni speciali di emule (amule in questo caso), screensaver di matrix, suonerie/sms gratis, insomma roba che si scarica al volo col browser si scompatta e si fa partire tranquillamente. Repository e firme digitali centrano poco anche perchè parliamoci chiaro, ubuntu o non ubuntu, l'idea di sources.list non è particolarmente radicata fuori dal mondo linux (e anche lì s'è diffusa in quanto via obbligata per la maggior parte degli utenti).

 

Ah proposito di ubuntu: permette di default l'accesso come root via ssh...

   
37. 0verture
sabato 6 dicembre 2008 alle 2:38 PM - unknown unknown unknown
   

Comunque se non è sudo, non vedo che problema ci sarebbe a fare lo stesso giochino con su, gksu, kdesu ecc.

I sorgenti ci sono, il 95% degli utenti anche linux, installa senza accertarsi di un bel niente, che ci vuole a fregarne una valanga e far spuntare dei sostituti dalla memoria lunga ?

   
38. Paperino
sabato 6 dicembre 2008 alle 7:32 PM - unknown unknown unknown
   

@folblog:

In realtà forse basterebbe scrivere qualcosa che vada bene per Debian, perchè funzioni anche su tutti i derivati

Il problema è che anche per attaccare Debian e derivati hai bisogno del massimo comun denominatore che è prossimo allo zero. Un malware per funzionare ha bisogno di altissima replicabilità ed è per questo che misure come l'ASLR sono molto efficaci: per il malware non interattivo è come se la user base di Windows fosse frammentata in 256 versioni diverse.

inserire codice in un'immagine è roba che anche un alunno di terza elementare sa fare.

Non sono d'accordo se per codice intendi qualcosa che sfrutti un buffer overflow. Se invece parli di un trojan che si traveste da immagine allora siamo d'accordo.

Vista 64bit è più sicuro di Vista 32bit

Su due piedi direi proprio di no. L'unica differenza la fa la firma dei driver, vedi il caso di atsiv: più un'eccezione che la regola.

@Sergio:

grazie dei link

@Gabriele:

Concordo su quasi tutto, ma il presupposto del tuo ragionamento è sbagliato:

Certo che se si ha a disposizione un utente pollo e un "admin pirla" il SO non c'entra nulla.

Nel mercato consumer utente e admin sono la stessa persona in una altissima percentuale di casi. E in quel caso se l'utente è pollo, l'admin è automaticamente pirla.

Notare che di default non ci si può loggare come root dall'interfaccia grafica in molti DE

Questo dal punto di vista della sicurezza è un punto a sfavore anziché a favore: su Windows (e immagino anche in *Nix) il vero security boundary e la sessione. Anche l'OTS authentication può in qualche modo essere crackata ad esempio facendo spoofing della finestrella di autenticazione (il finto Sudo di cui parla 0verture o una finta finestra di dialogo di richiesta password). Non sto parlando di intercettare i tasti che con il Secure Desktop è impossibile, ma di simulare graficamente e in maniera sonora la richiesta di password con una identica ma finta. Da questo punto di vista il prompt UAC di default (Mi consenta) è più sicuro di quello con password (default su *nix e BSD); in più su Vista c'è la possibilità di mitigare in maniera tombale questo tipo di attacco settando il flag della richiesta del three finger salute prima di ogni security prompt che è impossibile da spoofare.

Ovviamente questo non ha un corrispettivo nel mondo Windows

Questo non è corretto al 100% anche se dal punto di vista dell'utOnto la differenza è davvero minima. Se firmi il pacchetto di installazione che l'utente scarica da internet la finestra che ti appare quando lo lanci la prima volta è diversa a seconda del fatto se il pacchetto è firmato o meno. Purtroppo in questo caso è una questione di educazione degli utenti.

Anche qui Vista avrà migliorato qualcosa

Vista è migliorato di parecchio: molti servizi ora girano come Local Network (utente "normale") anziché Local System (root). In più ora girano in una sessione completamente separata, molto simile al Secure Desktop e non c'è modo di interagire con essi via desktop se non tramite i canali ufficiali. Su XP i servizi giravano nella stessa sessione dell'utente interattivo (Session 0) e le EoP erano molto più "facili".

C'è qualcuno competente che ha accesso ai software, per dare un'occhiata a cosa fa il sorgente.

Sono in totale disaccordo su questo punto. Se vedessi il codice che stiamo scrivendo in questi giorni che è involontariamente al limite dell'offuscazione capiresti che un amministratore, a meno che non abbia partecipato direttamente allo sviluppo, non ha le garanzie di cui parli.

Ossia io produttore del software X uso le api di MS per installarmi sul sistema e dichiaro come controllare se ci sono aggiornamenti. Questo ovviamente faciliterebbe anche la disinstallazione dato che il sistema dovrebbe tenere traccia delle modifiche fatte.

Questa cosa c'è già e si chiama Windows Installer; l'unica feature che manca è il supporto per l'automatic update. Ma ci sarebbero da raccontare così tanti aneddoti a riguardo del fantastico mondo di chi produce software per Windows che mi riservo di farlo in un prossimo post: bottomline, la soluzione è teoricamente facile, praticamente quasi impraticabile, ma prometto che ci torno.

@Straf:

Grazie dei link. Safari su Windows fino a qualche versione fa usava il desktop e davvero non saprei se usava il sistema integrato di quarantena di Windows. 

Del sistema di quarantena introdotto in 10.5 ne ero a conoscenza (mi son fatto quattro risate quando ho visto la pubblicità in cui prendevano per c*lo UAC e poi di fatto copiavano il concetto di quarantena pari-pari). Sicuramente mitiga di parecchio ma non è una soluzione "definitiva". Se l'utente è abituato a tenere file in quarantena sul desktop uno in più potrebbe non dare nell'occhio.

@tutti: ottima discussione, grazie dei complimenti: contraccambio!

   
39. Hexaae
domenica 7 dicembre 2008 alle 6:18 AM - unknown unknown unknown
   

Belll'articolo dove che riprende l'argomento: Ma OSX è davvero sicuro by design?

www.pcalsicuro.com/.../#comment-31025

La risposta è no, anzi, Vista è più sicuro tecnicamente...

   
40. Hexaae
domenica 7 dicembre 2008 alle 6:25 AM - unknown unknown unknown
   

Ah, se qualcuno se lo fosse perso, ecco un esempio di virus in rete per MacOSX: http://it.youtube.com/watch?v=CBk0olNvFgE

Esistono esistono, come per tutti, e soprattutto si moltiplicheranno appena OSX raggiungerà percentuali rilevanti...

   
41. 0verture
domenica 7 dicembre 2008 alle 9:22 PM - unknown unknown unknown
   

Il giorno che cominceranno a diffondere in massa virus per mac osx e linux (distro tipo ubuntu) ci sarà un genocidio di imbecilli. I primi credono che osx è invulnerabile ai virus nel nome della Santa Trinità rappresentata da Stiiv, il Dio Dollaro ed il Mac mentre gli altri blaterano tanti bei discorsi sull'infallibilità del free software ma di fatto non hanno un briciolo di competenze concrete per capire esattamente come comportarsi senza un "aspira caccole" marchiato norton, eset o che altro.

   
42. Paperino
domenica 7 dicembre 2008 alle 9:31 PM - unknown unknown unknown
   

@Hexaae: direi che l'articolo di Marco è davvero complementare.

@Stefano: ho guardato il whitepaper sulla sicurezza ma mi sarebbe piaciuto qualcosa di più internal. Ad esempio l'applicazione di misure come l'ASLR, come funziona la quarantena, ecc.

   
43. evacchi
lunedì 8 dicembre 2008 alle 10:07 AM - unknown unknown unknown
   

il file dev'essere reso eseguibile dall'utente per poter sperare di fare qualche danno

fai un tar e i permessi vengono mantenuti nell'archivio; estrai et voila

   
44. 0verture
lunedì 8 dicembre 2008 alle 10:59 AM - unknown unknown unknown
   

fai un tar e i permessi vengono mantenuti nell'archivio; estrai et voila

E "stranamente" quando scarichi sono sempre in tar

   
45. Hexaae
lunedì 8 dicembre 2008 alle 10:20 PM - unknown unknown unknown
   

...e di sandbox (IE7 su Vista, Chrome)...

Scusate, ma Chrome non ha una sua sandbox built-in no? Sarò uno di quei 4 sulla terra che non l'ha mai provato (nè gli interessa farlo a dire il vero ;)).

   
[ Pagina 1 di 2  - più vecchi ]
Lascia un commento:
Commento: (clicca su questo link per gli smiley supportati; regole di ingaggio per i commenti)
(opzionale, per il Gravatar)