Magisk Hide es una funcionalidad de la suit de software open source llamada Magisk desarrollada para evitar que las aplicaciones detecten que el dispositivo ha sido rooteado. En este post vamos a analizar las técnicas utilizadas por Magisk Hide para luego determinar cómo ayudar a los desarrolladores que necesiten implementar las mejores prácticas de seguridad para la detección de root considerando esta técnica.

Antes de comenzar, vale la pena mencionar que el proceso de rooteo de un dispositivo es peligroso y muchos usuarios buscan e implementan este proceso, conociendo o no las consecuencias que podría causar.

Dicho esto, el rooting es un proceso que permite obtener permisos de administrador sobre teléfonos inteligentes, tabletas y otros dispositivos del sistema operativo móvil Android. Esta característica es utilizada comúnmente para mejorar el rendimiento del dispositivo, extender el uso de la batería, realizar modificaciones al sistema operativo o liberarse de algunas restricciones impuestas por el fabricante. Sin embargo, existen diversos riesgos asociados que podrían poner en segundo plano a las utilidades anteriormente mencionadas. Si quieres conocer los riesgos que implican que un dispositivo cuente con esta característica, recomendamos leer la nota Mitos de la seguridad móvil #2: el rooting o jailbreaking no afectan la protección”.

Considerando los riesgos de seguridad a los que pueden estar sujetos los usuarios que deciden rootear o realizar jailbreak en sus dispositivos, muchas de las aplicaciones (banca electrónica, video juegos, Fintech) buscan identificar y prevenir que su aplicación sea ejecutada en ambientes con las particularidades del rooteo; sin embargo, a través de Magisk Hide, cuya principal función es evitar que las detecciones de root impidan la ejecución de una determinada aplicación y que la misma pueda funcionar correctamente en ambientes rooteados, la tarea para los desarrolladores se ha vuelto más compleja.

Magisk Hide: cómo funciona y cómo identificar la presencia de root en un dispositivo

Muchas de las detecciones de root surgen a partir de la verificación de rutas y archivos comunes que puedan servir como un indicio para saber si en el dispositivo se pueden ejecutar comandos con privilegios de administrador, obtener los nombres de los paquetes o identificadores de las aplicaciones más populares como SuperSU y el mismo Magisk. Sin embargo, Magisk viene siendo un proyecto con mucha participación y permite cambiar su propio nombre e identificador de paquete por uno aleatorio, y cambiar las propiedades del dispositivo a valores “normales” que pasan desapercibidos por la misma detección.

Imagen 1. Pantalla de Inicio de la aplicación Magisk, utilizando el cambio aleatorio de nombre.

Acciones para los desarrolladores interesados en mejorar la seguridad de sus aplicaciones

A partir de las actualizaciones más recientes, la aplicación cuenta con una característica de ocultación completa (Full Hide Capability). ¿Qué nos da a entender esto? Que el proceso no siempre fue excelente. Una publicación del investigador darvincisec descubrió que en versiones anteriores a la actual no se estaban escondiendo las rutas de Magisk cargadas cuando un servicio era ejecutado. Debido a esto, el servicio podía estar corriendo en el mismo ambiente que la aplicación o en un proceso diferente dependiendo de la configuración establecida en el archivo de manifiesto, y si era un ambiente distinto al de la aplicación se podía aprovechar el servicio para poder detectar ciertas rutas de Magisk. Esto funcionaba perfecto en versiones anteriores a Android 9.0.+ y, como dijimos anteriormente, en versiones anteriores de Magisk. Sin embargo, es importante conocer cómo fue posible aprovechar el uso de los servicios para la detección y considerar aplicar las medidas mencionadas a continuación.

Muchas de las características de Magisk Hide surgen de las detecciones recomendadas por especialistas para saber si el dispositivo está o no rooteado, y tomando como base el marco de referencia OWASP, recomendamos revisar la existencia de archivos comunes, tales como:

  • /system/app/Superuser.apk
  • /system/etc/init.d/99SuperSUDaemon
  • /dev/com.koushikdutta.superuser.daemon/
  • /system/xbin/daemonsu
  • /sbin/su
  • /system/bin/su
  • /system/bin/failsafe/su
  • /system/xbin/su
  • /system/xbin/busybox
  • /system/sd/xbin/su
  • /data/local/su
  • /data/local/xbin/su
  • /data/local/bin/su

Validar que existan los binarios correspondientes para ejecutar comandos con privilegios elevados. Determinar su existencia intentando ejecutar el comando su. También es recomendable tener en consideración las rutas predefinidas por Magisk, tal como se muestra en la siguiente imagen.

Imagen 2. Definición de archivos y rutas para detectar Magisk

Realizando diversas pruebas con el proyecto de rootInspector, que cuenta con implementaciones de JNI para detectar los binarios comunes, es posible determinar la existencia de /system/xbin/su con el fragmento de código desarrollado en C++.

Imagen 3. Fragmento de código en C++.

Aun cuando Magisk Hide está habilitado para la aplicación de prueba, tal como se puede observar en la Imagen 4, dentro de las aplicaciones listadas esta seleccionado el paquete de prueba con el código anterior, y dentro de las detecciones que implementa el proyecto se puede apreciar en la Imagen 5 la detección del binario /system/xbin/su en un dispositivo rooteado con Android 10.

Pese a que en un sistema operativo Android 9.0+ no es posible detectar Magisk con un servicio ejecutado en un ambiente diferente (tal como lo mencionamos anteriormente), esperemos que esto sea de utilidad para los desarrolladores que se encuentren aplicando medidas contra la detección root.

Conclusiones

La propia recomendación del Testing Guide de OWASP Mobile Security al momento de implementar cualquier técnica de detección habla sobre los criterios a considerar al momento de trabajar algún esquema que contemple al menos los siguientes puntos:

  • Múltiples métodos de detección a lo largo del desarrollo de las aplicaciones y no solo al inicio cuando la aplicación es lanzada.
  • La implementación de los métodos en múltiples capas de la aplicación, desde el mismo código en el lenguaje nativo, llamada a funciones del sistema, o por medio de los servicios, utilizando la técnica descrita por el investigador darvincisec.
  • El desarrollo de funciones que sean originales; es decir, que tengan un grado de dificultad adicional para evitar ser fáciles de identificar y no copiadas de StackOverFlow o algún otro recurso (claro, la idea puede servir como base).

Considerando los puntos anteriores, vemos que es importante mantener las medidas ya conocidas por la comunidad de investigadores que aportan a proyectos de seguridad como OWASP. Sin embrago, es importante mencionar que el trabajo de investigación y las nuevas características de la misma plataforma Android deben ser aprovechadas, además de aplicar los múltiples métodos conocidos y de desarrollo propio para evitar que a algún actor externo le resulte sencillo evadir los mecanismos de protección de una aplicación.

Conforme pasa el tiempo existen nuevas técnicas, tanto de protección como para evadirlas, y para que esto no se convierta en el juego del gato y el ratón es importante combinar las técnicas de antiroot, antidebugging, antiemulation, y así tener una perspectiva mayor que permita elevar el nivel de seguridad de las aplicaciones desarrolladas.