BookinglyTech News
Ciberseguridad

Los avisos de cambios de ficheros filtran lo que hace el usuario en cuatro sistemas

Un trabajo aceptado en el ACM CCS demuestra que inotify, FileObserver, ReadDirectoryChangesW y File System Events revelan actividad ajena solo con permiso de lectura.

3 min de lecturaLobsters0 vistas

Los mecanismos que avisan a las aplicaciones de que un fichero ha cambiado filtran más de lo que deberían. Un trabajo aceptado en el ACM CCS de 2026, que se celebra en La Haya del 15 al 19 de noviembre, demuestra que inotify en Linux, FileObserver en Android, ReadDirectoryChangesW en Windows y File System Events en macOS permiten reconstruir actividad de usuario, de sistema y de aplicaciones con nada más que permiso de lectura.

La clave está en que el atacante nunca ve el contenido. Solo recibe notificaciones: se abrió, se escribió, se cerró, se borró. Los autores sostienen que ese flujo de metadatos basta para deducir cosas que no deberían salir de la máquina, y en algunos casos para descubrir la existencia de ficheros que tradicionalmente no se podían ni conocer.

Tres agujeros propios de cada plataforma

En Linux, montar un watch sobre un directorio legible reporta todos los eventos de los ficheros que contiene, incluso de aquellos que el proceso no puede leer directamente. Con /dev/input eso significa que un usuario sin acceso a /dev/input/event4 sigue viendo cada pulsación de tecla, porque el directorio sí es listable. Lo mismo ocurre entre usuarios conectados por SSH: cualquiera puede vigilar /dev/pts y saber cuándo teclea el otro. No se filtra qué tecla, solo cuándo, pero sobre eso hay dos décadas de literatura de ataques por tiempos entre pulsaciones: Song en 2001, Zhang y Wang en 2009, Monaco en 2018 y Qiu en 2025.

A eso se suma un ataque de redirección de interfaz en KDE Plasma sobre Wayland. Un proceso del mismo usuario puede vigilar /usr/bin/pkexec para detectar cuándo va a aparecer el diálogo de autenticación de polkit y dibujar encima una ventana falsa que capture la contraseña. El equipo de seguridad de KDE responde que la prevención de robo de foco no está diseñada como mecanismo de seguridad. SteamOS, que usa Plasma 6, entra en el mismo escenario.

En Android, FileObserver se salta la vista por aplicación que impone la capa FUSE: una app sin privilegios puede vigilar la carpeta privada de otra. Los autores lo demuestran contra WhatsApp, viendo cuándo llegan o se borran fotos, vídeos y ficheros.

En Windows el caso es más grueso. Vigilar el directorio raíz C:\ reporta la ruta completa de cualquier fichero tocado en el sistema, sin importar permisos ni usuarios. Microsoft lo describe como una característica no documentada. El caso más grave que enseñan es la filtración en tiempo real de qué webs visita otro usuario, y el hallazgo le valió a la compañía una nominación a la peor respuesta de proveedor en los Pwnies de 2026.

Nada de esto es nuevo. inotify está en el kernel desde la 2.6.13 (2005), FileObserver existe desde 2008, ReadDirectoryChangesW desde Windows 2000 y File System Events desde Mac OS X 10.5 Leopard (2007). Esa antigüedad es parte del problema: son APIs que llevan dos décadas integradas en aplicaciones de todo tipo y cuyo modelo de permisos nadie revisó pensando en este vector.

El material del trabajo, con las demos por plataforma, está en el repositorio del proyecto. Falta por ver si Microsoft mueve ficha o si todo queda en el limbo de las características no documentadas; KDE ya ha dicho que no lo trata como un fallo. Para quien administra flotas, la lectura práctica es que el aislamiento entre usuarios y entre aplicaciones no puede darse por supuesto mientras existan estos watches.