Info:

twitter

Ultimi commenti: Comment feed

Tags:

Sponsor:

Archivio 2018:

Feb Gen

Archivio 2017:

Dic Nov Ott Mag Apr Mar Feb Gen

Archivio 2016:

Dic Nov Ott Ago Mag Mar Feb Gen

Archivio 2015:

Nov Ott Set Mar Gen

Archivio 2014:

Dic Nov Ott Set Lug Giu Mag Apr Gen

Archivio 2013:

Dic Nov Set Ago Lug Giu Mag Apr Feb Gen

Archivio 2012:

Dic Nov Ott Set Ago Giu Mag Apr Mar Feb Gen

Archivio 2011:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2010:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2009:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2008:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2007:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

Archivio 2006:

Dic Nov Ott Set Ago Lug Giu Mag Apr Mar Feb Gen

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): [ più recenti-  Pagina 2 di 2 ]
1. Sergio DeiCorrenti
venerdì 5 dicembre 2008 alle 10:06 PM - unknown unknown unknown
   

Posso fare il pignolo?

Correggimi se sbaglio ma "Combinando tutte le possibili permutazioni si ottengono 12 tipi diversi di malware": come puoi pensare che esista un malware che non richiede interazione dell'utente ma che richiede (sempre all'utente, se no a chi?) i privilegi di amministratore?

Poi sinceramente non ho capito la [1]... A quanto ne so (e a quanto si legge) OS X non ha un AutoRun ma può al massimo prendere un'immagine e impostarla come sfondo della finestra (del CD, della ISO, etc...): tu vorresti quindi exploitare un potenziale baco nella lettura di tale immagine per eseguire codice arbitrario? (E questo lo chiameresti AutoRun?!?)

   
2. Paperino
venerdì 5 dicembre 2008 alle 10:14 PM - unknown unknown unknown
   

@Sergio:

Posso fare il pignolo?

Certo, alla fine il post diventa più chiaro! More than welcome.

come puoi pensare che esista un malware che non richiede interazione dell'utente ma che richiede (sempre all'utente, se no a chi?) i privilegi di amministratore

Pensa ad un worm che sfrutta un baco di un servizio di sistema per installare un rootkit. Per installare un rootkit ci vogliono i permessi di amministratore che guadagni automaticamente sfruttando la vulnerabilità del servizio di sistema (ovviamente se il servizio di sistema gira come super-user). Esempio reale http://en.wikipedia.org/wiki/Sasser_(computer_worm)

Per quanto riguarda l'autorun hai ragione, sono stato poco chiaro.

tu vorresti quindi exploitare un potenziale baco nella lettura di tale immagine per eseguire codice arbitrario?

Sono poco informato davvero, ma il link che ho letto parla di lancio automatico di file PDF. Se sfruttare un baco nella lettura delle immagini è difficile ma fattibile, immagino che un PDF tra form e javascript sia più facilmente sfruttabile.

   
3. sirus
venerdì 5 dicembre 2008 alle 10:17 PM - unknown unknown unknown
   

30 minuti di applausi...

   
4. Sergio DeiCorrenti
venerdì 5 dicembre 2008 alle 10:32 PM - unknown unknown unknown
   

Domanda:

Per installare un rootkit ci vogliono i permessi di amministratore che guadagni automaticamente sfruttando la vulnerabilità del servizio di sistema

Questo non rientra nell'escalation? Cmq non è imp! Era solo per capire la tua distinzione.

Sono invece più pignolo su questo

Sono poco informato davvero, ma il link che ho letto parla di lancio automatico di file PDF. Se sfruttare un baco nella lettura delle immagini è difficile ma fattibile, immagino che un PDF tra form e javascript sia più facilmente sfruttabile.

