Nascondere l'accesso root in Magisk diventerà molto più difficile da fare grazie a un recente cambiamento in SafetyNet che porta l'attestazione hardware.
A marzo, alcuni utenti avevano installato Magisk si accorse che i loro dispositivi non superavano l'attestazione SafetyNet. Questa notizia è stata preoccupante per la community di XDA perché significa che molte app bancarie/finanziarie cruciali e giochi popolari come Pokémon Go e Fate/Grand Order si rifiutavano di funzionare su dispositivi rooted. Per qualche tempo è sembrato che le restrizioni più severe in SafetyNet fossero state ritirate, per poi essere nuovamente implementate per una manciata di utenti nelle ultime settimane. Tuttavia, Google ha confermato all'inizio di maggio che sta testando l'attestazione supportata dall'hardware Risposte di SafetyNet, che è ciò che ha impedito a Magisk di nascondere nuovamente lo stato di sblocco del bootloader Marzo. Se questo cambiamento si diffonderà ampiamente, significherà che gli utenti dovranno scegliere tra avere accesso a root/ROM personalizzate/kernel/ecc. o le loro app e giochi bancari preferiti. Una delle maggiori attrattive di Android per gli utenti esperti potrebbe presto scomparire.
Per ricapitolare questa serie di eventi, dovremmo prima parlare di SafetyNet stessa. SafetyNet è un insieme di API in Google Play Services. L'API SafetyNet Attestation è una di quelle API e può essere richiamata da applicazioni di terze parti per verificare se l'ambiente software del dispositivo è stato manomesso in qualche modo. L'API verifica varie cose come i segni dei file binari del superutente, lo stato di sblocco del bootloader e altro ancora. Quando esegui il root di un dispositivo con Magisk, "[crea] un" ambiente sicuro "isolato per il processo di rilevamento [SafetyNet] e passa attraverso l'API di Google per creare un legittimo Risultato SafetyNet che non riflette lo stato reale del dispositivo", secondo lo sviluppatore riconosciuto senior XDA topjohnwu. Ciò consente all'utente di eseguire il root del proprio telefono garantendo al tempo stesso che l'API restituisca sempre "false" per qualsiasi controllo di sblocco del bootloader. Questo metodo per aggirare il rilevamento dello sblocco del bootloader di SafetyNet ha funzionato per Magisk negli ultimi tempi anni, ma è solo perché Google ha trattenuto la verifica dell'integrità dell'immagine di avvio utilizzando l'hardware attestazione. A marzo sembrava che Google stesse finalmente iniziando a utilizzare l'attestazione hardware in SafetyNet per verificare l' immagine di avvio, ma non abbiamo mai ricevuto una dichiarazione ufficiale da Google che confermasse la modifica e solo pochi utenti lo hanno ricevuto ricercato. Come notato dal membro senior di XDA Dislocamento, tuttavia, Google ha confermato il 5 maggio 2020 che le risposte dell'API SafetyNet Attestation da alcuni dispositivi ora includono controlli supportati dall'hardware.
Nel gruppo Google per "Client API SafetyNet", Google ha dettagliato una nuova funzionalità per l'API di attestazione: interviewType. La risposta JSON Web Signature (JWS) di alcuni dispositivi avrà un campo denominato "evaluationType" che "fornirà agli sviluppatori informazioni dettagliate nei tipi di segnali/misurazioni che hanno contribuito a ogni singola risposta dell'API SafetyNet Attestation." Uno dei token supportati in questo campo c'è "HARDWARE_BACKED" che indica che l'API "[ha utilizzato] le funzionalità di sicurezza supportate dall'hardware disponibili del dispositivo remoto (per esempio. Attestazione della chiave supportata da hardware) per influenzare la [sua] valutazione." Google afferma che stanno "attualmente valutando e adattando i criteri di idoneità per i dispositivi su cui faremo affidamento su dispositivi supportati da hardware funzionalità di sicurezza." Ciò significa che, su alcuni dispositivi, Google Play Services utilizza ora l'attestazione supportata dall'hardware per rilevare che il software del dispositivo non è stato manomesso. Google non ha documentato ufficialmente questo cambiamento al di fuori dell'annuncio nel gruppo Google, quindi alcuni sviluppatori che utilizzano SafetyNet potrebbero farlo non essere a conoscenza di questa modifica (e quindi non stanno ancora controllando il campo "HARDWARE_BACKED" nelle risposte JWS). Tuttavia, per quelle app che stanno controllando questo campo, ora non c'è modo di nascondere loro l'accesso root, a condizione che il tuo dispositivo faccia parte del test che Google sta effettuando corsa.
Secondo topjohnwu, l'attestazione supportata dall'hardware significa che Google Play Services ora "[invia] un certificato di archivio di chiavi non modificato ai server SafetyNet, [verifica] la sua legittimità e [controlla] i dati dell'estensione del certificato per sapere se il tuo dispositivo [ha] verificato l'abilitazione all'avvio (stato del bootloader).” Poiché le chiavi private da cui derivano i certificati del keystore sono supportati dall'ambiente sicuro isolato del telefono, il loro recupero comporterebbe la vanificazione della sicurezza del Trusted Execution Environment (TEE) del telefono o della sicurezza hardware dedicata modulo (HSM). Se in qualche modo si riuscisse a trapelare una chiave privata, il file le chiavi verrebbero rapidamente revocate una volta che Google lo ha scoperto. Google offre centinaia di migliaia di dollari in premi per eventuali vulnerabilità critiche della sicurezza che interessano il TEE nei telefoni Pixel, il che dimostra che è incredibilmente improbabile che questa sia una potenziale strada per aggirare il rilevamento dello sblocco del bootloader comunque.
Un altro potenziale modo in cui Magisk potrebbe continuare a falsificare lo stato di sblocco del bootloader è modificare il codice lato client di SafetyNet per utilizzare sempre la valutazione BASIC. COME note di topjohnwu, tuttavia, ciò richiederebbe l'inserimento di codice personalizzato in Google Play Services tramite un framework di aggancio come Xposed Framework. Questo non solo è difficile da fare perché Google Play Services è altamente offuscato, ma è anche impossibile da nascondere poiché "alcune analisi dello spazio di memoria riveleranno molto la manipolazione del codice facilmente." Inoltre, questo funzionerebbe solo se i server di Google continuassero ad accettare le valutazioni BASIC e se le valutazioni HARDWARE_BACKED non venissero applicate sui dispositivi che supportano loro. (Le risposte di SafetyNet "[provengono] dai server di Google e sono firmate con la chiave privata di Google", secondo topjohnwu, quindi le risposte effettive non possono essere falsificate.)
A partire da Android 7 Nougat, Google ha richiesto che tutti i dispositivi abbiano un ambiente sicuro isolato, ciò significa che questa modifica al modo in cui SafetyNet verifica lo sblocco del bootloader influenzerà la maggior parte dei dispositivi non disponibili Là. Poiché i dispositivi più vecchi senza un ambiente sicuro isolato ovviamente non possono eseguire l'attestazione supportata dall'hardware, Magisk sarà comunque in grado di nascondere l'accesso root su tali dispositivi. Ma se questo cambiamento si diffonderà su vasta scala, tutti gli altri dovranno fare una scelta difficile tra l’accesso root e le app bancarie.
Sfortunatamente, probabilmente ci sono molte app là fuori che utilizzano i controlli SafetyNet quando in realtà non ne hanno bisogno. Un esempio citato da topjohnwu è l'app ufficiale di McDonald's, che apparentemente rifiuta di funzionare su un dispositivo sbloccato con il bootloader. Su Twitter, topjohnwu denuncia le app che abusano dell'API creando un ambiente ostile per gli utenti esperti. Sviluppatore riconosciuto XDA Quinny899 si unisce con un aneddoto su come il suo team ha pensato di utilizzare SafetyNet per verificare lo stato di sicurezza del dispositivo. Alla fine hanno deciso di non procedere poiché l'app del suo team crittografa tutti i dati sensibili con cui lavora. SafetyNet, sostiene, non dovrebbe essere utilizzato al posto di adeguate pratiche di sicurezza e gestione dei dati, soprattutto se si considera il possibilità di exploit da superutente.
Per ulteriori informazioni su come la nuova modifica SafetyNet influisce su Magisk, consulta topjohnwu's eccellenti FAQ su Twitter. Se vuoi semplicemente verificare se il tuo dispositivo fa parte del nuovo test SafetyNet di Google, puoi seguire questa guida da XDA Senior Member Displax o scarica l'ultima versione di Magisk Manager.
Questo articolo è stato aggiornato alle 10:46 EST del 30 giugno 2020 per correggere il fatto che Google paga solo premi per le vulnerabilità TEE rilevate nei telefoni Pixel. Inoltre, sono stati aggiunti dettagli sull'ultima versione di Magisk Manager che ora mostra il campo interviewType nel controllo SafetyNet integrato.