Controlla la firma e l'autenticazione di qualsiasi app Mac dal terminale

Gatekeeper esegue questo controllo automaticamente la prima volta che apri un'app scaricata e la maggior parte delle volte non vedi mai i dettagli: viene visualizzata una finestra di dialogo, fai clic su di essa, fatto. Questo laboratorio consiste nel vedere cosa ha visto Gatekeeper: quale sviluppatore ha firmato l'app, se la firma è intatta, se il servizio notarile di Apple l'ha controllata e cosa gli è consentito fare una volta eseguita. Ogni comando qui viene fornito con gli strumenti da riga di comando di Xcode (xcode-select --install se non li hai ancora) e ognuno di essi è di sola lettura: stai ispezionando, non modificando, l'app.

La firma stessa: codesign -dvvv

codesign è lo strumento di Apple per creare e controllare le firme dei codici. Il flag -d visualizza informazioni sul codice firmato in un percorso e, secondo la sua pagina man, "L'aumento dei livelli di verbosità produce più output" - quindi -dvvv (visualizzazione, tre livelli di verbosità) ti offre il quadro completo in un solo comando:

$ codesign -dvvv /Applications/Example.app
# example output, trimmed to the fields that matter
Executable=/Applications/Example.app/Contents/MacOS/Example
Identifier=com.example.app
Format=app bundle with Mach-O universal (x86_64 arm64)
CodeDirectory v=20500 size=... flags=0x10000(runtime) hashes=...
Signature size=4741
Authority=Developer ID Application: Example Software LLC (ABCDE12345)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Team Identifier=ABCDE12345
Runtime Version=14.0.0

