El desarrollador de Magisk ha descubierto que es posible que Google haya comenzado a utilizar comprobaciones de hardware para determinar si un dispositivo ha sido desbloqueado con el gestor de arranque.
Desarrollador reconocido por XDA topjohnwuEl proyecto "Magisk" se ha convertido esencialmente en sinónimo de "root" en la comunidad de Android. Una de las principales razones por las que es tan popular es porque puede ocultar el hecho de que el usuario ha modificado su dispositivo. Sin embargo, es posible que Google esté tomando medidas enérgicas contra la capacidad de Magisk para ocultar el estado de desbloqueo del gestor de arranque de las aplicaciones.
Para rootear su teléfono, generalmente necesita desbloquear el gestor de arranque, lo que le permite mostrar imágenes de arranque modificadas. Esto es necesario porque Magisk modifica la imagen de arranque para falsificar el estado del cargador de arranque y/o las comprobaciones del estado de arranque verificado. La API SafetyNet Attestation de Google, que forma parte de los servicios de Google Play, se utiliza para indicarle a una aplicación si se está ejecutando en un dispositivo manipulado; Si la API de SafetyNet detecta que el gestor de arranque se ha desbloqueado, devolverá un estado de error para la verificación de "Integridad básica". Los dispositivos que no superen esta verificación se pueden bloquear de las aplicaciones que utilizan la API SafetyNet para determinar la integridad del dispositivo; Estas aplicaciones suelen incluir aplicaciones bancarias, aplicaciones de pago (como Google Pay) y muchos juegos en línea (como Pokémon Go). Sin embargo, debido a que hasta ahora la API SafetyNet solo ha utilizado comprobaciones de software para determinar si el dispositivo ha sido manipulado, Magisk puede simplemente falsificar el gestor de arranque y/o estado de arranque verificado, ya que está instalado en un nivel inferior y con privilegios más altos que los servicios de Google Play y otros espacios de usuario. aplicaciones. Como explica topjohnwu, MagiskHide "[crea] un 'entorno seguro' aislado para el proceso de detección, y pasa por la API de Google para crear un
legal Resultado de SafetyNet que no refleja el estado real del dispositivo."Sin embargo, recientemente, los usuarios han notado que sus dispositivos desbloqueados con el gestor de arranque no pasan la verificación de integridad básica de SafetyNet a pesar de que usaron Magisk para parchear la imagen de arranque. Según topjohnwu, esto se debe a que es posible que Google haya implementado una certificación de clave a nivel de hardware para verificar que la imagen de arranque no haya sido manipulada. Específicamente, esto significa que los Servicios de Google Play "[envían] un certificado de almacén de claves no modificado a los servidores SafetyNet, verifican su legitimidad y verifican datos de extensión del certificado para saber si su dispositivo [tiene] habilitado el arranque verificado (estado del cargador de arranque)". Esto significa que es posible que ya no esté disponible. Es posible ocultar el hecho de que el gestor de arranque se ha desbloqueado, lo que provocará que aplicaciones como Google Pay y Pokémon Go no funcionen. normalmente.
Como señaló topjohnwu, este cambio en la forma en que SafetyNet verifica el estado de desbloqueo del gestor de arranque se produce a través de una actualización del lado del servidor de la API de SafetyNet contenida en los servicios de Google Play. Sin embargo, no todos los usuarios fallan estas comprobaciones actualizadas de SafetyNet, por lo que es posible que la nueva certificación de clave a nivel de hardware aún no se aplique ampliamente.
Hemos visto a topjohnwu superar obstáculos técnicos una y otra vez. Google implementa con frecuencia nuevas comprobaciones en SafetyNet que luego topjohnwu descubre y elude en Magisk. Cada nueva versión de Android trae cambios en la estructura de la partición o la imagen de arranque, lo que requiere que topjohnwu estudie los cambios y luego implemente un nuevo método de parcheo. Sin embargo, esta vez incluso topjohnwu puede tener dificultades para encontrar una vía de circunvalación.
Esto se debe a que la solución esta vez implicaría piratear el firmware del entorno de ejecución confiable (TEE) de los dispositivos para recuperar la clave privada. Sin embargo, esto es increíblemente difícil de hacer ya que requiere encontrar una vulnerabilidad en el firmware que está diseñado para ser increíblemente seguro. De hecho, muchas empresas ofrecen pagos de cientos de miles de dólares si se encontrara tal vulnerabilidad. Google, por ejemplo, paga 250.000 dólares por vulnerabilidades de ejecución remota de código en el entorno de ejecución confiable de Pixel, y hasta $1.000.000 para vulnerabilidades en el Titán M chip de seguridad. Incluso si de alguna manera se filtrara una clave privada, es poco probable que fuera de mucha utilidad ya que Google puede revocar la clave de forma remota por lo que no se puede utilizar para verificar la integridad de los dispositivos.
Una vez que se aplique ampliamente la certificación de claves a nivel de hardware para SafetyNet, la mayoría de los dispositivos con cargadores de arranque desbloqueados que ejecutan Android 8.0 Oreo o superior no pasarán la verificación de integridad básica de SafetyNet. Esto se debe a que todos los dispositivos que se iniciaron con Android 8.0 Oreo o superior deben tener un almacén de claves de hardware implementado en un TEE. Algunos dispositivos hoy en día incluso tienen módulos de seguridad de hardware (HSM) dedicados que dificultan aún más la explotación al alejar el TEE del procesador principal; el Titan M en el Pixel 4 y El nuevo chip de seguridad de Samsung en el Galaxy S20 son ejemplos de ello.
topjohnwu también explica que otras posibles soluciones son imposibles o muy desafiantes. Es probable que el uso de Xposed Framework para modificar la API de atestación de SafetyNet en los servicios de Google Play no funcione ya que "las comprobaciones adecuadas de SafetyNet verificarán los resultados en un servidor remoto, no en [el] dispositivo que puede ser manipulado mediante marcos de inyección de código". Además, los servicios de Google Play están muy ofuscados, lo que hace que la creación de un módulo Xposed de este tipo sea increíblemente desafiante en la primera lugar. Tampoco será posible falsificar el resultado de una prueba de SafetyNet, ya que las respuestas de SafetyNet "provienen de los servidores de Google y están firmadas con la clave privada de Google".
Google ha tenido la capacidad de reforzar las comprobaciones de SafetyNet utilizando una certificación de clave respaldada por hardware desde hace varios años. El hecho de que se abstuvieran de hacerlo durante 3 años ha permitido a los usuarios disfrutar de los módulos raíz y Magisk sin sacrificar la capacidad de utilizar aplicaciones bancarias. Sin embargo, parece que la capacidad de Magisk para ocultar eficazmente el estado de desbloqueo del gestor de arranque pronto llegará a su fin. Es un cambio que esperábamos desde hace años, pero nos entristece ver que finalmente entra en vigor. Esperamos que Google actualice la API de atestación SafetyNet para indicar si la verificación de estado utilizó hardware. atestación, ya que esto permitiría a los desarrolladores de aplicaciones decidir si quieren bloquear a todos los usuarios que hayan desbloqueado la gestor de arranque.
Gracias a Daniel Micay (@danielmicay) por su aporte sobre este asunto!