La temida atestación de hardware de SafetyNet se está desplegando, lo que hace que sea mucho más difícil para Magisk ocultar root

En marzo, algunos usuarios con Magisk instalado notaron que sus dispositivos estaban fallando en la atestación de SafetyNet. Esta noticia fue preocupante para la comunidad de XDA porque significa que muchas aplicaciones bancarias y financieras cruciales y juegos populares como Pokémon Go y Fate/Grand Order se negaban a ejecutarse en dispositivos arraigados. Durante algún tiempo, parecía que las restricciones más estrictas en SafetyNet se habían retirado, solo para volver a implementarse 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 las respuestas de SafetyNet, que es lo que hizo que Magisk no pudiera ocultar el estado de desbloqueo del cargador de arranque en marzo. Si este cambio se implementa ampliamente, significará que los usuarios tendrán que elegir entre tener acceso a root / ROMs personalizadas / 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 recapitular esta serie de eventos, primero debemos hablar de SafetyNet en sí. SafetyNet es un conjunto de API de los servicios de Google Play. La API de certificación SafetyNet es una de esas API, y las aplicaciones de terceros pueden llamarla para comprobar si el entorno de software del dispositivo ha sido alterado de alguna manera. La API comprueba varias cosas, como signos de binarios de superusuario, el estado de desbloqueo del cargador de arranque y más. Cuando rootea un dispositivo con Magisk, es » un ‘entorno seguro’ aislado para el proceso de detección, y pasa por la API de Google para crear un resultado de red segura legítimo 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 mientras se asegura de que la API siempre devuelva «falso» para cualquier comprobación de desbloqueo del gestor de arranque. Este método de evitar la detección de desbloqueo del cargador de arranque de SafetyNet ha estado funcionando para Magisk durante los últimos años, pero eso es solo porque Google ha retenido la verificación de la integridad de la imagen de arranque utilizando la certificación de hardware. En marzo, parecía que Google finalmente estaba comenzando a emplear la certificación de hardware en SafetyNet para verificar la imagen de arranque, pero nunca recibimos una declaración oficial de Google que confirmara el cambio y solo unos pocos usuarios se vieron afectados. Sin embargo, como observó Displax, Miembro Senior de XDA, Google confirmó el 5 de mayo de 2020 que las respuestas de la API de Certificación de SafetyNet de algunos dispositivos ahora incluyen comprobaciones respaldadas por hardware.

En el Grupo de Google para «Clientes de la API SafetyNet», Google detalló una nueva función para la API de certificación: evaluationType. La respuesta de Firma Web JSON (JWS) de algunos dispositivos tendrá un campo llamado «Tipo de evaluación» que «proporcionará a los desarrolladores información sobre los tipos de señales/mediciones que han contribuido a cada respuesta individual de la API de certificación de SafetyNet».»Uno de los tokens compatibles en este campo es «HARDWARE_BACKED», que indica que la API » las características de seguridad respaldadas por hardware disponibles del dispositivo remoto (por ejemplo, la certificación de claves respaldadas por hardware) influyen en la evaluación.»Google dice que actualmente están evaluando y ajustando los criterios de elegibilidad para dispositivos en los que dependeremos de características de seguridad respaldadas por hardware.»Lo que esto significa es que, en algunos dispositivos, Google Play Services ahora está utilizando 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 usan SafetyNet pueden no estar al tanto de este cambio (y por lo tanto aún no están revisando el campo «HARDWARE_BACKED» en las respuestas de JWS.) Sin embargo, para aquellas aplicaciones que están comprobando este campo, ahora no hay forma de ocultarles el acceso de root, siempre que su dispositivo sea parte de la prueba que Google está ejecutando.

Respuesta de la API de certificación de SafetyNet con el tipo de evaluación que devuelve «BÁSICO».» Crédito: Desplazamiento de Miembro Senior de XDA
Respuesta de SafetyNet BASIC y HARDWARE_BACKED
Respuesta de la API de certificación de SafetyNet con el tipo de evaluación que devuelve «BASIC» y «HARDWARE_BACKED».»Créditos: XDA Senior Member Displax