Quattro campi da leggere ogni volta. Authority è la catena di certificati: una normale app esterna dovrebbe terminare con Apple Root CA tramite Developer ID Certification Authority, con la riga superiore che nomina lo sviluppatore. Team Identifier è l'ID di dieci caratteri di Apple per l'account sviluppatore: il valore da confrontare tra app che ritieni provengano dalla stessa azienda, poiché non cambia tra le loro versioni. flags=0x10000(runtime) significa che è abilitato il runtime rafforzato, una serie di restrizioni aggiuntive (come la resistenza all'inserimento di codice nel processo) che Apple richiede per l'autenticazione. E l'assenza di qualsiasi riga Authority - solo Signature=adhoc - significa che l'app non è firmata o è autofirmata senza alcun collegamento con Apple.

La firma corrisponde ancora ai file: --verify --deep --strict

Una firma è una promessa su un insieme specifico di byte al momento della firma. --verify controlla se quella promessa è ancora valida: secondo la pagina man, conferma "che il codice in quei percorsi è firmato, che la firma è valida e che tutti i componenti sigillati sono inalterati". Due flag aggiuntivi sono importanti per un app bundle, che è una directory piena di risorse annidate, framework ed eseguibili di supporto, non un singolo file:

$ codesign --verify --deep --strict --verbose=2 /Applications/Example.app
/Applications/Example.app: valid on disk
/Applications/Example.app: satisfies its Designated Requirement

--deep è importante perché, secondo la pagina man, la verifica del contenuto nidificato è per impostazione predefinita "limitata a un'indagine superficiale che potrebbe non rilevare modifiche al codice nidificato" - la modalità profonda verifica ricorsivamente ogni framework incorporato e strumento di supporto, non solo il bundle esterno. --strict aggiunge controlli aggiuntivi che Apple considera abbastanza importanti da non essere attivi per impostazione predefinita, incluso il fatto che qualsiasi collegamento simbolico all'interno del bundle "punta a file sigillati all'interno del bundle", rifiutando quelli che puntano all'esterno dell'app o a qualcosa non sigillato: un trucco noto per introdurre di nascosto un payload non firmato in un bundle altrimenti legittimamente firmato. Se uno dei due controlli fallisce, vedrai code failed to satisfy specified code requirement o una nota che nomina esattamente quale elemento nidificato non corrisponde a ciò che era originariamente sigillato: leggi quella riga, nomina il file.

Lettura dei diritti

I diritti sono le autorizzazioni specifiche concesse dalla firma di un'app: accesso alla telecamera, possibilità di raggiungere la rete senza sandbox, disabilitazione della convalida della libreria e così via. codesign -d --entitlements - li estrae; secondo la pagina man, "I dati sui diritti incorporati verranno estratti allo stesso modo e scritti" nel percorso indicato e - indica l'output standard:

$ codesign -d --entitlements - /Applications/Example.app
# example output, trimmed
<key>com.apple.security.cs.disable-library-validation</key>
<true/>
<key>com.apple.security.network.client</key>
<true/>
<key>com.apple.security.device.camera</key>
<true/>

La maggior parte dei diritti sono insignificanti e corrispondono a ciò di cui ovviamente l'app ha bisogno: un'app di videochiamata che richiede l'accesso alla fotocamera non è una scoperta. Quello su cui vale la pena soffermarsi è disable-library-validation: significa che l'app caricherà il codice dall'esterno del proprio bundle firmato, che è una normale necessità per alcuni software basati su plug-in e una porta più ampia di quella richiesta dalla maggior parte delle app. È un dettaglio da notare, non un campanello d'allarme automatico, ed è esattamente il tipo di dettaglio che non puoi vedere senza chiedere.

Il servizio notarile di Apple lo ha effettivamente controllato: spctl e cucitrice

Una firma valida dimostra solo che un'app non è stata modificata da quando uno sviluppatore l'ha firmata, ma non dice nulla sul fatto che Apple l'abbia esaminata o meno. Questo è ciò che aggiunge l'autenticazione notarile. La documentazione di Apple descrive il servizio notarile automatizzato come la scansione "del software alla ricerca di componenti dannosi, verifica la presenza di problemi di firma del codice e restituisce rapidamente i risultati". Quando passa, "il servizio notarile genera un ticket da aggiungere al tuo software; il servizio notarile pubblica anche quel ticket online dove Gatekeeper può trovarlo."

spctl --assess è il modo pratico per chiedere il verdetto al motore delle policy di Gatekeeper invece di dedurlo da soli. Secondo la sua pagina man, --assess "esegui[i] una valutazione sui file forniti" e -v / --verbose, ripetuto per maggiori dettagli, viene descritto semplicemente come una richiesta di "output più dettagliato":

$ spctl --assess -vv /Applications/Example.app
/Applications/Example.app: accepted
source=Notarized Developer ID

source=Notarized Developer ID è il risultato che vuoi vedere: significa che Gatekeeper ha trovato una firma ID sviluppatore valida e un ticket di autenticazione, indipendentemente dal fatto che il ticket sia pinzato sull'app o sia stato trovato online. Un risultato di source=Unnotarized Developer ID significa che l'app è firmata ma Apple non l'ha autenticata (o non l'ha ancora) e un rejected semplice significa che Gatekeeper ne impedirebbe l'avvio nella sua configurazione predefinita.

Per controllare la graffetta in modo specifico, xcrun stapler validate cerca il ticket fisicamente allegato all'app anziché chiedere a Gatekeeper di cercarlo online: utile per confermare che un'app continuerà a valutare correttamente senza alcuna connessione Internet:

$ xcrun stapler validate /Applications/Example.app
Processing: /Applications/Example.app
The validate action worked!

Il flag di quarantena: da dove proviene il controllo di prima esecuzione

La guida alla sicurezza della piattaforma di Apple spiega che "Gatekeeper tiene traccia anche della provenienza dei file scritti dal software scaricato" e "richiede l'approvazione dell'utente prima di aprire il software scaricato per la prima volta". Il meccanismo alla base di ciò è un attributo esteso, com.apple.quarantine, che Safari, Mail e altre app allegano a tutto ciò che salvano dalla rete. xattr -l lo elenca e, secondo la pagina man, questa opzione "fa sì che vengano visualizzati sia i nomi degli attributi che i valori corrispondenti":

$ xattr -l ~/Downloads/Example.dmg
com.apple.quarantine: 0081;65e1a2b3;Safari;

