Sin root, sin exploits ni vulnerabilidades: Shizuku convierte una app en aplicación de sistema

Shizuku fue concebido como un método para dar a las aplicaciones Android habituales acceso a las API del sistema sin root, pero el mismo mecanismo convierte un único permiso en una llave casi universal para las funciones de ADB. El equipo de Pradeo comprobó la herramienta en Android 16 y descubrió que, tras la autorización, la aplicación obtiene permisos de shell del sistema con UID 2000.

En la prueba usaron Shizuku 13.6 en modo ADB sin root y una aplicación a la que no se le concedieron permisos de Android salvo acceso a Shizuku. De las 41 comandos verificados, 27 ejecutados a través de Shizuku devolvían más datos o desbloqueaban funcionalidades adicionales. La razón es que el servidor ejecuta los comandos en nombre del shell, no de la propia aplicación.

La diferencia fue notable incluso en una inventaria básica del dispositivo. Sin Shizuku, la aplicación de prueba veía 98 paquetes instalados, dos procesos propios y 284 líneas del registro del sistema. Tras conectarse al servicio, las cifras aumentaron a 261 paquetes, 382 procesos y 1978 líneas accesibles para el shell del sistema. Cinco comandos no funcionaron en ninguno de los modos.

Pradeo también reprodujo cuatro escenarios de abuso. La aplicación pudo leer secretos que otro programa dejó en logcat, instalar silenciosamente un APK de prueba sin la ventana del instalador y otorgarse acceso a los contactos sin una solicitud del sistema. Mediante el shell también se obtuvieron datos sobre cuentas, conexiones de red y uso de aplicaciones.

No obstante, Shizuku no concede al proceso shell acceso directo a los directorios privados de otras aplicaciones en /data/data, salvo que el paquete esté marcado como depurable. Tampoco se trata de una vulnerabilidad de Android ni de Shizuku: el mecanismo funciona según su diseño. El riesgo surge cuando el usuario permite a una aplicación de terceros ejecutar comandos a través de un servicio ya en ejecución. Un único consentimiento aplica de inmediato a todos esos comandos.

Un troyano real, RedHook, mostró una variante más peligrosa del mismo esquema. Tras obtener Accesibilidad mediante ingeniería social, el malware activa por sí mismo las opciones de desarrollador y la depuración inalámbrica, se conecta al ADB local y despliega su propio servidor basado en Shizuku. Tras un reinicio, RedHook puede volver a activar la depuración y recuperar privilegios en cuestión de segundos.

Los autores del análisis recomiendan prestar atención a opciones de desarrollador activadas inesperadamente y a la depuración USB o la depuración inalámbrica, a aplicaciones desconocidas con servicios de Accesibilidad y al servicio Shizuku en ejecución. Sin embargo, la presencia de Shizuku por sí sola no indica infección: la herramienta la utilizan programas legítimos para gestionar paquetes, realizar copias de seguridad, automatizar tareas y configurar el sistema.