Apple ha una storia un po’ discutibile con i ricercatori di sicurezza: vuole sostenere che la sua sicurezza sia eccellente, il che significa cercare di zittire coloro che mirano a dimostrare il contrario. Ma quei tentativi di combattere i ricercatori che vendono le loro informazioni a chiunque non sia Apple mina il messaggio di sicurezza dell’azienda di Cupertino.

Un recente articolo sul Washington Post ha rivelato i dettagli dietro la ben nota lotta di Apple con il governo degli Stati Uniti nel 2016, quando il Dipartimento di Giustizia spinse Cupertino a creare una backdoor di sicurezza relativa all’iPhone utilizzato da un terrorista nella tristemente famosa sparatoria di San Bernardino. Apple si rifiutò; il governo allora portò Apple in tribunale, per poi abbandonare la battaglia legale quando trovò un modo per aggirare la sicurezza di Apple. L’exploit funzionò, ma sul dispositivo non fu trovato nulla di valore per il governo.

Tutto ciò è già noto, ma l’articolo del Post descrive l’exploit che il governo ha acquistato per 900.000 dollari. Si trattava di un buco nel codice open-source di Mozilla che Apple aveva utilizzato per consentire il collegamento degli accessori alla porta Lightning di un iPhone. Quello era il tallone d’Achille dello smartphone. A tal proposito non c’è più da preoccuparsi ora, visto che la vulnerabilità è stata risolta da tempo da Mozilla, rendendo inutile l’exploit.

La funzionalità di sicurezza di Apple consisteva in una difesa contro gli attacchi brute force, con l’iPhone che semplicemente cancellava tutti i dati al proprio interno dopo 10 tentativi di accesso falliti. Un ricercatore creò allora un exploit che consentì l’accesso iniziale al telefono, per poi affidarsi a un altro exploit che permise una maggiore manovrabilità. Infine, intervenne un terzo exploit finale che un altro ricercatore di Azimuth aveva già creato per gli iPhone e che gli diede il pieno controllo del processore principale del telefono, il cervello del dispositivo. Da lì si riuscirono a cancellare diverse feature dell’iPhone, tra cui proprio quella che cancellava i dati dopo 10 tentativi errati.

Alla luce di tutto ciò, qual è il risultato finale per la sicurezza aziendale? È un po’ complicato. Da un certo punto di vista un’azienda non può fidarsi di nessun dispositivo mobile di livello consumer (i dispositivi Android e iOS possono avere problemi di sicurezza diversi, ma entrambi hanno problemi di sicurezza sostanziali) senza modificare in qualche modo i suoi meccanismi di sicurezza. Da una prospettiva più pragmatica, nessun dispositivo offre una sicurezza perfetta, anche se alcuni dispositivi mobili (iOS più di Android) fanno un buon lavoro su questo versante.

I dispositivi mobili offrono infatti feature di sicurezza dell’identità a costi molto bassi grazie alla biometria integrata. Oggi è quasi tutto affidato al riconoscimento facciale, ma sinceramente spero nel ritorno dell’impronta digitale e soprattutto nell’aggiunta della scansione della retina, che è un metodo biometrico molto migliore del dito o del viso.

gestione delle vulnerabilità

In ogni caso, questi dati biometrici sono importanti perché il punto debole sia per iOS che per Android è ottenere l’accesso autorizzato al dispositivo, che è ciò di cui parla la storia del Washington Post. Una volta all’interno del telefono, la biometria fornisce un livello aggiuntivo di autenticazione conveniente per le app aziendali. Sto ancora aspettando che qualcuno utilizzi il riconoscimento facciale per avviare una VPN aziendale; dato infatti che la VPN è la chiave iniziale per i file aziendali ultra sensibili, necessita di un’autenticazione aggiuntiva.

Per quanto riguarda la soluzione alternativa descritta dal Post, il vero colpevole è la complessità. Gli smartphone sono dispositivi molto sofisticati, con tantissime app di terze parti che si portano dietro problemi di sicurezza. Mi viene in mente un articolo di qualche anno fa in cui parlavamo di come l’app Starbucks salvasse le password in testo non crittografato che chiunque poteva vedere. Il colpevole si era rivelato essere un’app di analisi degli arresti anomali di proprietà di Twitter che “catturava” tutto nell’istante in cui rilevava un arresto anomalo. Ecco da dove provenivano le password in testo non crittografato.

Tutto ciò solleva una domanda chiave: quanti test di sicurezza mobile sono realistici, sia a livello aziendale (Starbucks, in questo esempio) che a livello di fornitore (Apple)? La scoperta dell’app “malevola” nell’esempio di Starbucks avvenne grazie a un penetration tester e continuo a sostenere che ci debba essere molto più testing sia a livello di azienda, sia di fornitore. Detto questo, anche un buon tester di terze parti non riuscirà mai a scoprire tutto: nessuno riesce a farlo.

Questo ci riporta alla domanda iniziale: cosa dovrebbero fare gli amministratori IT e della sicurezza aziendale quando si tratta di sicurezza mobile? Bene, possiamo eliminare l’opzione ovvia, poiché non utilizzare i dispositivi mobili per i dati aziendali non è un’opzione. I loro vantaggi e la massiccia distribuzione (sono già nelle mani di quasi tutti i dipendenti/appaltatori/terzi/clienti) rendono infatti impossibile resistere ai dispositivi mobili.

Ma nessuna azienda può fidarsi ciecamente della sicurezza di questi dispositivi. Ciò significa partizionare i dati aziendali e richiedere l’accesso alle app di sicurezza di livello aziendale. Ci sono semplicemente troppe vulnerabilità (scoperte e ancora da scoprire) che possono essere sfruttate. Negli smartphone odierni c’è il codice di migliaia di programmatori che lavorano per Apple (molti dei quali non parlano mai tra loro) o che hanno creato app di terze parti. Invariabilmente non esiste una sola persona che sappia tutto di tutto sul codice all’interno del telefono. È vero per qualsiasi dispositivo complesso e lo è anche, inevitabilmente, per gli smartphone.