De acuerdo con topjohnwu, la certificación respaldada por hardware significa que Google Play Services now» es un certificado de almacén de claves sin modificar para los servidores SafetyNet, su legitimidad y los datos de extensión de certificados para saber si el dispositivo verificó el arranque habilitado (estado del cargador de arranque).»Dado que las claves privadas de las que se derivan los certificados del almacén de claves están respaldadas por el entorno seguro aislado del teléfono, recuperarlas implicaría derrotar la seguridad del Entorno de ejecución confiable (TEE) o el módulo de seguridad de hardware dedicado (HSM) del teléfono. Si de alguna manera se pudiera filtrar una clave privada, las claves se revocarían rápidamente una vez que Google se enterara. 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 esta sea una vía potencial para evitar la detección de desbloqueo del cargador de arranque de todos modos.

Otra posible forma en que Magisk podría seguir 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. Sin embargo, como señala topjohnwu, esto requeriría inyectar código personalizado en los servicios de Google Play a través de un marco de conexión como el marco Xposed. Esto no solo es difícil de hacer porque los servicios de Google Play son muy confusos, sino que también es imposible de ocultar, ya que «algunos análisis de espacio de memoria revelarán la manipulación del código con mucha facilidad.»Además, esto solo funcionaría si los servidores de Google continúan aceptando evaluaciones BÁSICAS y si las evaluaciones basadas en HARDWARE no se aplican en los dispositivos que las admiten. (Las respuestas de SafetyNet «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 se pueden falsificar.)

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 cargador de arranque afectará a la mayoría de los dispositivos que existen. 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 de root y las aplicaciones bancarias.

Desafortunadamente, es probable que haya muchas aplicaciones que usan comprobaciones de SafetyNet cuando en realidad no lo 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 cargador de arranque. En Twitter, topjohnwu llama a las aplicaciones que abusan de la API como creando un entorno hostil para los usuarios avanzados. Quinny899, reconocido desarrollador de XDA, se une con una anécdota sobre cómo su equipo consideró usar SafetyNet para verificar el estado de seguridad del dispositivo. En última instancia, decidieron no hacerlo, ya que la aplicación de su equipo encripta todos los datos confidenciales con los que trabaja. SafetyNet, argumenta, no debe usarse en lugar de las prácticas adecuadas de seguridad y manejo de datos, especialmente cuando se considera la posibilidad de exploits de superusuario.

Soy partidario de @AndroidDev para restringir la evaluación de redes seguras respaldadas por hardware a aplicaciones» reales » sensibles a la seguridad. Los desarrolladores deben pasar por un proceso de solicitud para calificar este nivel de acceso a la API. Es ridículo que McDonalds se niegue a ejecutarse en un dispositivo desbloqueado con cargador de arranque.

– John Wu (@topjohnwu) Junio 29, 2020

Para obtener más información sobre cómo el nuevo cambio de SafetyNet afecta a Magisk, consulta las excelentes preguntas frecuentes de topjohnwu en Twitter. Si solo quieres comprobar si tu dispositivo forma parte de la nueva prueba SafetyNet de Google, puedes seguir esta guía de XDA Senior Member Displax o descargar la última versión de Magisk Manager.

Magisk Manager actualizado para reflejar el campo Tipo de evaluación en las comprobaciones de SafetyNet para que las personas puedan comenzar a contar los últimos días de gloria < pic.twitter.com/x61tGjM7IK

– John Wu (@topjohnwu) Junio 30, 2020

Este artículo se actualizó a las 10:46 AM EST del 30 de junio de 2020 para corregir que Google solo paga recompensas por vulnerabilidades de TEE encontradas en teléfonos Pixel. Además, se agregaron detalles sobre la última versión de Magisk Manager, que ahora muestra el campo evaluationType en el comprobador de red segura integrado.

Lea Esto A Continuación


  • Google forma Android Ready SE Alliance para impulsar la adopción de llaves de coche digitales y licencias de conducir


  • Fairphone 2 de 2015 ahora recibe la actualización oficial de Android 9 Pie


  • El Moto G50 de Motorola tiene un chip 5G económico y un precio bajo


  • ASUS lanza nuevas actualizaciones para ROG Phone 5, ROG Phone 3 y ROG Phone II con parches de seguridad y correcciones de errores


«

+