Google está probando una nueva función de seguridad como parte del Modo de protección avanzada de Android (AAPM) que evita que ciertos tipos de aplicaciones utilicen la API de servicios de accesibilidad.

El cambio, incorporado en Android 17 Beta 2, fue reportado por primera vez por Android Authority la semana pasada.

AAPM fue introducido por Google en Android 16, lanzado el año pasado. Cuando activadohace que el dispositivo entre en un estado de mayor seguridad para protegerse contra ataques cibernéticos sofisticados. Al igual que el modo de bloqueo de Apple, la función de inclusión prioriza la seguridad a costa de una funcionalidad y usabilidad disminuidas para minimizar la superficie de ataque.

Algunos de los configuraciones centrales incluyen bloquear la instalación de aplicaciones de fuentes desconocidas, restringir la señalización de datos USB y exigir el escaneo de Google Play Protect.

«Los desarrolladores pueden integrar esta función utilizando el Administrador de protección avanzada API para detectar el estado del modo, lo que permite que las aplicaciones adopten automáticamente una postura de seguridad reforzada o restrinjan la funcionalidad de alto riesgo cuando un usuario ha optado por participar», Google anotado en su documentación que describe las características de Android 17.

La última restricción agregada a la configuración de seguridad de un toque tiene como objetivo evitar que las aplicaciones que no están clasificadas como herramientas de accesibilidad puedan aprovechar las funciones del sistema operativo. API de servicios de accesibilidad. Herramientas de accesibilidad verificadas, identificadas por el isAccessibilityTool=»true» indicadorestán exentos de esta regla.

Según Google, sólo los lectores de pantalla, los sistemas de entrada basados ​​en interruptores, las herramientas de entrada basadas en voz y los programas de acceso basados ​​en Braille están designados como herramientas de accesibilidad. El software antivirus, las herramientas de automatización, los asistentes, las aplicaciones de monitoreo, los limpiadores, los administradores de contraseñas y los lanzadores no entran en esta categoría.

Si bien AccessibilityService tiene sus casos de uso legítimos, como ayudar a usuarios con discapacidades a usar dispositivos y aplicaciones Android, en los últimos años los malos actores han abusado ampliamente de la API para robar datos confidenciales de dispositivos Android comprometidos.

Con el último cambio, a cualquier aplicación que no sea de accesibilidad y que ya tenga el permiso se le revocarán automáticamente sus privilegios cuando AAPM esté activo. Los usuarios tampoco podrán otorgar permisos a las aplicaciones para la API a menos que la configuración esté desactivada.

Android 17 también viene con un nuevo selector de contactos que permite a los desarrolladores de aplicaciones especificar solo los campos a los que desean acceder desde la lista de contactos de un usuario (por ejemplo, números de teléfono o direcciones de correo electrónico) o permitir a los usuarios seleccionar ciertos contactos con una aplicación de terceros.

«Esto le otorga a su aplicación acceso de lectura solo a los datos seleccionados, lo que garantiza un control granular y al mismo tiempo proporciona una experiencia de usuario consistente con capacidades integradas de búsqueda, cambio de perfil y selección múltiple sin tener que crear o mantener la interfaz de usuario», dijo Google.

Una nueva investigación ha descubierto que se podría abusar de las claves API de Google Cloud, generalmente designadas como identificadores de proyecto con fines de facturación, para autenticarse en puntos finales sensibles de Gemini y acceder a datos privados.

Los hallazgos provienen de Truffle Security, que descubrió casi 3.000 claves API de Google (identificadas por el prefijo «AIza») incrustadas en el código del lado del cliente para proporcionar servicios relacionados con Google, como mapas incrustados en sitios web.

«Con una clave válida, un atacante puede acceder a los archivos cargados, a los datos almacenados en caché y cargar el uso de LLM a su cuenta», dijo el investigador de seguridad Joe Leon. dichoañadiendo las claves «ahora también se autentican en Gemini aunque nunca fueron destinadas a ello».

El problema ocurre cuando los usuarios habilitan la API de Gemini en un proyecto de Google Cloud (es decir, API de lenguaje generativo), lo que hace que las claves de API existentes en ese proyecto, incluidas aquellas a las que se puede acceder a través del código JavaScript del sitio web, obtengan acceso subrepticio a los puntos finales de Gemini sin ninguna advertencia o aviso.

Esto permite efectivamente que cualquier atacante que raspe sitios web obtenga dichas claves API y las utilice con fines nefastos y robo de cuotas, incluido el acceso a archivos confidenciales a través de los puntos finales /files y /cachedContents, así como realizar llamadas a la API Gemini, acumulando enormes facturas para las víctimas.

Además, Truffle Security descubrió que la creación de una nueva clave API en Google Cloud tiene como valor predeterminado «Sin restricciones», lo que significa que es aplicable para todas las API habilitadas en el proyecto, incluido Gemini.

«El resultado: miles de claves API que se implementaron como tokens de facturación benignos ahora son credenciales de Gemini activas en la Internet pública», dijo Leon. En total, la compañía dijo que encontró 2.863 claves activas accesibles en la Internet pública, incluido un sitio web asociado con Google.

La divulgación se produce cuando Quokka publicó un informe similar, en el que encontró más de 35.000 claves API únicas de Google integradas en su análisis de 250.000 aplicaciones de Android.

