Nel precedente articolo abbiamo parlato di log, eventi e script. Siamo arrivati ad uno dei capitoli più belli, ma al tempo stesso di difficile comprensione: iniziamo a farci un’idea chiara di com’è strutturata la sicurezza in macOS e iOS.
Preambolo
Diciamolo, virus e malware sono rari su macOS (ma non inesistenti) e questo è un aspetto che Apple ha continuato a vantare per molti anni, facendo ottenere punti extra sia a macOS che ad iOS.
Ma qual è la verità?
E’ tutto vero, ed è in gran parte dovuto alla monocoltura verso Windows. Mettendosi nei panni di uno sviluppatore di malware, è logico pensare che è molto più conveniente investire tempo e sforzo nello sviluppo di un virus su un sistema operativo come Windows (presente su un numero immenso di computer nel mondo) piuttosto che su macOS o sistemi basati su kernel Linux che sono più di nicchia (tra molte virgolette, per rendere l’idea).
In effetti, macOS (e in una certa misura anche Linux) rimangono in “buona salute”, semplicemente perché non attirano molto l’attenzione dei “fornitori” di malware (un’altra ragione è che Unix ha sempre aderito al principio di privilegi minimi: non concede ad un utente normale, l’accesso root di default). Potreste esultare, ma è bene sapere la situazione sta cambiando, con il lento ma costante aumento della quota di mercato di macOS, aumenta proporzionalmente il numero di malware in circolazione.
Un dato importante: “Flashback” (così chiamato perché era un trojan mascherato da aggiornamento di Adobe Flash) fu un virus che infettò circa 600.000 utenti negli Stati Uniti. Parliamo di macOS.
Code Signing
Prima che il software possa essere definito sicuro, bisogna autenticarne l’origine, la provenienza. Se un’app viene scaricata da un sito Internet a caso, esiste un rischio (basso, ma presente) significativo che si tratti di un malware. Questo rischio è tuttavia fortemente ridotto, nel momento in cui è possibile verificare l’origine dell’app ed inoltre se è certo che non è stata modificata durante la fase di download (esistono alcune tecniche, basate su attacchi MITM che permettono di sostituire un’eseguibile con un altro a propria discrezione).
Il code signing (firma del codice) fornisce un meccanismo proprio per realizzare questi controlli: utilizzando lo stesso stratagemma usato dalla tecnologia SSL per stabilire l’identità dei siti Web (firmando la chiave pubblica con la chiave privata dell’emittente), Apple incoraggia gli sviluppatori a firmare le proprie applicazioni per poter autenticare in modo veloce identità e provenienza. Il punto cruciale di una firma digitale è che la chiave pubblica del firmatario deve essere a nota a priori all’emettitore, cioè Apple.
Se volete verificare l’effettiva presenza dei portachiavi di sistema (che incorpora questi certificati), all’interno del vostro sistema macOS, potete utilizzare l’utility security, che tra le sue varie funzioni, permette di scaricare i portachiavi di sistema, in modalità interattiva, dove in login.keychain-db abbiamo ad esempio la password dell’user (matteo) e in System.keychain la password e i certificati del Wi-Fi.
Apple ha sviluppato un linguaggio speciale per definire i requisiti necessari alla firma del codice, che possono essere visualizzati con il comando csreq. Inoltre, è presente anche il comando codesign usato dagli sviluppatori per firmare le app: (oltre a verificare/visualizzare le firme esistenti) la cosa divertente è che il codesign non firmerà nulla senza un certificato valido e attendibile, che gli sviluppatori possono ottenere solo registrandosi al Programma sviluppatori Apple.
Mentre la firma del codice in macOS è facoltativa, in iOS è obbligatoria. Se per qualche ragione (divina), un’applicazione non firmata si fa strada nel file system, verrà uccisa dal kernel dopo un qualsiasi tentativo di esecuzione. Questo è ciò che rende la vita dei jailbreaker così difficile: il sistema, semplicemente si rifiuta di eseguire del codice non firmato, e quindi l’unico modo per farlo è sfruttare le vulnerabilità nelle applicazioni firmate già esistenti (e in seguito il kernel stesso). I jailbreaker devono quindi cercare questi ‘difetti’ nelle app e nelle librerie di sistema di iOS. In alternativa, possono provare a cercare guasti nel meccanismo di firma del codice stesso, come accadde al ricercatore di sicurezza Charlie Miller in iOS 5.0.
Qualsiasi app che viola i termini di servizio del programma sviluppatori di Apple, porta automaticamente lo sviluppatore a diventare un utente “non gradito” per Apple, con conseguente ban dall’App Store. Nel prossimo articolo, inizieremo a comprendere il concetto di sandbox.
Anche per questo articolo è tutto. Per eventuali domande, curiosità o feedback potete lasciare un commento qui in basso, a presto!