Quando si parla di malware su piattaforme alternative a Microsoft Windows, quindi Linux oppure OS X – tra i sistemi operativi più diffusi – si accende sempre una sorta di guerra di religione, ignorando a volte le argomentazioni tecniche a favore di molte argomentazioni di parte che fanno diventare la discussione più una tifoseria da stadio che non un confronto costruttivo.
La realtà dei fatti – condivisa da chiunque conosca tecnicamente i vari sistemi operativi – è che tutti e tre i sistemi operativi sono a rischio malware, sebbene Windows sia ampiamente più vulnerabile – sia chiaro, non per una questione tecnica, quanto più che per una maggiore esposizione che causa una maggiore attenzione da parte degli utenti e dei malware writer. Infatti, stando alle statistiche di Aprile 2011 pubblicate da MarketShare, Windows detiene uno share di mercato dell’88,91%, OS X del 5,40%, Linux dello 0,94%. Una differenza in punti percentuali abissale, che ben evidenzia quanto Windows possa essere un target preferenziale rispetto alle altre due piattaforme.
Una delle obiezioni che solitamente viene addotta contro l’affermazione secondo la quale i sistemi operativi Linux sarebbero vulnerabili alle infezioni è quella che qualsiasi operazione viene eseguita come utente limitato e non come root, amministratore di sistema. Di conseguenza, un eventuale malware eseguito come utente limitato non permetterebbe di fare alcun danno al sistema in sé.
Come è stato ampiamente dimostrato più volte, la realtà dei fatti è che, invece, un qualsiasi malware, pur essendo eseguito come utente limitato, può comunque danneggiare gravemente tutto ciò che riguarda la sessione dell’utente che ne rimane infetto, pur non intaccando l’integrità del sistema operativo.
Il concetto di malware si è evoluto nel tempo, codici nocivi non più interessati a rimanere quanto più possibili nascosti nel sistema o codici altamente complessi sviluppati allo scopo di mostrare le capacità individuali dei vari programmatori. I malware attuali puntano tutto sulla capacità di poter intercettare e rubare quanti più dati possibili, dati personali, identità, dati di accesso a siti di e-banking o di commercio online, password di e-mail, ftp, qualsiasi dato che è in genere facilmente intercettabile anche senza aver a disposizione diritti amministrativi. La facile accessibilità ad un numero incredibile di engine polimorfici, sia lato client che lato server, permette ai malware di poter agire spesso in maniera indisturbata agli occhi dei software antivirus, sfruttando quel lasso di tempo che intercorre tra il rilascio del malware e l’aggiornamento rilasciato per i software antivirus. E tutto da un semplice account utente limitato. Di esempi ce ne possono essere vari, da ZeuS a SpyEye, a Carberp, a Tatanga, tutti trojan che possono lavorare tranquillamente in ambiente limitato senza avere a disposizione privilegi di amministratore di sistema.
Su Linux il concetto non si sposta poi di molto. Anche su questa piattaforma, considerata al sicuro da malware, è possibile intercettare tutti questi dati con un semplice malware che catturi ad esempio le attività del browser. D’altronde, con lo stesso principio utilizzato per Windows, sia il malware che l’eventuale browser vengono solitamente eseguiti nella stessa sessione dell’utente.
Un esempio si può fare con un semplice keylogger, capace di intercettare le password digitate da tastiera. Nel caso di Windows ci sono svariati modi per poter verificare lo stato della tastiera e di eventuali tasti premuti, anche da account limitato, ad esempio sfruttando l’API GetAsyncKeyState() che può essere eseguita senza privilegi amministrativi. In Linux viene in aiuto a questo scopo il gestore grafico X Window System, che si occupa tra l’altro di fornire l’interfaccia verso tastiera e mouse. Una sua funzione in particolare, XQueryKeymap(), svolgerebbe lo stesso identico lavoro della sua equivalente funzione in Windows precedentemente citata, e tutto questo ovviamente anche da account limitato.
In altre parole un trojan, quale ad esempio il famigerato SpyEye, che già è in grado di colpire Windows anche da account limitato compromettendo il funzionamento di Firefox al fine di intercettare ciò che passa per il browser, sarebbe facilmente portabile in ambiente Linux.
Nasce qui la seconda obiezione: come ci arriva questo malware in un ambiente Linux? Obiezione alla quale è facile rispondere: tramite gli stessi canali utilizzati per la maggior parte in Windows, quindi ingegneria sociale, warez, peer 2 peer, falsi plugin per visualizzare video a luci rosse. Tutti vettori di infezione dove è l’utente spesso a fare la differenza (n.b. spesso, non sempre).
Il fatto che esistano dei repository ufficiali che semplificano la vita agli utenti Linux, i quali possono attingere direttamente a tali server e scaricare i software che vogliono in maniera sicura, non esclude il fatto che molti software e tool non siano presenti in tali repository, ma vengono scaricati dai siti ufficiali delle varie software house o dai siti web dei vari sviluppatori. Inoltre, anche in Linux esistono programmi a pagamento, e dove esistono programmi a pagamento molto facilmente esistono anche crack e keygen – un esempio può essere VMWare workstation e relativi crack/keygen. Sicuramente ci sono anche alternative gratuite a tali prodotti, tuttavia lo stesso si può dire in ambito Windows, dove però gli utenti continuano spesso a preferire crack e keygen ad alternative free. Questo è uno dei potenziali vettori di infezione in ambito Linux, già ampiamente testato in ambito Windows.
Tornando però alla prima obiezione, cioè quella di non avere la password di root e quindi l’impossibilità di danneggiare l’integrità del sistema. Quante volte gli utenti desktop di Linux, ad esempio Ubuntu oppure OpenSuse, nell’effettuare delle installazioni software, oppure delle configurazioni del sistema, fare del testing, si trovano nella necessità di inserire la propria password di root al fine di poter eseguire tali operazioni come root? Può un eventuale malware, in azione nel sistema con privilegi limitati, intercettare tale password?
La risposta è sì. Nel momento in cui l’utente digita la propria password davanti alla richiesta ad esempio del comando su, sudo, oppure davanti alla richiesta di gksudo o kdesudo, gksu, kdesu, un eventuale malware con privilegi limitati che sta interrogando lo stato della tastiera tramite XQueryKeymap() può intercettare tale password, ottenendo quindi la chiave d’accesso al sistema. Nel momento in cui viene chiesta la password di root, tale richiesta non viene in alcun modo isolata dal sistema, o filtrata, permettendo dunque a qualunque software di intercettarla.
Microsoft, in Windows Vista e Windows 7, nell’implementazione dello User Account Control e del Mandatory Integrity Control, ha implementato una tecnologia denominata User Interface Privilege Isolation, o UIPI, capace di isolare le interfacce grafiche in base ai livelli di integrità di ogni processo in esecuzione. Dei livelli di integrità ne è stato parlato già in precedenza in questo blog specificandone meglio il loro funzionamento, che è comunque riassumibile in una sorta di ulteriore suddivisione dei privilegi e permessi all’interno di uno specifico account. Ogni processo viene eseguito con uno specifico livello di integrità che può essere in generale alto, medio, basso, con il livello standard che è il medio. Nessun processo può in alcun modo avere accesso ai processi eseguiti con un livello di integrità superiore a quello del processo in questione; inoltre, scendendo di livello, aumentano le restrizioni in termini di permessi che vengono applicate al processo eseguito. Grazie alla tecnologia UIPI nessun processo può comunicare di default con le interfacce grafiche dei processi eseguiti ad un livello di integrità superiore. Questa tecnologia, implementata principalmente per la prevenzione degli shatter attack, è utilissima anche per isolare finestre importanti. Eseguendo un programma come amministratore, ad esempio, tutto ciò che verrà scritto in tale finestra non può essere intercettato da un malware eseguito in modalità utente, anche all’interno della stessa sessione. Questo perché il malware verrebbe eseguito ad un livello di integrità medio, mentre l’eventuale programma eseguito come amministratore verrebbe eseguito con un livello di integrità alto. Cosa che non avviene invece in Ubuntu Linux, come dimostrato nel video sopra pubblicato.
Inoltre anche in Windows potrebbe essere necessario inserire la password di amministratore se si sta lavorando da un account limitato e si ha bisogno di effettuare qualche modifica o installazione di qualche specifico software. Anche in Windows verrà mostrata la finestra di inserimento password, così come mostrato nel video di Ubuntu, con una differenza fondamentale: in Windows Vista e Windows 7, la finestra viene totalmente isolata dal sistema: si tratta della modalità UAC Secure Desktop, una modalità in cui tutti quanti i processi del sistema vengono sospesi ad eccezione dei processi eseguiti da account SYSTEM – quindi tutti i processi utente vengono totalmente sospesi, rimangono solo i processi critici di Windows. La finestra viene quindi totalmente isolata, così da poter permettere all’utente di inserire la propria password in sicurezza senza che eventuali malware eseguiti in modalità utente possano intercettarla. Nel video mostrato qui sotto è possibile visualizzare il comportamento di un semplice keylogger in Windows Vista e Windows 7 nelle situazioni sopra descritte.
Questo problema, mostrato sopra in Ubuntu, non è un problema di Ubuntu in sé, quanto dell’implementazione di X in generale. Un problema che è conosciuto già da svariato tempo, tanto che uno sviluppatore Debian ha dichiarato lo scorso Ottobre 2010:
If you ever believed that there is *any* way to prevent a program having access to your session to obtain root access when you use the same session to do stuff as root, you have been abused […] If there is a malicious program running in your session, you are completely screwed.
Stessa situazione verificabile anche su OpenSuse, come dimostrato nel video qui sotto:
In definitiva, sia Windows che Linux (nelle proprie incarnazioni delle varie distribuzioni) sono due ottimi sistemi operativi, entrambi con i propri pregi ed i propri difetti. Linux è da sempre un sistema rinomato per la sua solidità e stabilità; Windows, grazie al salto avanti fatto con Vista prima e 7 poi, è diventato un sistema operativo al passo con i tempi, estremamente valido e sicuro in termini tecnici. Nessuno dei due sistemi operativi è al sicuro da malware, entrambi sono ampiamente vulnerabili. Windows è maggiormente esposto, vero, paga dunque il pegno per essere il sistema operativo più diffuso al mondo. Linux è meno esposto in ambito desktop, se ne sta più tranquillo e al sicuro da potenziali attacchi di malware – non sarebbe redditizio in fondo focalizzarsi su un 1% circa di mercato e, a parte l’eventuale fama, non si avrebbe un rientro economico rapido. Ad oggi Linux è più al sicuro rispetto a Windows? A rigor di logica ovviamente sì. Linux è più sicuro di Windows? Come è possibile vedere, se si volesse attaccare il pinguino, ci sarebbero tutte le carte in regola per poterlo fare. Ad oggi, tuttavia, l’utilizzo di Linux è garanzia di una maggiore impermeabilità ai malware. L’importante è non farsi cogliere impreparati se il vento dovesse cambiare.
Ciao Marco un ottimo articolo che dimostra in definitiva come ogni OS ha una sua specifica possibile superficie di attacco.
Vorrei, prendendo in considerazione, il parametro ” > diffusione = > attenzione” far notare ai lettori che nel caso di Linux la quota in diffusione già bassa è ulteriormente frammentata in una miriade di distro per alcuni versi anche molto diverse trà di loro.
Che in fondo hanno lo scopo pratico di scoraggiare ulteriormente un eventuale malware-writer che si concentrasse su tale OS.
Quindi se è giusta la tesi che Linux è più sicuro di Windows, come si posiziona OSX rispetto allo stesso Linux ?
Per me ad un livello di sicurezza intermedio trà i 2 OS.
Non solo per la diffusione superiore,ma anche per il metodo di installazione software,ma non solo.
Ritengo infatti (ma la mia è solo una considerazione personale) anche se suffragata da un fatto e cioè che i malwares per mac sono spesso stati reperiti nei canali p2p,che l’utente Mac sia più propenso di quello linux a reperire sw ufficialmente a pagamento nel modo suddetto.
aggiungerei un’importante osservazione che rende inconfutabile la maggiore sicurezza di windows e che (non ti offendere) credo renda superfluo il pur pregevole dibattimento che hai scritto: Windows ha l’antivirus, OsX e Linux no.
E questo dice tutto!
Concludo il mio intervento ponendo un accento sulla sicurezza dei prodotti Microsoft, una vera GARANZIA per l’utente.
Parola di Winaro! ;D
Questo è FALSO.
E non mi riferisco solamente al fatto che esistono antivirus per i sistemi unix, ma anche al fatto che sono arcinote dei famosi software microsoft che sono stati rilasciati con bachi nella sicurezza grandi come case.
Tanto per citare un software che sembra non poter dare problemi: Excel è stato sfruttato nel 2011 per ottenere alcune chiavi di tokenID RSA. I malintenzionati sono riusciti benissimo nel loro intendo scoprendo **40 milioni** di tokenID che hanno poi utilizzato per attaccare la difesa USA.
Il tutto ha causato circa 70 milioni di dollari di danni.
Se questa è la GARANZIA che dà la microsoft, beh non vale ‘na cippa.
La sottile ironia del commento si scontra con l’evidenza che esistono antivirus anche per OS X e Linux 😉
Ciao 🙂
Un dubbio.
Hai spiegato benissimo come, eseguendo il browser con i diritti di amministratore, il keylogger, grazie a UIPI, è impossibilitato a catturare i tasti premuti sulla tastiera.
Mi viene da pensare che il modo più sicuro per eseguire il browser mentre si accede al sito di home banking, sia appunto quello di eseguirlo come administrator.
Ma in questo modo non sarebbe rischioso per altri tipi di attacchi ed exploit che agirebbero attraverso un processo eseguito con privilegi elevati?
Ciao,
innanzitutto grazie per l’interessantissima domanda che, effettivamente, stavo aspettando prima o poi. Temevo infatti che venissi frainteso. Hai assolutamente ragione, il mio esempio era per mostrare semplicemente come, nella stessa sessione, Windows riesca ad isolare perfettamente i vari processi basandosi sui vari livelli di integrità, bloccando qualsiasi programma eseguito a livello medio o basso di riuscire ad intercettare cosa avviene nei processi eseguiti ad un livello di integrità superiore.
Ciò non deve essere frainteso tuttavia! È assolutamente sconsigliabile eseguire un browser con privilegi di amministratore! Esistono tool ottimi per isolare il browser dal resto del sistema operativo, ad esempio Prevx SafeOnline o Trusteer Rapport, i quali prevengono altri software dall’intercettare ciò che avviene all’interno del browser stesso.
Altrimenti, altra soluzione, potrebbe essere quella di eseguire il browser utilizzato per attività sensibili – ad esempio e-banking – con un altro account, in un’altra sessione utente. Questo bloccherebbe l’eventuale malware eseguito in user mode nella sessione dell’utente infetto.
Spero di essere stato più chiaro ora 🙂
Ciao,
Marco
come ti è stato già chiesto, potresti descrivere se osx e i sistemi BSD in genere, soffrono della stessa vulnerabilità in modo analogo a linux? Qual è il modello di isolamento in osx? grazie
qualche anno fa la Rutkowska ha mostrato sul suo blog come bypassare UIPI aprendo una shell amministrativa con IL alto da un processo con IL basso, attraverso un messaggio WM_KEYDOWN.
@Francesco: ottima domanda, a cui cercherò di rispondere appena riesco a mettere mano su un Mac 🙂
@Daniele: la questione è un po più complessa. In quel caso non è che l’UIPI viene bypassato, è che c’è un comportamento di design tale che tutti i thread relativi ai processi che appartengono al processo csrss.exe non vengono filtrati dall’UIPI. Esempio che vale con il prompt dei comandi, che “appartiene” a csrss.exe tramite conhost.exe. Ecco cosa diceva la Rutkowska, che era possibile aspettare un prompt dei comandi eseguito ad alto livello e riuscire a far eseguire a tale prompt dei comandi del proprio codice arbitrario ereditando quindi un livello di integrità alto.
Di sicuro non è un comportamento che aiuta a intercettare la password di amministratore, inoltre per un utilizzo funzionale all’attacker il target (il prompt dei comandi) deve essere un processo appartenente al csrss (e lo è) e tale processo deve essere stato eseguito ad un livello di integrità alto preventivamente.
Tutto ciò non funziona se si parla di normali processi utente non appartenenti al csrss.exe, in quel caso l’UIPI funziona regolarmente
Dirò la verità, inizialmente ero un po’ titubante, il titolo e l’incipit dell’articolo mi sembravano troppo da fan di Redmond… poi però ho letto tutto e devo dire che non ti sei lasciato andare a conclusioni affrettate, in definitiva l’articolo l’ho trovato molto gradevole e interessante. 😉
In sostanza dici e provi che un software malevolo installato a livello utente può sbirciare molte cose, ovviamente. Questo è certamente vero, però mi viene da pensare che forse si considera poco un altro aspetto della faccenda: come lo becco ‘sto software?
In Linux non esistono autorun che partano senza farti svolazzare un gigantesco popup davanti alla faccia, come anche mancano gli ActiveX e ogni volta che apri una pagina con Java devi accettare di eseguire l’applet. Inoltre ad un programma ci devi dare i permessi di esecuzione a mano prima di avviarlo (a meno che non installi un deb/rpm trovato a caso, ma allora lo fai a tuo rischio). Mi sembra insomma che manchino questi e altri buchi clamorosi che permettano di venire “da fuori per dentro”. Perché certamente “da dentro per dentro” i danni li puoi fare, però a quel punto vuol dire già che qualcosa prima era andato storto!
Che ne pensi?
PS: 2 cose. Warez sotto Linux? Questa mi sembra un tantino esagerata. 😛 Lo stesso dicasi per Windows al passo coi tempi: Seven ok, ci sta, ma Vista era una versione alfa scritta malaccio e fatta per essere lenta e pesante.
Ciao!
Grazie per il commento innanzitutto 🙂 Sono contento che hai avuto la voglia di leggere tutto l’articolo, molti si sono fermati all’inizio travisando completamente il senso intero del pezzo.
Il problema dell’arrivare sul PC è un problema reale ma fino ad un certo punto: lo stesso si può dire sui sistemi operativi Windows in fondo. Il problema per gran parte è l’utente, che esegue spesso senza leggere e senza le dovute precauzioni. Il warez può diventare un problema, come lo è diventato su Windows. D’altronde, nel momento in cui c’è un programma che va acquistato, ci sarà sempre qualcuno che distribuisce eventuali crack – o finti crack, fatti appositamente per diffondere malware. Se Linux prendesse veramente piede, il problema si presenterebbe anche lì, non vedo il perché non dovrebbe presentarcisi. Purtroppo è un fenomeno che non discrimina, abbraccia tutti, indistintamente.
Neanche in Windows ora esistono autorun che partono automaticamente, e gli ActiveX subiscono delle stringenti misure di sicurezza prima di essere eseguiti.
Con Windows Vista/7, di buchi clamorosi non ne esistono poi tanti, eppure la questione malware continua ad esistere, perché il problema spesso risiede in altro.
Senza considerare eventuali file infector, come esistono per Windows possono esistere in Linux, altro vettore probabile di infezione. Tu esegui un binario che ti risulta affidabile ed in realtà non lo è – a meno che non controlli di ogni file l’eventuale hash, fatto che presuppone tu abbia conoscenza a priori dell’hash per il confronto.
Insomma, di discorsi se ne possono fare tantissimi, il problema è che vettori di infezione si possono trovare tranquillamente. Ma, come dico a fine articolo, in fondo Linux è più al sicuro ad oggi, è vero, e forse è quel piccolo angolo di paradiso al momento incontaminato dalla realtà
Le faccio prima di tutto i miei sinceri complimenti per la competenza e allo stesso tempo semplicità con cui ha trattato un argomento tecnicamente molto complesso.
Ciò premesso, c’è secondo me un aspetto che riguarda l’argomento sicurezza che non dovrebbe essere per niente sottovalutato e che richiederebbe un’approfondita analisi.
Come già accennato dall’utente Lazza nel precedente commento, le modalità con cui un sistema operativo si espone ad eventuali malware esulano in buona parte dalla pura efficienza del codice.
A dimostrazione di questo, i più famosi hacker hanno sempre affermato che il modo più efficiente per penetrare un sistema è una tecnica che faccia abbondante uso di espedienti di social engineering e non certo affidandosi solamente a eleganti logiche algoritmiche.
Lei converrà con me che lasciare quasi esclusivamente all’ignaro utente la responsabilità di scegliere quali software installare sul proprio sistema operativo, aumenta esponenzialmente le probabilità di essere esposti alle suddette tecniche di social engineering.
Si potrebbe di conseguenza affermare che la percentuale di rischio è sicuramente inferiore in tutti quei sistemi operativi che hanno adottato un metodo “controllato” per far installare del software.
Il computer non è sempre usato da un altro “computer” e gli aspetti sociologici che riguardano il suo utilizzo sono un fattore che chi produce software dovrebbe seriamente prendere in considerazione.
Con tutto ciò non voglio assolutamente criticare in nessun modo chi ha deciso di investire di più nel settore marketing e raggiungere uno share di mercato dell’89,91% piuttosto che investire in ulteriori sistemi per la sicurezza dell’utilizzatore finale (molto probabilmente, al posto loro avrei fatto la stessa cosa).
Per il resto concordo pienamente con la sua esposizione: Windows e Linux hanno più o meno le stesse quantità e qualità di problemi.
Salve,
concordo pienamente con il suo commento. Non è un caso che lentamente tutti si stiano muovendo verso l’idea di store già implementata da anni da Apple con il proprio AppStore. Un’idea di store che ai più “smanettoni” non è piaciua, un’idea che costringe a sottostare a certe regole di sviluppo molto rigide in alcuni casi, ma un’idea che riesce a garantire un buon livello di stabilità e sicurezza del sistema operativo che la utilizza
Bypassing Windows services protections
http://www.immunitysec.com/infiltrate/presentations/WindowsServicesHacking.pdf
enjoy 🙂
Che senso ha questo link? Tutto il PDF parla di come i servizi di sistema, già installati nel sistema come servizi (neanche semplicemente eseguiti da utente, sono già stati installati come servizi) “potrebbero” superare le difese di Windows Vista/7. Si chiama proprio: “Bypassing Windows services protections”
E questo che c’entra con l’articolo? 🙂
Spero vivamente che l’articolo NON SIA a scopo commerciale : “Marco è Malware Technology Specialist per Prevx, dove si occupa di analisi di software nocivi e sviluppo di nuove tecnologie per l’individuazione e rimozione dei malware” ,ovviamente per voi l’utenza GNU/Linux è inutile quanto “prevx” per linux… chi si comprerebbe Prevx se non gli users Windows? 🙂
Speravo che queste “insinuazioni” fossero lasciate fuori dal blog, visto che il livello degli articoli è ben differente dal dire “comprate Prevx” 🙂
Non ci posso credere, avevo perso di vista questo blog, da quando lo seguivo su pcalsicuro, e mi era dispiaciuto un sacco. Vedo anche tu Marco, hai “fatto carriera” e potrei dire nel frattempo anche io, che pur facendo l’amministratore di sistemi eterogenei tra loro *Win/*Nix/AS400* mi sono anche io più accentrato nella questione della IT Security. I troll continuano a imperserverare, ma questo è un “male necessario” 🙂 Detto questo mi piace questa tua analisi che condivido e cerco di far capire a molti. Da sysadmin ho avuto a più riprese la controprova che un utente limitato non è comunque una soluzione di sicurezza, perchè il suo ecosistema può venire compromesso e quindi in buona sostanza metti una falla nell’intero architrave di sistema.
P.S. cercherò di rileggermi le puntate perse… Felice 2013 a te e al tuo team!
Salve,
articolo molto interessante. Avrei alcune domande: l’implementazione di una tecnologia analoga a UIPI su ambienti Linux dove potrebbe essere fatta? Attualmente abbiamo X.org che gestisce la parte grafica e ConsoleKit-PolicyKit(e successori)/Systemd per la gestione dei permessi degli utenti, cioè “chi può fare cosa” nel sistema (va beh Systemd fa un po’ tutto…). Allora, mi chiedo, volendo realizzare un concetto simile a UIPI su Linux, dove si dovrebbe attuare? Per mantenere la stessa logica di Microsoft su ambiente Win (cioè agire sull’isolamento delle interfacce grafiche), si dovrebbe fare su X.org oppure su un singolo DE?
Ultima domanda: considerazioni sulla sicurezza di OpenBSD? Facendo riferimento ad una situazione base, con il sistema + DE appena installato e tutte le configurazioni di default, altrimenti è chiaro che bisogna contestualizzare il contesto di utilizzo.
Grazie per l’articolo e grazie in anticipo per la risposta,
Saluti
hawake