Nessun output significa che il file non presenta alcun contrassegno di quarantena: o è stato creato localmente, è arrivato tramite un percorso che non imposta l'attributo (alcuni strumenti di archivio e gestori di pacchetti lo saltano) oppure il contrassegno è stato rimosso manualmente con xattr -d com.apple.quarantine. Vale la pena conoscere quest'ultimo caso per un motivo diverso: è un modo documentato in cui le persone ignorano completamente il controllo di prima esecuzione di Gatekeeper, su file di cui si fidano o pensano di fidarsi, e vale la pena rifletterci piuttosto che incollare da un insieme sconosciuto di istruzioni del terminale.

Un confronto funzionato: due app che rivendicano lo stesso sviluppatore

Un modo concreto per utilizzare tutto questo insieme: supponiamo che tu abbia due copie di un'app che dichiarano entrambe di provenire dalla stessa azienda, una dal sito dello sviluppatore e una da un collegamento che qualcuno ti ha inviato. Esegui codesign -dvvv su entrambi e confronta la riga Team Identifier: è una stringa di dieci caratteri legata a uno specifico account sviluppatore Apple e, a differenza di un nome visualizzato o di un identificatore di bundle, non è qualcosa che una seconda parte può riprodurre casualmente senza accedere al certificato di firma di quell'account. Se le due copie mostrano identificatori di squadra diversi, non stai guardando due build della stessa app; stai esaminando due firmatari diversi, uno dei quali non è quello richiesto dal download. Seguilo con spctl --assess -vv sulla copia sospetta: una fonte di autenticazione non corrispondente o assente sulla copia che afferma di essere identica a un originale autenticato è la conferma, non solo un indizio.

Leggendo l'intero quadro e le reali bandiere rosse

• Nessuna catena Authority o una catena che non termina con Apple Root CA: l'app non ha un'identità di sviluppatore responsabile dietro di sé.
• codesign --verify fallisce, soprattutto con un messaggio che nomina uno specifico file nidificato: qualcosa all'interno del pacchetto è cambiato dopo che è stato firmato.
• spctl --assess restituisce rejected oppure l'identificatore del team in codesign -dvvv non corrisponde allo sviluppatore previsto per quel prodotto.
• Un contrassegno di quarantena chiaramente rimosso da un file che non hai scaricato personalmente o che è arrivato tramite un canale insolito (uno script, un allegato di posta elettronica rinominato per assomigliare a qualcos'altro).
• Diritti completamente aperti - accesso completo al disco, convalida della libreria disabilitata, accesso alla rete illimitato - su un'app il cui scopo dichiarato ovviamente non ne ha bisogno.

Nessuno di questi controlli esamina ciò che fa effettivamente l'app una volta che è in esecuzione e connessa alla rete: si tratta di un diverso tipo di domanda, a cui si risponde osservando il suo traffico anziché la sua firma. Una firma pulita e un ticket di autenticazione valido sono un punto reale e significativo: dicono che Apple ha visto questo esatto set di byte e non ha riscontrato problemi di firma del codice al momento del controllo. Sono l'inizio della fiducia in un'app, non la fine.

Il ruolo di FireAI e di HisnLabs

A clean signature and a stapled ticket say an app hasn’t been tampered with since Apple checked it — they say nothing about what it connects to afterward, which is the question FireAI’s per-app rules and on-device review are built to keep answering, signature by signature, connection by connection.

FireAI è il prodotto di HisnLabs: un firewall con IA che funziona direttamente sul Mac. Mostra in linguaggio chiaro ogni connessione che le tue app effettuano e ti lascia decidere cosa esce dal tuo Mac — la sua IA lavora in locale, quindi il tuo traffico non viene mai inviato a noi né a nessun altro. Il team di ricerca sulla sicurezza di HisnLabs è quello che mantiene affidabili queste decisioni: cataloga quali domini sono semplice telemetria e quali un servizio reale, traccia il Paese e la rete dietro una connessione e addestra il modello locale (la funzione Autopilot) su schemi di traffico reali, senza che nulla lasci il tuo Mac.

Puoi leggere le scelte tecniche che ci stanno dietro, oppure provare FireAI per 17 giorni, su FireAI, di HisnLabs.