Ataque Pixnapping

• Pixnapping es una nueva técnica de ataque con la que una app maliciosa de Android puede robar en secreto información personal mostrada en otras apps o sitios web
• Este ataque usa un canal lateral entre la API de Android y el hardware GPU, y afecta a la mayoría de los dispositivos recientes de fabricantes importantes como Google y Samsung
• Puede exponer toda la información que aparece en pantalla, como códigos de autenticación, chats y correos electrónicos, y puede ejecutarse incluso sin permisos de app
• En Google Authenticator, es posible robar códigos de autenticación de dos factores en menos de 30 segundos
• Tanto Google como los fabricantes de GPU siguen sin contar con parches o medidas de mitigación sólidas para este ataque

---

Resumen

• Pixnapping es un ataque que permite que una app maliciosa de Android robe, sin que el usuario lo note, información mostrada en otras apps o sitios web
• La filtración de información se logra abusando de un canal lateral entre la API de Android y la GPU, y afecta a la mayoría de los smartphones Android recientes, incluidos dispositivos de Google y Samsung
• Entre las apps afectadas verificadas se incluyen Gmail, Signal, Google Authenticator, Venmo y Google Maps, y también es posible robar códigos 2FA de Google Authenticator en menos de 30 segundos

Artículo de investigación y demostración

• Está previsto que se presente en ACM CCS 2025 con el artículo “Pixnapping: Bringing Pixel Stealing out of the Stone Age”
• En la versión preliminar del artículo se pueden consultar el principio del ataque y sus detalles

Preguntas y respuestas principales

Qué dispositivos están afectados

• Se demostró en Google Pixel 6, 7, 8, 9 y Samsung Galaxy S25 con Android 13~16
• Es muy probable que el principio central del ataque funcione igual en dispositivos de otros fabricantes

Condiciones del ataque

• Cualquier app de Android sin permisos puede ejecutar el ataque
• Se activa incluso sin declarar permisos adicionales en el archivo manifiesto de la app

Qué información puede robarse

• Toda la información mostrada en pantalla, como chats, códigos de autenticación y correos electrónicos, puede ser objetivo del ataque
• La información interna que no aparece en pantalla no puede filtrarse

Casos reales de explotación

• Por ahora no está confirmado si ya se está explotando en el mundo real

Cómo pueden protegerse los usuarios

• Se recomienda instalar de inmediato cada nuevo parche de seguridad de Android cuando esté disponible

Cómo pueden protegerse los desarrolladores

• Por el momento no se han identificado defensas o mitigaciones efectivas
• Si se tienen ideas relevantes de seguridad, los investigadores piden que se les contacte

Cómo funciona el ataque

1. La app maliciosa invoca a la app objetivo (por ejemplo, Google Authenticator) para inducir que se renderice información sensible
2. En la pantalla de la app objetivo, fuerza la aplicación de una operación gráfica (como desenfoque) sobre un píxel específico
3. Usa un canal lateral como GPU.zip para extraer, píxel por píxel, la información del píxel del paso 2

• Al repetir los pasos 2 y 3, reconstruye todos los píxeles y luego extrae el contenido original mediante OCR
• El efecto es similar a tomar una captura de pantalla de una vista a la que la app maliciosa en realidad no debería poder acceder

APIs de Android explotadas

• Usa la window blur API para aplicar procesamiento gráfico (desenfoque) a zonas de píxeles sensibles
• Usa callbacks de VSync para medir el tiempo de renderizado y aprovecharlo en la extracción píxel por píxel

Parche y respuesta de Google

• Google respondió limitando la cantidad de actividades con procesamiento blur que una app puede invocar, pero pronto se encontró un workaround
• Ese workaround sigue actualmente bajo embargo y no se ha hecho público

Canal lateral a nivel de hardware

• Extrae la información de los píxeles mediante un canal lateral basado en GPU llamado GPU.zip
• Hasta octubre de 2025, los fabricantes de GPU no tienen planes de parches específicos

Identificación de la vulnerabilidad (CVE)

• Fue registrada oficialmente como CVE-2025-48561

Impacto en otros sistemas operativos

• Android es vulnerable porque permite que una app aplique operaciones gráficas sobre la pantalla de otra app y mida efectos secundarios
• No está confirmado si puede aplicarse a otros sistemas operativos

Vulnerabilidad adicional App List Bypass

• También existe una vulnerabilidad de app list bypass que permite identificar la lista de otras apps instaladas sin permisos adicionales ni declaraciones en el manifiesto
• Puede usarse para perfilar al usuario y, a diferencia de métodos previos, funciona sin declaraciones adicionales
• Google la clasificó como “Infeasible” y cerró el caso sin medidas adicionales

Logo, código fuente y licencia

