En Android 17 el modo Advanced Protection cambia radicalmente las reglas del juego: solo las aplicaciones verificadas, marcadas como Accessibility Tools, obtienen acceso a AccessibilityService, mientras que todas las demás quedan bloqueadas, lo que corta uno de los canales clave para los troyanos bancarios y los programas espía, pero al mismo tiempo crea riesgos de compatibilidad para las aplicaciones legítimas que usan Accessibility fuera de su propósito directo; las organizaciones y los usuarios avanzados tendrán que inventariar previamente este tipo de aplicaciones y probar su funcionamiento en el nuevo modo.
Detalles técnicos de los cambios en Android 17
Según el blog oficial de seguridad de Google, en Android 17, cuando está activado Advanced Protection, el acceso a AccessibilityService se limita automáticamente solo a las aplicaciones que Google ha clasificado como Accessibility Tools. Todos los demás programas perderán la posibilidad de utilizar esta interfaz, incluso si antes el usuario les había otorgado manualmente los permisos correspondientes.
El AccessibilityService API es un framework potente que permite a una aplicación:
- trabajar en segundo plano;
- interceptar eventos de la interfaz de usuario;
- interactuar con otras aplicaciones en nombre del usuario.
Su propósito es ayudar a las personas con discapacidades (lectura de pantalla, control por voz, etc.), lo que se describe en la documentación oficial de AccessibilityService API. Sin embargo, ese mismo nivel de privilegios da al malware la posibilidad de observar y controlar el sistema en profundidad sin necesitar privilegios de root.
Pasos previos de protección en torno a Accessibility
Las nuevas restricciones en Android 17 complementan las medidas ya implementadas por Google contra el uso indebido de Accessibility:
- bloqueo de la activación de Accessibility para aplicaciones instaladas al margen de la tienda oficial (sideloading);
- protección durante las llamadas telefónicas, que impide que un atacante convenza al usuario por teléfono de desactivar Google Play Protect, instalar software de orígenes desconocidos o conceder permisos de Accessibility peligrosos;
- flag accessibilityDataSensitive, que los desarrolladores pueden establecer en elementos de la interfaz con datos confidenciales para que las aplicaciones potencialmente maliciosas no puedan leer el contenido ni emular acciones sobre esos elementos; este mecanismo se describe en el material técnico de Google sobre la protección frente a fugas de datos a través de Accessibility;
- modo Android Advanced Protection Mode (AAPM), que ya limitaba el uso de Accessibility para ciertos tipos de aplicaciones.
La nueva función de Android 17, de hecho, invierte el modelo por defecto: en lugar de «permitido para todos salvo los explícitamente prohibidos» se introduce el esquema «prohibido para todos salvo las Google Accessibility Tools explícitamente autorizadas», pero solo para los dispositivos con Advanced Protection activado.
Funciones de seguridad adicionales en Android 17
Además de la protección de Accessibility, Android 17 con Advanced Protection añade otros elementos de defensa reforzada (Google Security Blog):
- Intrusion Logging: registro continuo orientado a la privacidad para investigar ataques de espionaje complejos; se activa manualmente en los ajustes de Advanced Protection.
- USB Protection: protección frente al acceso no autorizado al dispositivo a través de una conexión física USB.
- Disable WebGPU: posibilidad de desactivar WebGPU en el navegador para reducir la superficie de ataque de exploits web complejos.
- Failed Authentication Lock: bloqueo completo del dispositivo tras una serie de intentos fallidos de autenticación, lo que dificulta el brute force y la prueba física de combinaciones.
- View Supporting Apps: interfaz que permite al usuario ver qué aplicaciones instaladas han comprobado el estado de Advanced Protection.
Los desarrolladores de aplicaciones pueden recibir una notificación sobre la activación de Advanced Protection y activar automáticamente funciones de protección adicionales o cambiar el comportamiento de la aplicación para esta categoría de usuarios (descripción oficial del mecanismo).
Contexto de amenazas: por qué Accessibility está en el punto de mira
El acceso a AccessibilityService hace tiempo que se convirtió en un objetivo prioritario del malware móvil. Según la descripción de Google, después de convencer al usuario para que active Accessibility con el pretexto de una «función avanzada» o de «acelerar el rendimiento», la aplicación maliciosa obtiene la posibilidad de:
- iniciar de forma programática transferencias fraudulentas de fondos desde aplicaciones financieras instaladas;
- interceptar pulsaciones de teclas y datos introducidos;
- crear pantallas de inicio de sesión falsas sobre aplicaciones legítimas;
- concederse permisos adicionales sensibles;
- leer datos confidenciales directamente de la pantalla;
- instalar otro software malicioso o bloquear su propia desinstalación.
El punto clave es que todo esto ocurre sin necesidad de explotar una vulnerabilidad del kernel ni de obtener root: el malware se apoya en una interfaz de sistema legítima, pero excesivamente potente. Por ello, trasladar el acceso a Accessibility a un modelo de «solo Accessibility Tools verificadas cuando Advanced Protection está activado» recorta toda una clase de ataques que se basaban exclusivamente en la ingeniería social y el posterior abuso del API.
Evaluación del impacto en organizaciones y usuarios
A quién afectan los cambios:
- usuarios de dispositivos con Android 17 que activan Advanced Protection;
- desarrolladores de cualquier aplicación que utilice AccessibilityService;
- equipos de seguridad y de análisis forense digital que investigan ataques móviles dirigidos.
Efecto positivo: para los dispositivos con Advanced Protection el riesgo de compromiso mediante ingeniería social e imposición de aplicaciones que utilizan Accessibility para el fraude se reduce drásticamente. Incluso si el usuario instala una aplicación maliciosa e intenta concederle acceso a Accessibility, el sistema en Android 17 no lo permitirá si la aplicación no figura entre las Accessibility Tools verificadas.
El reverso de la moneda: cualquier aplicación legítima que actualmente utilice AccessibilityService para tareas no estándar (automatización, funciones complementarias sobre otras aplicaciones, shells auxiliares, etc.), pero que no esté clasificada por Google como Accessibility Tool, cuando se active Advanced Protection en Android 17:
- perderá el acceso a AccessibilityService;
- podrá perder parcial o totalmente su funcionalidad;
- empezará a comportarse de forma distinta en dispositivos con y sin Advanced Protection, lo que complicará el soporte.
Para el entorno corporativo esto implica la necesidad de revisar los perfiles de uso de Android: los dispositivos de empleados con mayores requisitos de protección (por ejemplo, directivos o personal que trabaja con datos sensibles), al activar Advanced Protection, pueden encontrarse con fallos de funciones habituales de aplicaciones de terceros que, a primera vista, no son críticas pero sí molestas.
Conviene destacar por separado el impacto de Intrusion Logging y USB Protection. La primera herramienta aumenta las probabilidades de éxito en la investigación de ataques de espionaje complejos, pero exige una activación consciente y la definición de un proceso de trabajo con los registros. La segunda reduce el riesgo de ataques cuando hay acceso físico al dispositivo a través de USB, algo crítico para amenazas relacionadas con el robo de dispositivos o intentos de analizarlos en el lado del atacante.
Recomendaciones prácticas
Para organizaciones y equipos de seguridad
- Inventariar las aplicaciones que utilizan AccessibilityService en los dispositivos Android gestionados. Señalar por separado cuáles de ellas son críticas para los procesos de negocio.
- Realizar una prueba piloto de Android 17 con Advanced Protection activado en un grupo limitado de usuarios que tengan dichas aplicaciones. Registrar qué funciones dejan de funcionar.
- Segregar los perfiles de dispositivos: en cuáles Advanced Protection debe activarse obligatoriamente (dispositivos con mayor riesgo) y en cuáles es opcional debido a la dependencia de aplicaciones que usan Accessibility.
- En los procedimientos de respuesta a incidentes tener en cuenta la posibilidad de usar Intrusion Logging: definir quién y en qué casos lo activa en los ajustes de Advanced Protection, y cómo se extraen y analizan los registros.
- Activar USB Protection en todos los dispositivos donde sean aceptables las restricciones al conectarse por USB, y actualizar las instrucciones para el personal que necesite conexiones periódicas seguras a PC.
- Evaluar la necesidad de desactivar WebGPU en dispositivos utilizados para acceder a recursos web críticos, a fin de minimizar el riesgo de ataques complejos a través del navegador.
Para desarrolladores de aplicaciones Android
- Revisar la justificación del uso de AccessibilityService. Si su producto no es una herramienta de asistencia para personas con discapacidades, el uso de Accessibility puede provocar el bloqueo de funcionalidades para parte de los usuarios con Advanced Protection.
- Estudiar y cumplir la política de uso de AccessibilityService, expuesta en la guía de Google Play para desarrolladores, y, si es necesario, pasar la verificación como Accessibility Tool.
- Marcar los elementos sensibles de la interfaz con el flag accessibilityDataSensitive, tal como se describe en el material de Google sobre la protección de datos frente a su visualización a través de Accessibility, para reducir el riesgo de fuga de información confidencial a través de servicios maliciosos.
- Implementar bifurcación de la lógica para usuarios con Advanced Protection activado, utilizando el mecanismo de notificaciones sobre su activación (descripción en el blog de seguridad de Google) y, si es necesario, desactivar o sustituir las funciones que dependan de AccessibilityService.
- Construir un entorno de pruebas en Android 17 y añadir comprobaciones con Advanced Protection activado a las pruebas de regresión, especialmente si el producto trabaja con operaciones financieras o datos sensibles.
La conclusión clave es que Android 17 con Advanced Protection traslada la protección frente al uso indebido de AccessibilityService del ámbito de «convencer al usuario para que no pulse de más» al ámbito de la prohibición a nivel del sistema. Por tanto, ya ahora tiene sentido: 1) recopilar la lista de todas las aplicaciones que utilizan AccessibilityService en su entorno, 2) en un grupo de dispositivos de prueba con Android 17 activar Advanced Protection y registrar todas las interrupciones de funcionamiento, 3) según los resultados de las pruebas, sustituir las aplicaciones problemáticas o preparar con antelación excepciones y perfiles de dispositivos separados.