Ocultar o acesso root no Magisk está prestes a se tornar muito mais difícil graças a uma mudança recente no SafetyNet que traz atestado de hardware.
Em março, alguns usuários com Magisk instalado percebido que seus dispositivos estavam falhando no atestado SafetyNet. Esta notícia foi preocupante para a comunidade do XDA porque significa que muitos aplicativos bancários/financeiros cruciais e jogos populares como Pokémon Go e Fate/Grand Order se recusavam a rodar em dispositivos com acesso root. Por algum tempo, parecia que as restrições mais rígidas do SafetyNet foram retiradas, apenas para serem implementadas novamente para alguns usuários nas últimas semanas. No entanto, o Google confirmou discretamente no início de maio que estava testando o atestado baseado em hardware para Respostas SafetyNet, que foi o que tornou o Magisk incapaz de ocultar o status de desbloqueio do bootloader Marchar. Se essa mudança for amplamente implementada, isso significará que os usuários terão que escolher entre ter acesso a root/ROMs/kernels personalizados/etc. ou seus aplicativos e jogos bancários preferidos. Um dos maiores apelos do Android para usuários avançados poderá desaparecer em breve.
Para recapitular esta série de eventos, devemos primeiro falar sobre o próprio SafetyNet. SafetyNet é um conjunto de APIs no Google Play Services. A API SafetyNet Attestation é uma dessas APIs e pode ser chamada por aplicativos de terceiros para verificar se o ambiente de software do dispositivo foi adulterado de alguma forma. A API verifica várias coisas, como sinais de binários de superusuário, status de desbloqueio do bootloader e muito mais. Quando você faz root em um dispositivo com Magisk, ele “[cria] um ‘ambiente seguro’ isolado para o processo de detecção [SafetyNet] e passa pela API do Google para criar um legítimo Resultado SafetyNet que não reflete o status real do dispositivo”, de acordo com XDA Senior Recognized Developer topjohnwu. Isso permite que o usuário faça root em seu telefone, garantindo que a API sempre retorne "falso" para qualquer verificação de desbloqueio do bootloader. Este método de contornar a detecção de desbloqueio do bootloader do SafetyNet tem funcionado para o Magisk nos últimos anos, mas isso ocorre apenas porque o Google adiou a verificação da integridade da imagem de inicialização usando hardware atestado. Em março, parecia que o Google estava finalmente começando a empregar atestação de hardware no SafetyNet para verificar o imagem de inicialização, mas nunca recebemos uma declaração oficial do Google confirmando a mudança e apenas alguns usuários foram afetado. Conforme descoberto pelo membro sênior do XDA Displax, no entanto, o Google confirmou em 5 de maio de 2020 que as respostas da API SafetyNet Attestation de alguns dispositivos agora incluem verificações baseadas em hardware.
No Grupo do Google para “Clientes da API SafetyNet”, o Google detalhou um novo recurso para a API Attestation: avaliaçãoType. A resposta JSON Web Signature (JWS) de alguns dispositivos terá um campo chamado "evaluationType" que "fornecerá aos desenvolvedores informações nos tipos de sinais/medições que contribuíram para cada resposta individual da API SafetyNet Attestation." Um dos tokens suportados neste campo está "HARDWARE_BACKED" que indica que a API "[usou] os recursos de segurança disponíveis com suporte de hardware do dispositivo remoto (por exemplo. atestado de chave apoiado por hardware) para influenciar [sua] avaliação." O Google diz que eles estão "atualmente avaliando e ajustando os critérios de elegibilidade para dispositivos onde contaremos com suporte de hardware recursos de segurança." Isso significa que, em alguns dispositivos, o Google Play Services agora usa atestado baseado em hardware para detectar que o software do dispositivo não foi adulterado. O Google não documentou oficialmente essa mudança fora do anúncio no Grupo do Google, portanto, alguns desenvolvedores que usam o SafetyNet podem não está ciente dessa alteração (e, portanto, ainda não está verificando o campo "HARDWARE_BACKED" nas respostas do JWS). No entanto, para os aplicativos que estão verificando esse campo, agora não há como ocultar o acesso root deles, desde que seu dispositivo faça parte do teste que o Google está correndo.
De acordo com topjohnwu, o atestado apoiado por hardware significa que o Google Play Services agora “[envia] um certificado de armazenamento de chaves não modificado para servidores SafetyNet, [verifica] sua legitimidade e [verifica] os dados da extensão do certificado para saber se o seu dispositivo [tem] inicialização verificada habilitada (status do bootloader). Como as chaves privadas das quais os certificados de armazenamento de chaves são derivados são apoiados pelo ambiente seguro isolado do telefone, recuperá-los envolveria derrotar a segurança do Trusted Execution Environment (TEE) do telefone ou da segurança de hardware dedicada módulo (HSM). Se alguém fosse capaz de vazar uma chave privada, o chaves seriam rapidamente revogadas assim que o Google descobriu. O Google oferece centenas de milhares de dólares em recompensas por quaisquer vulnerabilidades críticas de segurança que afetem o TEE em telefones Pixel, o que apenas mostra que é incrivelmente improvável que este seja um caminho potencial para contornar a detecção de desbloqueio do bootloader de qualquer forma.
Outra maneira potencial de o Magisk continuar a falsificar o status de desbloqueio do bootloader é modificando o código do lado do cliente do SafetyNet para sempre usar a avaliação BASIC. Como notas de topjohnwu, porém, isso exigiria a injeção de código personalizado no Google Play Services por meio de uma estrutura de conexão como o Xposed Framework. Isso não é apenas difícil de fazer porque o Google Play Services é altamente ofuscado, mas também é impossível de esconder, pois "algumas análises de espaço de memória revelarão manipulação de código muito facilmente." Além disso, isso também só funcionaria se os servidores do Google continuassem a aceitar avaliações BASIC e se as avaliações HARDWARE_BACKED não fossem aplicadas em dispositivos que suportam eles. (As respostas do SafetyNet “[vêm] dos servidores do Google e são assinadas com a chave privada do Google”, de acordo com topjohnwu, portanto, as respostas reais não podem ser falsificadas.)
Desde o Android 7 Nougat, o Google exige que todos os dispositivos tenham um ambiente seguro e isolado, o que significa que esta mudança na forma como o SafetyNet verifica o desbloqueio do bootloader afetará a maioria dos dispositivos que estão fora lá. Como dispositivos mais antigos sem um ambiente seguro isolado obviamente não podem realizar atestados baseados em hardware, o Magisk ainda será capaz de ocultar o acesso root nesses dispositivos. Mas se essa mudança for amplamente implementada, todos os outros terão que fazer uma escolha difícil entre acesso root e aplicativos bancários.
Infelizmente, provavelmente existem muitos aplicativos por aí que usam verificações do SafetyNet quando na verdade não são necessários. Um exemplo citado por topjohnwu é o aplicativo oficial do McDonald's, que aparentemente se recusa a rodar em um dispositivo desbloqueado com bootloader. No Twitter, topjohnwu chama os aplicativos que usam excessivamente a API por criarem um ambiente hostil para usuários avançados. Desenvolvedor reconhecido pelo XDA Quinny899 conta uma anedota sobre como sua equipe considerou usar o SafetyNet para verificar o status de segurança do dispositivo. No final das contas, eles decidiram não prosseguir com isso, já que o aplicativo de sua equipe criptografa todos os dados confidenciais com os quais trabalha. O SafetyNet, argumenta ele, não deve ser usado no lugar de práticas adequadas de segurança e tratamento de dados, especialmente quando se considera o possibilidade de explorações de superusuários.
Para obter mais informações sobre como a nova mudança do SafetyNet afeta o Magisk, confira topjohnwu's excelente FAQ no Twitter. Se você deseja apenas verificar se o seu dispositivo faz parte do novo teste SafetyNet do Google, você pode seguir este guia por XDA Senior Member Displax ou baixe a versão mais recente do Magisk Manager.
Este artigo foi atualizado às 10h46 EST do dia 30 de junho de 2020, para corrigir que o Google só paga recompensas por vulnerabilidades TEE encontradas em telefones Pixel. Além disso, foram adicionados detalhes sobre a versão mais recente do Magisk Manager, que agora mostra o campo AssessmentType no verificador SafetyNet integrado.