«Más allá del posible abuso de costos a través de solicitudes automatizadas de LLM, las organizaciones también deben considerar cómo los puntos finales habilitados para IA podrían interactuar con mensajes, contenido generado o servicios en la nube conectados de manera que amplíen el radio de explosión de una clave comprometida», dijo la empresa de seguridad móvil. dicho.

«Incluso si no se puede acceder a datos directos del cliente, la combinación de acceso a inferencia, consumo de cuotas y posible integración con recursos más amplios de Google Cloud crea un perfil de riesgo que es materialmente diferente del modelo de identificador de facturación original en el que confiaron los desarrolladores».

Aunque inicialmente se consideró que el comportamiento era intencionado, desde entonces Google intervino para solucionar el problema.

«Somos conscientes de este informe y hemos trabajado con los investigadores para abordar el problema», dijo un portavoz de Google a The Hacker News por correo electrónico. «Proteger los datos y la infraestructura de nuestros usuarios es nuestra principal prioridad. Ya hemos implementado medidas proactivas para detectar y bloquear claves API filtradas que intentan acceder a la API de Gemini».

Actualmente no se sabe si este problema alguna vez fue explotado en la naturaleza. Sin embargo, en un publicación en Reddit publicado hace dos días, un usuario afirmó que una clave API de Google Cloud «robada» resultó en cargos de $82,314.44 entre el 11 y el 12 de febrero de 2026, frente a un gasto regular de $180 por mes.

Nos comunicamos con Google para obtener más comentarios y actualizaremos la historia si recibimos una respuesta.

Se recomienda a los usuarios que hayan configurado proyectos de Google Cloud que verifiquen sus API y servicios, y verifiquen si las API relacionadas con la inteligencia artificial (IA) están habilitadas. Si están habilitadas y son de acceso público (ya sea en JavaScript del lado del cliente o registradas en un repositorio público), asegúrese de que las claves estén rotadas.

«Empiece primero con las claves más antiguas», dijo Truffle Security. «Es más probable que se hayan implementado públicamente bajo la antigua guía de que las claves API se pueden compartir de forma segura y luego obtuvieron privilegios de Gemini de manera retroactiva cuando alguien de su equipo habilitó la API».

«Este es un gran ejemplo de cómo el riesgo es dinámico y cómo las API pueden tener permisos excesivos después del hecho», dijo Tim Erlin, estratega de seguridad de Wallarm, en un comunicado. «Las pruebas de seguridad, el escaneo de vulnerabilidades y otras evaluaciones deben ser continuas».

«Las API son complicadas en particular porque los cambios en sus operaciones o los datos a los que pueden acceder no son necesariamente vulnerabilidades, pero pueden aumentar directamente el riesgo. La adopción de IA que se ejecuta en estas API y su uso solo acelera el problema. Encontrar vulnerabilidades no es suficiente para las API. Las organizaciones tienen que perfilar el comportamiento y el acceso a los datos, identificar anomalías y bloquear activamente la actividad maliciosa».

Investigadores de ciberseguridad han revelado detalles de un nuevo paquete malicioso descubierto en la Galería NuGet, que se hace pasar por una biblioteca de la empresa de servicios financieros Stripe en un intento de apuntar al sector financiero.

El paquete, cuyo nombre en código es StripeApi.Net, intenta hacerse pasar por raya.netuna biblioteca legítima de Stripe que cuenta con más de 75 millones de descargas. Fue subido por un usuario llamado StripePayments el 16 de febrero de 2026. El paquete ya no está disponible.

«La página NuGet para el paquete malicioso está configurada para parecerse lo más posible al paquete oficial Stripe.net», ReversingLabs Petar Kirhmajer dicho. «Utiliza el mismo ícono que el paquete legítimo y contiene un archivo Léame casi idéntico, solo intercambia las referencias a ‘Stripe.net’ para que diga ‘Stripe-net’».

En un esfuerzo adicional por dar credibilidad al paquete con errores tipográficos, se dice que el actor de amenazas detrás de la campaña infló artificialmente el recuento de descargas a más de 180.000. Pero en un giro interesante, las descargas se dividieron en 506 versiones, y cada versión registró unas 300 descargas en promedio.

El paquete replica algunas de las funciones del paquete Stripe legítimo, pero también modifica ciertos métodos críticos para recopilar y transferir datos confidenciales, incluido el token API de Stripe del usuario, al actor de la amenaza. Dado que el resto de las bases de código siguen siendo completamente funcionales, es poco probable que atraiga sospechas de desarrolladores desprevenidos que puedan haberlo descargado sin darse cuenta.

ReversingLabs dijo que descubrió e informó sobre el paquete «relativamente pronto» después de su lanzamiento inicial, lo que provocó que lo tomaran antes de que pudiera causar daños graves.

La empresa de seguridad de la cadena de suministro de software también señaló que la actividad marca un cambio con respecto a campañas anteriores que aprovecharon paquetes NuGet falsos para apuntar al ecosistema de criptomonedas y facilitar el robo de claves de billetera.

«Los desarrolladores que por error descarguen e integren una biblioteca con errores tipográficos como StripeAPI.net aún tendrán sus aplicaciones compiladas exitosamente y funcionarán según lo previsto», dijo Kirhmajer. «Los pagos se procesarían normalmente y, desde la perspectiva del desarrollador, nada parecería roto. Sin embargo, en el fondo, actores maliciosos copian y filtran en secreto datos confidenciales».