• El logo de Pixnapping puede usarse libremente bajo licencia CC0
• Después de la distribución de los parches, el código fuente se publicará en GitHub(https://github.com/TAC-UCB/pixnapping)

Respuesta y cronograma principal

• Entre febrero y octubre de 2025 se llevó a cabo una divulgación escalonada de la vulnerabilidad a Google y Samsung, junto con solicitudes de respuesta
• Google clasificó el riesgo de Pixnapping y app list bypass como High/Low, y concluyó que algunos parches eran insuficientes o inviables (sin posibilidad de corrección)
• Se prevén parches adicionales en el boletín de seguridad de Android de diciembre de 2025

Resumen

• Pixnapping es un ataque que puede filtrar de forma indebida información importante de la pantalla real aprovechando una combinación de fallas en la estructura de permisos de las apps y en el funcionamiento del hardware
• Tanto el software como el hardware de seguridad de Android requieren mejoras estructurales

[GN⁺]

Opinión de Hacker News

• Me parece que el problema central es que el sistema de permisos de Android permite por defecto cosas como "ejecutarse en segundo plano" o "acceso a internet" sin aprobación del usuario; este tipo de ataque es posible porque todas las apps —incluso un juego offline— tienen esos permisos por defecto. Muchas apps deberían tener acceso a internet solo "mientras se usa la app" y, aunque eso no sería una protección perfecta, sí podría reducir mucho el impacto del ataque porque siempre existe el riesgo de ejecutar una app maliciosa por accidente.

  • Me pregunto si existe algún estudio serio sobre el riesgo de las actualizaciones automáticas frente a las manuales o no realizadas, especialmente en entornos medio aislados como Android; en particular, quisiera saber si hay investigaciones que comparen tasas de fallos.

  • En realidad sí existe el permiso de acceso a internet, y en GrapheneOS se puede negar por completo el acceso a internet a las apps que lo declaran.

  • Hay una respuesta convincente de por qué Android no pide al usuario permiso para el acceso a internet; es una respuesta directa del equipo de desarrollo de Android fuente. En cuanto a "ejecutarse en segundo plano", como Android está basado en "intents", una app puede despertarse en cualquier momento, así que una simple opción de "prohibir ejecución en segundo plano" podría no funcionar como el usuario espera.

• Vi el video y aun así me cuesta entender cómo funciona este ataque; me pregunto si después de cambiar de app todavía es posible acceder a los píxeles de la app de autenticación.

• Sobre la pregunta de cómo debería proteger a los usuarios un desarrollador de apps, dicen que no hay mitigaciones publicadas, pero yo creo que hay algunos intentos básicos que podrían hacerse; por ejemplo, no fijar la posición del código en la pantalla, ocultarlo cuando la app queda en segundo plano, mover el código continuamente, cambiar colores y contraste, mostrar ruido estático, o hacer que solo parpadeen brevemente partes del código en vez del código completo. Claro, eso afectaría algo la UX, pero en teoría podría elevar bastante la dificultad para el atacante. También menciono que habría límites si información secreta ya quedó en caché mediante screenshots.

  • Recuerdo que Google Authenticator alguna vez cambió para que hubiera que tocar el código TOTP para mostrarlo. En ese momento pensé que no detenía una amenaza real y que solo era incómodo; mucha gente estuvo de acuerdo y poco después esa función fue revertida discretamente. Me pregunto si habrá sido una mitigación preventiva para este fallo.

  • Comparten una demo en unscreenshottable.vercel.app.

• Enfatizan que, para que este ataque sea realmente viable contra TOTP, el tipo de letra y la posición de los píxeles tendrían que conocerse perfectamente. Según el paper, robar regiones sensibles de la pantalla toma bastante tiempo y, por ejemplo, los códigos 2FA normalmente se actualizan cada 30 segundos, así que hay una restricción de tiempo muy estricta. Si el atacante no logra extraer los 6 dígitos dentro de esos 30 segundos, el valor desaparece. Aun así, si el tipo de letra ya es conocido por el atacante, podría distinguirse con solo extraer algunos píxeles.

  • Como solo hay unas cuantas apps de autenticación ampliamente usadas (Google, Microsoft Authenticator, Okta, etc.), no creo que eso sea un gran obstáculo en la práctica.

• Aclaran que es una técnica que existe desde hace tiempo, pero que es muy efectiva para apuntar a objetivos precisos. Si puedes instalar una app específica en el teléfono de un usuario, ni siquiera hace falta complicarse tanto: la app misma puede acceder directamente a la información que quieras. Por ejemplo, si una app como Facebook mostrara un aviso de privacidad diciendo "esta app captura la pantalla periódicamente", sorprendentemente mucha gente igual lo permitiría. Dijeron que publicarían el código fuente de Pixnapping en este repositorio cuando ya fuera posible aplicar parches, pero en realidad tampoco parece que la ingeniería inversa fuera tan difícil. Podrían haber esperado a que se parcheara, pero da la impresión de que los investigadores querían llamar la atención más rápido.

  • En realidad, el parche original para la vulnerabilidad ya es público; incluso el mensaje del commit relacionado dice explícitamente que busca "evitar el robo de píxeles midiendo el tiempo de blur entre ventanas". La razón por la que los investigadores no publican el código es que descubrieron una forma de eludir ese parche. Además mencionan que "ningún vendor de GPU se ha comprometido a parchear GPU.zip" y que "Google tampoco tiene intención de corregir la vulnerabilidad de bypass de la lista de apps" ("cerrado como no se arreglará"). Considerando que la fecha del primer reporte fue el 24 de febrero de 2025, no parece justo decir que los investigadores fueron apresurados. Y aunque existiera una alerta de "esta app captura la pantalla periódicamente", una pantalla marcada explícitamente como no capturable no puede capturarse sin un exploit aparte.

  • La fecha del primer reporte a Google fue el 24 de febrero de 2025; sí se les dio tiempo suficiente.

• Reconocen que este ataque es una técnica inteligente que aprovecha el tiempo de renderizado como canal lateral. Incluso en Google Authenticator, recolectar todos los píxeles tomaría bastante tiempo. Más bien me preocupa cuánto podría aplicarse algo así al robo de OTP por mensajes de texto. También hay cada vez más correos de phishing con patrones fijos, como los emails de notificación de GitHub, así que ya dejé de hacer clic en enlaces dentro del correo; ahora también pienso que conviene evitar abrir apps mediante sugerencias de intent. Es mejor abrir la app directamente para hacer lo necesario y eliminar apps inútiles. La superficie de ataque también puede ampliarse mediante SDKs o intents desde páginas web, y siento que eso se pasa por alto con frecuencia.

• Por el título pensé que era un juego de navegador y lo busqué por eso.

• No soy experto en seguridad, pero creo que si instalas una app en un escritorio Windows, el ataque puede hacerse mucho más rápido y de forma más sigilosa que con pixnapping en Android. Si reutilizas la misma contraseña en varios sitios web, uno de ellos podría robarla e iniciar sesión en otro lugar con ella, siempre que no haya otra capa de seguridad. En teoría la seguridad es débil, aunque en la práctica este tipo de ataque no suele ser tan común ni tan fácil de ejecutar.

  • En escritorio no hay sandboxing, mientras que en móvil sí, así que escapar del sandbox equivale a una violación de seguridad. Además, en escritorio no instalas una app distinta para cada cadena de comida rápida, pero en móvil sí se tiende a instalar apps sin mucho criterio.

• Comparten un enlace a la discusión anterior.

  • En la discusión anterior, muchos decían que no había de qué preocuparse porque ya había parche, pero en este caso dicen que ese parche no funciona por completo.

• Piensan que los dispositivos modernos se han vuelto tan complejos que la seguridad total es imposible. Parece que estas cosas pasan porque se siguen agregando funciones innecesarias sin fin. Creen que en el futuro aumentará la demanda de sistemas operativos centrados en seguridad y con funciones mínimas, como FreeBSD.

  • Quieren un entorno donde se pueda hacer make world desde la terminal incluso estando en movimiento.

  • Existe Precursor, creado por Bunnie; les parece genial, pero demasiado caro. Si ya te parece caro un calculador de $100, Precursor tiene una forma parecida y una potencia de cómputo similar, pero cuesta $1000 y ni siquiera se puede usar en un examen de matemáticas. Blog oficial de Precursor (ahora no carga, aunque quizá vuelva más tarde).

  • Después de leer comentarios de HN durante varios años, siento que el conocimiento y la práctica de seguridad han retrocedido mucho, y que la expansión de la IA generativa va a empeorar aún más la situación. Hoy en día también hay mucha gente que, mientras habla de proyectos de teléfonos de la FSF, se queja de lo incómodo que es usar apps de banca móvil. También dicen que es una molestia tener que escribir la contraseña cada 30 minutos en el escritorio, o se quejan de que "¿ahora tengo que cargar dos teléfonos?". Desde mi punto de vista, si alguien roba tu teléfono después de verte introducir la contraseña, lo primero que hará será abrir la app bancaria, la app de dinero y todo lo que pueda para sacar la mayor cantidad de datos posible. Ese tipo de crimen ocurre todos los días. Lo mejor es no instalar esas apps en el teléfono, o al menos no dejarlas con sesión iniciada; lo mismo aplica para las apps de 2FA. Es como andar mostrando una maleta de viaje de marca cara: te convierte en objetivo. A menos que seas un CEO o alguien bajo ataque a nivel estatal, deberías ser aún más cuidadoso. Incluso un dispositivo con un "SO de seguridad de funciones mínimas" seguiría teniendo el problema esencial de la pérdida física del dispositivo, como cuando alguien ve tu contraseña y luego te roba el aparato; pero sí creo que se debe separar estrictamente un teléfono para juegos y apps con publicidad, usado en bares y similares, de otro teléfono dedicado a banca, 2FA y trabajo.