Lo sviluppatore di Magisk ha scoperto che Google potrebbe aver iniziato a utilizzare controlli hardware per determinare se un dispositivo è stato sbloccato con il bootloader.
Sviluppatore riconosciuto XDA topjohnwuIl progetto "Magisk" di è diventato essenzialmente sinonimo di "root" nella comunità Android. Uno dei motivi principali per cui è così popolare è perché può nascondere il fatto che l'utente ha modificato il proprio dispositivo. Tuttavia, Google potrebbe reprimere la capacità di Magisk di nascondere lo stato di sblocco del bootloader dalle applicazioni.
Per eseguire il root del telefono, di solito è necessario sbloccare il bootloader, che consente di eseguire il flashing delle immagini di avvio modificate. Ciò è necessario perché Magisk modifica l'immagine di avvio per falsificare lo stato del bootloader e/o i controlli dello stato di avvio verificato. L'API SafetyNet Attestation di Google, che fa parte di Google Play Services, viene utilizzata per indicare a un'app se è in esecuzione su un dispositivo manomesso; se l'API SafetyNet rileva che il bootloader è stato sbloccato, restituirà uno stato di errore per il controllo di "integrità di base". I dispositivi che non superano questo controllo possono quindi essere esclusi dalle app che utilizzano l'API SafetyNet per determinare l'integrità del dispositivo; tali app in genere includono app bancarie, app di pagamento (come Google Pay) e molti giochi online (come Pokémon Go). Tuttavia, poiché finora l'API SafetyNet ha utilizzato solo controlli software per determinare se il dispositivo è stato manomesso, Magisk può semplicemente falsificare il stato del bootloader e/o di avvio verificato poiché è installato a un livello inferiore e con privilegi più elevati rispetto a Google Play Services e altri spazi utente applicazioni. Come spiega topjohnwu, MagiskHide "[crea] un 'ambiente sicuro' isolato per il processo di rilevamento e passa attraverso l'API di Google per creare un
legittimo Risultato SafetyNet che non riflette il reale stato del dispositivo."Di recente, tuttavia, gli utenti hanno notato che i loro dispositivi sbloccati con il bootloader non superano il controllo di integrità di base di SafetyNet anche se hanno utilizzato Magisk per applicare la patch all'immagine di avvio. Secondo topjohnwu, ciò è dovuto al fatto che Google potrebbe aver implementato l'attestazione della chiave a livello hardware per verificare che l'immagine di avvio non sia stata manomessa. Nello specifico, ciò significa che Google Play Services "[invia] un certificato di archivio di chiavi non modificato ai server SafetyNet, ne verifica la legittimità e controlla dati dell'estensione del certificato per sapere se il tuo dispositivo [ha] verificato l'avvio abilitato (stato del bootloader)." Ciò significa che potrebbe non essere più possibile nascondere il fatto che il bootloader è stato sbloccato, il che comporterà il mancato funzionamento di applicazioni come Google Pay e Pokémon Go normalmente.
Come ha notato topjohnwu, questa modifica al modo in cui SafetyNet controlla lo stato di sblocco del bootloader avviene tramite un aggiornamento lato server dell'API SafetyNet contenuta in Google Play Services. Tuttavia, non tutti gli utenti falliscono questi controlli SafetyNet aggiornati, quindi la nuova attestazione chiave a livello hardware potrebbe non essere ancora ampiamente applicata.
Abbiamo visto topjohnwu superare gli ostacoli tecnici più e più volte. Google lancia spesso nuovi controlli in SafetyNet che topjohnwu poi scopre e aggira in Magisk. Ogni nuova versione di Android apporta modifiche alla struttura delle partizioni o all'immagine di avvio, richiedendo a topjohnwu di studiare le modifiche e quindi implementare un nuovo metodo di patch. Tuttavia, anche topjohnwu potrebbe avere difficoltà a trovare una tangenziale questa volta.
Questo perché la soluzione alternativa questa volta comporterebbe l'hacking del firmware dei dispositivi Trusted Execution Environment (TEE) per recuperare la chiave privata. Tuttavia, questo è incredibilmente difficile da fare in quanto richiede l’individuazione di una vulnerabilità nel firmware progettato per essere incredibilmente sicuro. In effetti, molte aziende offrono pagamenti per centinaia di migliaia di dollari se dovesse essere riscontrata una tale vulnerabilità. Google, ad esempio, paga 250.000 dollari per le vulnerabilità legate all'esecuzione di codice in modalità remota nel Trusted Execution Environment di Pixel e fino a $ 1.000.000 per le vulnerabilità in Titano M chip di sicurezza. Anche se una chiave privata dovesse in qualche modo trapelare, è improbabile che possa essere di grande utilità da allora Google può revocare la chiave da remoto quindi non può essere utilizzato per verificare l'integrità dei dispositivi.
Una volta che l'attestazione della chiave a livello hardware sarà ampiamente applicata per SafetyNet, la maggior parte dei dispositivi con bootloader sbloccati che eseguono Android 8.0 Oreo o versioni successive non riusciranno a superare il controllo di integrità di base di SafetyNet. Questo perché tutti i dispositivi lanciati con Android 8.0 Oreo o versioni successive devono avere un archivio chiavi hardware implementato in un TEE. Alcuni dispositivi oggigiorno dispongono addirittura di moduli di sicurezza hardware (HSM) dedicati che rendono ancora più difficile lo sfruttamento allontanando il TEE dal processore principale; il Titan M nel Pixel 4 e Il nuovo chip di sicurezza di Samsung nel Galaxy S20 ne sono un esempio.
Topjohnwu spiega anche che altre potenziali soluzioni alternative sono impossibili o molto impegnative. L'utilizzo di Xposed Framework per modificare l'API SafetyNet Attestation in Google Play Services probabilmente non funzionerà poiché "i controlli SafetyNet adeguati verificheranno i risultati su un server remoto, non su [the] dispositivo che può essere manipolato da framework di iniezione di codice." Inoltre, Google Play Services è altamente offuscato, rendendo la creazione di un modulo Xposed incredibilmente impegnativa nel primo posto. Anche lo spoofing del risultato di un test di SafetyNet non sarà fattibile poiché le risposte di SafetyNet "provengono dai server di Google e sono firmate con la chiave privata di Google".
Google ha la capacità di rafforzare i controlli SafetyNet utilizzando l'attestazione chiave supportata da hardware ormai da diversi anni. Il fatto che si siano astenuti dal farlo per 3 anni ha consentito agli utenti di usufruire dei moduli root e Magisk senza sacrificare la possibilità di utilizzare le app bancarie. Tuttavia, sembra che la capacità di Magisk di nascondere in modo efficace lo stato di sblocco del bootloader sia presto giunta al termine. È un cambiamento che aspettavamo da anni, ma ci dispiace vederlo finalmente entrato in vigore. Ci auguriamo che Google aggiorni l'API SafetyNet Attestation per restituire se il controllo dello stato è stato utilizzato in base all'hardware attestazione in quanto ciò consentirebbe agli sviluppatori di app di decidere se desiderano bloccare tutti gli utenti che hanno sbloccato il file boot loader.
Grazie a Daniel Micay (@DanielMicay) per il suo contributo in merito a questo argomento!