O desenvolvedor do Magisk descobriu que o Google pode ter começado a usar verificações de hardware para determinar se o bootloader de um dispositivo foi desbloqueado.
Desenvolvedor reconhecido pelo XDA topjohnwuO projeto “Magisk” da empresa tornou-se essencialmente sinônimo de “root” na comunidade Android. Um dos principais motivos de sua popularidade é porque pode ocultar o fato de que o usuário modificou seu dispositivo. No entanto, o Google pode estar reprimindo a capacidade do Magisk de ocultar o status de desbloqueio do bootloader dos aplicativos.
Para fazer root no seu telefone, geralmente você precisa desbloquear o bootloader, que permite atualizar imagens de inicialização modificadas. Isso é necessário porque o Magisk modifica a imagem de inicialização para falsificar o status do bootloader e/ou as verificações de status da inicialização verificada. A API SafetyNet Attestation do Google, que faz parte do Google Play Services, é usada para informar a um aplicativo se ele está sendo executado em um dispositivo adulterado; se a API SafetyNet detectar que o bootloader foi desbloqueado, ela retornará um status de falha para a verificação de "Integridade Básica". Os dispositivos que falharem nesta verificação podem ser bloqueados de aplicativos que usam a API SafetyNet para determinar a integridade do dispositivo; esses aplicativos normalmente incluem aplicativos bancários, aplicativos de pagamento (como Google Pay) e muitos jogos online (como Pokémon Go). No entanto, como a API SafetyNet até agora só usou verificações de software para determinar se o dispositivo foi adulterado, o Magisk pode simplesmente falsificar o bootloader e/ou status de inicialização verificada, pois está instalado em um nível inferior e com privilégios mais altos do que o Google Play Services e outro espaço de usuário formulários. Como explica topjohnwu, MagiskHide "[cria] um 'ambiente seguro' isolado para o processo de detecção e passa pela API do Google para criar um
legítimo Resultado SafetyNet que não reflete o status real do dispositivo."Recentemente, porém, os usuários notaram que seus dispositivos desbloqueados pelo bootloader estão falhando na verificação de integridade básica do SafetyNet, embora tenham usado o Magisk para corrigir a imagem de inicialização. De acordo com topjohnwu, isso ocorre porque o Google pode ter implementado o atestado de chave em nível de hardware para verificar se a imagem de inicialização não foi adulterada. Especificamente, isso significa que o Google Play Services "[envia] um certificado de armazenamento de chaves não modificado para servidores SafetyNet, verifica sua legitimidade e verifica dados de extensão de certificado para saber se o seu dispositivo [tem] inicialização verificada habilitada (status do bootloader)." Isso significa que pode não ser mais é possível ocultar o fato de que o bootloader foi desbloqueado, o que fará com que aplicativos como Google Pay e Pokémon Go não funcionem normalmente.
Como observou topjohnwu, essa mudança na maneira como o SafetyNet verifica o status de desbloqueio do bootloader ocorre por meio de uma atualização do lado do servidor para a API SafetyNet contida no Google Play Services. No entanto, nem todos os usuários estão falhando nessas verificações atualizadas do SafetyNet, portanto, o novo atestado de chave em nível de hardware ainda não pode ser amplamente aplicado.
Vimos topjohnwu superar obstáculos técnicos repetidas vezes. O Google frequentemente lança novas verificações no SafetyNet que topjohnwu descobre e ignora no Magisk. Cada nova versão do Android traz mudanças na estrutura da partição ou na imagem de inicialização, exigindo que topjohnwu estude as mudanças e então implemente um novo método de correção. No entanto, mesmo topjohnwu pode ter dificuldades para encontrar um desvio desta vez.
Isso ocorre porque a solução alternativa desta vez envolveria hackear o firmware do Trusted Execution Environment (TEE) dos dispositivos para recuperar a chave privada. No entanto, isso é incrivelmente difícil de fazer, pois requer encontrar uma vulnerabilidade no firmware projetado para ser incrivelmente seguro. Na verdade, muitas empresas oferecem pagamentos de centenas de milhares de dólares se tal vulnerabilidade for encontrada. O Google, por exemplo, paga US$ 250.000 por vulnerabilidades de execução remota de código no Trusted Execution Environment do Pixel, e até US$ 1.000.000 para vulnerabilidades no Titã M chip de segurança. Mesmo que uma chave privada vazasse de alguma forma, é improvável que fosse de muita utilidade, uma vez que Google pode revogar remotamente a chave portanto, não pode ser usado para verificar a integridade dos dispositivos.
Depois que o atestado de chave em nível de hardware for amplamente aplicado para SafetyNet, a maioria dos dispositivos com bootloaders desbloqueados executando Android 8.0 Oreo ou superior não conseguirá passar na verificação de integridade básica do SafetyNet. Isso ocorre porque todos os dispositivos lançados com Android 8.0 Oreo ou superior são obrigados a ter um keystore de hardware implementado em um TEE. Certos dispositivos hoje em dia possuem até módulos de segurança de hardware (HSMs) dedicados que tornam a exploração ainda mais difícil ao afastar o TEE do processador principal; o Titan M no Pixel 4 e O novo chip de segurança da Samsung no Galaxy S20 são exemplos disso.
Topjohnwu também explica que outras possíveis soluções alternativas são impossíveis ou altamente desafiadoras. Usar o Xposed Framework para modificar a API SafetyNet Attestation no Google Play Services provavelmente não funcionará, pois "as verificações adequadas do SafetyNet verificarão os resultados em um servidor remoto, não no [the] dispositivo que pode ser manipulado por estruturas de injeção de código." Além disso, o Google Play Services é altamente ofuscado, tornando a criação de tal módulo Xposed incrivelmente desafiadora no primeiro lugar. Falsificar o resultado de um teste SafetyNet também não será possível, já que as respostas do SafetyNet “vêm dos servidores do Google e são assinadas com a chave privada do Google”.
O Google tem conseguido fortalecer as verificações do SafetyNet usando atestado de chave apoiado por hardware há vários anos. O fato de terem se abstido de fazer isso por 3 anos permitiu que os usuários aproveitassem os módulos root e Magisk sem sacrificar a capacidade de usar aplicativos bancários. No entanto, parece que a capacidade do Magisk de ocultar efetivamente o status de desbloqueio do bootloader está chegando ao fim. É uma mudança que esperávamos há anos, mas estamos tristes por vê-la finalmente entrar em vigor. Esperamos que o Google atualize a API SafetyNet Attestation para retornar se a verificação de status usou base de hardware atestado, pois isso permitiria aos desenvolvedores de aplicativos decidir se desejam bloquear todos os usuários que desbloquearam o carregador de inicialização.
Obrigado a Daniel Micay (@DanielMicay) por sua contribuição sobre este assunto!