Nel link però si parla di DoS e system access (e che vorrà di'?!) ma non di arbitrary code execution...

Se da un lato si deve cazziare Safari per le sue igenuità (che grazie al cielo -parlo dell'apertura automatica dei file- possono essere disabilitate) dall'altro personalmente lodo Mac OS per non aver mai implementato l'AutoRun.

Un'altra cosa mi ha lasciato perplesso

In generale scrivere software per Mac è tecnicamente più difficile

A cosa ti riferisci esattamente? (curiosità, visto che sei piuttosto tecnico....)

   
5. EnricoC.
venerdì 5 dicembre 2008 alle 10:40 PM - unknown unknown unknown
   

Bello, bello e ancora bello.

Finalmente un'articolo che se venisse letto da una persona esterna che non ti conosce, quest'ultima non riuscirebbe a capire che lavori per Microsoft (a differenza forse di altri articoli).

Post da incorniciare. Andrebbe linkato ogni volta su punto-informatico quando spunta un commento di FUD, in entrambe "le direzioni", sia esso FUD MSfanboy o FUD Applefanboy

Per completezza vi linko anche quest'articolo state-of-the-art di Guido Lodice: Perchè non serve (quasi mai) un antivirus su GNU/Linux.

   
6. Barack dovella
venerdì 5 dicembre 2008 alle 10:42 PM - unknown unknown unknown
   

   
7. Barack dovella
venerdì 5 dicembre 2008 alle 10:43 PM - unknown unknown unknown
   

@enrici c,

 

che c'azzecca l hardware e la ram ?

   
8. EnricoC.
venerdì 5 dicembre 2008 alle 10:47 PM - unknown unknown unknown
   

che c'azzecca l hardware e la ram ?

Beh mi sembra ovvio. Che leggendo entrambi gli articoli che ho linkato si capisce perfettamente da che parte pende Paperino. Già un articolo che titola "Vista annoyances resolved. Mac annoyances still not" è un brutto biglietto da visita per l'imparzialità.

Comunque chiudiamo qui subito non voglio parlare di questo. Complimenti per l'articolo e STOP

   
9. Paperino
venerdì 5 dicembre 2008 alle 10:56 PM - unknown unknown unknown
   

@Sergio:

Questo non rientra nell'escalation?

Per escalation intendo un processo che tu lanci con le credenziali "ridotte" ma in qualche modo riesce a fare escalation. Pensa ad un applicazione scaricata da internet che sfrutta un baco nel driver della webcam che gira in kernel mode. Molto raro, ma teoricamente possibile.

Nel link però si parla di DoS e system access (e che vorrà di'?!) ma non di arbitrary code execution...

Secunia recita: A vulnerability has been reported in LibTIFF, which can be exploited by malicious people to cause a DoS (Denial of Service) or to potentially compromise a user's system. La regola del pollice (rule of thumb) dice che un buffer overflow/underflow porta automaticamente all'esecuzione di qualcosa di non voluto: se quel qualcosa è prettamente casuale ti ritrovi con un crash del sistema (DoS), se in qualche modo riesci a controllare quel qualcosa hai esecuzione di codice arbitrario. Quasi tutte le DoS di questo tipo si concludono con la frase "potential code execution" o variazione sul tema. Poi c'è chi riesce a sfruttare le vulnerabilità più innocue come i null pointer exception per creare un trampolino di lancio per vulnerabilità più pericolose. Sto parlando di casi reali già accaduti.

dall'altro personalmente lodo Mac OS per non aver mai implementato l'AutoRun.

Concordo, molte grane in meno.

A cosa ti riferisci esattamente?

Stavo cercando come si scrive un keylogger "benigno" per mac. Nel mondo windows basta scrivere un global keyboard hook (ovviamente con tutti i paletti del caso) e basta cercare con google "global keyboard hook" per trovare qualche migliaio di risultati con pezzi di codice pronto all'uso. Insomma se vuoi scrivere software/malware per Windows non hai che l'imbarazzo della scelta, ma come ho più volte sottolineato l'impressione potrebbe derivare dalla mia scarsa conoscenza della piattaforma.

   
10. Paperino
venerdì 5 dicembre 2008 alle 11:01 PM - unknown unknown unknown
   

@EnricoC:

un antivirus per Linux non serve per un motivo semplice e banale. L'unico virus che può funzionare (forse) su Linux è quello fornito di codice sorgente e istruzioni di compilazione. Debian usa i .DEB, red-hat gli RPM, tizio usa KDE, caio usa Gnome, sempronio si è creato un desktop environment ad hoc miscelando Gnome e KDE.

In queste condizioni scrivere software che funzioni su una macchina che non sia quella di sviluppo è già abbastanza challenging. Insomma l'approccio Mac, ma applicato all'ennesima potenza.

   
11. EnricoC.
venerdì 5 dicembre 2008 alle 11:02 PM - unknown unknown unknown
   

@ Paperino

Stavo cercando come si scrive un keylogger "benigno" per mac

Se vuoi te lo scrivo io in Java. Leggero e ottimo per l'hiding vero?

   
12. EnricoC.
venerdì 5 dicembre 2008 alle 11:06 PM - unknown unknown unknown
   

In queste condizioni scrivere software che funzioni su una macchina che non sia quella di sviluppo è già abbastanza challenging. Insomma l'approccio Mac, ma applicato all'ennesima potenza.

Proprio quello che sostengo io :). Però la "larga" diffusione di Ubuntu potrebbe far affievolire questa motivazione in futuro (se non già adesso).

   
13. Sergio DeiCorrenti
venerdì 5 dicembre 2008 alle 11:08 PM - unknown unknown unknown
   

Stavo cercando come si scrive un keylogger "benigno" per mac. Nel mondo windows basta scrivere un global keyboard hook (ovviamente con tutti i paletti del caso) e basta cercare con google "global keyboard hook" per trovare qualche migliaio di risultati con pezzi di codice pronto all'uso.

Guarda, se cerchi su VersionTracker ce n'è uno di sicuro (o almeno c'era qualche anno fa...)... se non lo hanno aggiornato è probabilmente per OS X (PowerPC). Se vuoi scriverne uno tu.... purtroppo non so aiutarti

scrivere software/malware per Windows non hai che l'imbarazzo della scelta, ma come ho più volte sottolineato l'impressione potrebbe derivare dalla mia scarsa conoscenza della piattaforma.

Sinceramente non ho mai trovato siti dedicati a codice "maligno" (passami il termine) su OS X mentre, come dici tu, "pullulano" quelli per Windows.

Per scrivere codice "normale" invece di siti ce ne sono anche per OS X.

   
14. Paperino
venerdì 5 dicembre 2008 alle 11:16 PM - unknown unknown unknown
   

Il mio era solo un esempio, volevo capire come funzionano gli hook di sistema in OSX e credimi ho trovato pochissima roba. Questo però non vuol dire che non si può fare.

   
15. Paperino
venerdì 5 dicembre 2008 alle 11:27 PM - unknown unknown unknown
   

@EnricoC:

Però la "larga" diffusione di Ubuntu potrebbe far affievolire questa motivazione in futuro

Il problema è che anche se Linux fosse solo Ubuntu avresti: Ubuntu/Kubuntu/Edubuntu/Xubuntu + qualche migliaio di customizzazioni fatte in casa. Non è remunerativo.

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