Ocultar el acceso de root en Magisk está a punto de volverse mucho más difícil gracias a un cambio reciente en SafetyNet que brinda certificación de hardware.
En marzo, algunos usuarios con Magisk instalado observó que sus dispositivos no superaban la certificación SafetyNet. Esta noticia fue preocupante para la comunidad de XDA porque significa que muchas aplicaciones bancarias/financieras cruciales y juegos populares como Pokémon Go y Fate/Grand Order se negaban a ejecutarse en dispositivos rooteados. Durante algún tiempo, pareció que las restricciones más estrictas en SafetyNet se habían retirado, solo para implementarse nuevamente para un puñado de usuarios en las últimas semanas. Sin embargo, Google confirmó silenciosamente a principios de mayo que estaban probando la certificación respaldada por hardware para Respuestas de SafetyNet, que es lo que hizo que Magisk no pudiera ocultar el estado de desbloqueo del gestor de arranque en Marzo. Si este cambio se implementa ampliamente, significará que los usuarios tendrán que elegir entre tener acceso a root/ROM personalizados/kernels/etc. o sus aplicaciones y juegos bancarios preferidos. Uno de los mayores atractivos de Android para los usuarios avanzados podría desaparecer pronto.
Para resumir esta serie de eventos, primero deberíamos hablar de SafetyNet en sí. SafetyNet es un conjunto de API en los servicios de Google Play. La API SafetyNet Attestation es una de esas API y puede ser invocada por aplicaciones de terceros para verificar si el entorno de software del dispositivo ha sido manipulado de alguna manera. La API busca varias cosas, como signos de archivos binarios de superusuario, el estado de desbloqueo del gestor de arranque y más. Cuando rooteas un dispositivo con Magisk, “[crea] un ‘entorno seguro’ aislado para el proceso de detección [SafetyNet] y pasa por la API de Google para crear un legal Resultado de SafetyNet que no refleja el estado real del dispositivo”, según el desarrollador reconocido senior de XDA topjohnwu. Esto permite al usuario rootear su teléfono y al mismo tiempo garantiza que la API siempre devuelva "falso" para cualquier verificación de desbloqueo del gestor de arranque. Este método para evitar la detección de desbloqueo del gestor de arranque de SafetyNet ha funcionado para Magisk durante los últimos años. años, pero eso es sólo porque Google ha pospuesto la verificación de la integridad de la imagen de arranque mediante hardware atestación. En marzo, parecía que Google finalmente estaba comenzando a emplear la certificación de hardware en SafetyNet para verificar la imagen de inicio, pero nunca recibimos una declaración oficial de Google confirmando el cambio y solo unos pocos usuarios fueron afectado. Según lo descubierto por el miembro senior de XDA mostrarSin embargo, Google confirmó el 5 de mayo de 2020 que las respuestas de la API de atestación SafetyNet de algunos dispositivos ahora incluyen verificaciones respaldadas por hardware.
En el grupo de Google para "Clientes de API SafetyNet", Google detalló una nueva característica para la API de atestación: tipo de evaluación. La respuesta JSON Web Signature (JWS) de algunos dispositivos tendrá un campo llamado "tipo de evaluación" que "proporcionará a los desarrolladores información en los tipos de señales/mediciones que han contribuido a cada respuesta individual de la API de atestación de SafetyNet". Uno de los tokens admitidos en este campo está "HARDWARE_BACKED", lo que indica que la API "[usó] las funciones de seguridad respaldadas por hardware disponibles del dispositivo remoto (p.ej. atestación de clave respaldada por hardware) para influir en [su] evaluación". Google dice que "actualmente están evaluando y ajustando los criterios de elegibilidad para dispositivos en los que dependeremos de dispositivos respaldados por hardware". características de seguridad". Lo que esto significa es que, en algunos dispositivos, los servicios de Google Play ahora utilizan una certificación respaldada por hardware para detectar que el software del dispositivo no ha sido manipulado. Google no ha documentado oficialmente este cambio fuera del anuncio en el Grupo de Google, por lo que algunos desarrolladores que utilizan SafetyNet pueden No esté al tanto de este cambio (y por lo tanto aún no está verificando el campo "HARDWARE_BACKED" en las respuestas de JWS). Sin embargo, para aquellas aplicaciones que están verificando este campo, ahora no hay forma de ocultarles el acceso de root, siempre que su dispositivo sea parte de la prueba que Google está realizando. correr.
Según topjohnwu, la certificación respaldada por hardware significa que Google Play Services ahora “[envía] un certificado de almacén de claves sin modificar a los servidores SafetyNet, [verifica] su legitimidad y [comprueba] los datos de extensión del certificado para saber si su dispositivo [tiene] habilitado el arranque verificado (estado del cargador de arranque)”. Dado que las claves privadas de las que se derivan los certificados del almacén de claves están respaldados por el entorno seguro aislado del teléfono, recuperarlos implicaría anular la seguridad del entorno de ejecución confiable (TEE) del teléfono o la seguridad de hardware dedicada. módulo (HSM). Si de alguna manera uno fuera capaz de filtrar una clave privada, el las claves serían rápidamente revocadas una vez que Google se enteró. Google ofrece cientos de miles de dólares en recompensas por cualquier vulnerabilidad de seguridad crítica que afecte al TEE en los teléfonos Pixel. lo que demuestra que es increíblemente improbable que esto sea una vía potencial para evitar la detección de desbloqueo del gestor de arranque. de todos modos.
Otra forma potencial en la que Magisk podría continuar falsificando el estado de desbloqueo del gestor de arranque es modificando el código del lado del cliente de SafetyNet para usar siempre la evaluación BÁSICA. Como notas de topjohnwuSin embargo, esto requeriría inyectar código personalizado en los servicios de Google Play a través de un marco de enlace como Xposed Framework. Esto no sólo es difícil de hacer porque los Servicios de Google Play están muy confusos, sino que también es imposible de ocultar ya que "algunos análisis del espacio de memoria revelarán una manipulación del código muy fácilmente". Además, esto solo funcionaría si los servidores de Google continúan aceptando evaluaciones BÁSICAS y si las evaluaciones HARDWARE_BACKED no se aplican en los dispositivos que admiten a ellos. (Las respuestas de SafetyNet "[provienen] de los servidores de Google y están firmadas con la clave privada de Google", según topjohnwu, por lo que las respuestas reales no pueden ser falsificadas).
Desde Android 7 Nougat, Google ha exigido que todos los dispositivos tengan un entorno seguro aislado, lo que significa que este cambio en la forma en que SafetyNet verifica el desbloqueo del gestor de arranque afectará a la mayoría de los dispositivos que están fuera de servicio. allá. Dado que los dispositivos más antiguos sin un entorno seguro aislado obviamente no pueden realizar una certificación respaldada por hardware, Magisk aún podrá ocultar el acceso de root en esos dispositivos. Pero si este cambio se implementa ampliamente, todos los demás tendrán que tomar una decisión difícil entre el acceso raíz y las aplicaciones bancarias.
Desafortunadamente, probablemente existan muchas aplicaciones que utilizan comprobaciones de SafetyNet cuando en realidad no las necesitan. Un ejemplo citado por topjohnwu es la aplicación oficial de McDonald's, que aparentemente se niega a ejecutarse en un dispositivo desbloqueado con gestor de arranque. En Twitter, topjohnwu denuncia que las aplicaciones que hacen un uso excesivo de la API crean un entorno hostil para los usuarios avanzados. Desarrollador reconocido por XDA quinny899 se suma con una anécdota sobre cómo su equipo consideró usar SafetyNet para verificar el estado de seguridad del dispositivo. Al final decidieron no seguir adelante, ya que la aplicación de su equipo cifra todos los datos confidenciales con los que trabaja. Sostiene que SafetyNet no debe utilizarse en lugar de prácticas adecuadas de seguridad y manejo de datos, especialmente cuando se considera la posibilidad de exploits de superusuario.
Para obtener más información sobre cómo el nuevo cambio de SafetyNet afecta a Magisk, consulte el artículo de topjohnwu. excelentes preguntas frecuentes en Twitter. Si solo desea verificar si su dispositivo es parte de la nueva prueba SafetyNet de Google, puede seguir esta guía por Displax, miembro senior de XDA, o descargue la última versión de Magisk Manager.
Este artículo se actualizó a las 10:46 a. m. EST del 30 de junio de 2020 para corregir que Google solo paga recompensas por las vulnerabilidades TEE encontradas en los teléfonos Pixel. Además, se agregaron detalles sobre la última versión de Magisk Manager, que ahora muestra el campo tipo de evaluación en el verificador SafetyNet integrado.