isec-tugraz/file-notification-attacksArtefactos de investigación para ataques de canal lateral de notificación de archivos en Linux, Windows y macOS, que demuestran la fuga de inotify/FSEvents, la sincronización de pulsaciones de teclas y la huella digital de sitios web.
Este repositorio contiene los artefactos (¡todavía en revisión!) para el artículo "File Notification Attacks: Templating and Exploiting Side-Channel Leakage from the File-Notification Systems on Linux, Windows, and macOS", aceptado en CCS '26.
Visita el sitio web con demos en: https://inoti.fyi/
Lee el artículo en: https://snee.la/pdf/pubs/file-notification-attacks.pdf o http://inoti.fyi/pubs/file-notification-attacks.pdf
Como parte de la evaluación de artefactos en CCS'26 (¡todavía en curso!), enviamos una VM Debian 13 + KDE Plasma 6 con un kernel pre-parcheado. Esta VM no se utilizó para producir los resultados de evaluación del artículo y no pretende reproducir su magnitud exacta. Este repositorio puede actualizarse para incorporar revisiones y comentarios de nuestros evaluadores de artefactos. Haremos la VM públicamente accesible cuando se complete nuestra evaluación de artefactos.
Empleamos Claude (Opus 4.8) para envolver nuestro código en artefactos decentemente bien documentados y de alto rendimiento (por ejemplo, el de Windows era un poco lento). Sin embargo, el código, scripts, makefiles que generó se basaron en
Las instrucciones para probar el código de Linux a continuación son específicas para ejecutar comandos en
la VM. Por favor, mira el código en su lugar en Linux/.
La VM existe puramente por conveniencia, para que montar cada ataque no requiera una configuración de entorno desde cero o una degradación del kernel. El mecanismo subyacente demostrado en la VM es idéntico al descrito en el artículo, pero ten en cuenta que no utilizamos la VM para producir los números reportados en el artículo. Los tiempos absolutos pueden diferir debido al entorno virtualizado y al hardware subyacente.
Los hallazgos se reproducen dentro de una VM Debian 13 (linux-vm/), instalada desde la
ISO oficial live de Debian con KDE Plasma 6 (Wayland) instalado con un kernel
que es anterior a la corrección de
fsnotify.
inotify-tools, los encabezados de desarrollo de Qt6 y pkexec están instalados. Nada más
se actualiza, y el kernel nunca se toca después de la instalación. Por favor, NO ejecutes
apt upgrade ni intentes actualizar el kernel. Esta imagen de VM es
deliberadamente antigua, no está actualizada y no tiene los últimos parches de seguridad.
¡Esta imagen de VM solo está destinada a validación y pruebas rápidas!
El código, los ataques y las demostraciones ubicadas dentro de la VM están replicados en
Linux/.
Nota: Mencionamos como qué usuario ejecutar los comandos en la parte superior de cada
bloque de comandos. Está [host], que es la máquina anfitriona que ejecuta la
VM, [user] que es la víctima de los ataques en la VM, y [spyuser] que
requiere ser configurado y será el atacante en la mayoría de los ataques de Linux.
La imagen de disco se envía como linux-vm-upload.qcow2, comprimida con zstd.
Renómbrala a linux-vm.qcow2 antes de ejecutar run.sh (que espera ese
nombre de archivo):
# Run As: [host]
cd linux-vm/
mv linux-vm-upload.qcow2 linux-vm.qcow2
./run.sh
Leer un qcow2 comprimido con zstd requiere qemu-img/qemu-system-x86_64 versión
5.2 o superior (2020+), verifica con qemu-img --version. Si estás atascado en un
QEMU más antiguo y falla al abrir la imagen, descomprímela en un qcow2 plano
primero:
qemu-img convert -O qcow2 linux-vm-upload.qcow2 linux-vm.qcow2
4 núcleos, 4GB de RAM, pantalla GUI. Los inicios de sesión son:
root, contraseña password,user, contraseña password,spyuser, contraseña password (¡no inicies sesión como spyuser!)La VM proporcionada ya ejecuta un kernel vulnerable, pre-parcheado
(6.12.43+deb13-amd64), por lo que no se necesita degradación para usarla. Necesitarás QEMU
para ejecutar esta imagen (que tiene una GUI). El artefacto se encuentra en
/home/user/Linux-File-Notification-Attacks dentro de la VM.
Un comando configura todo desde cero en la VM: (i) una cuenta spyuser sin privilegios
(no-sudo), (ii) su propia copia del directorio de artefactos (una cuenta sin privilegios separada
no puede acceder al directorio home de user de otra manera),
(iii) y cada script hecho ejecutable en ambas copias.
# In the VM, Run As: [user]
sudo bash ~/Linux-File-Notification-Attacks/setup_attacks.sh
Cada ataque a continuación se ejecuta como spyuser (su - spyuser, contraseña password),
excepto auth-ui-redress, que se ejecuta como user (explicado a continuación).
Demuestra que las notificaciones de operaciones de archivos se entregan en archivos que no pueden leerse directamente, siempre que su directorio padre sea legible.
# Run As: [spyuser]
# To switch to spyuser, in a new terminal type `su - spyuser`. The password
# is `password`.
cd ~/Linux-File-Notification-Attacks/unreadable-file-bypass
./watch-syslog.sh
Déjalo ejecutándose, luego genera una línea de registro desde otra terminal como user:
# Run As: [user]
logger "hello"
Esta imagen de Debian 13 no tiene rsyslog, por lo que no hay un archivo /var/log/syslog como
se muestra en el artículo. El script recurre a vigilar
/var/log/journal/<machine-id>/ en su lugar. Esta es la misma idea, ya que los
archivos .journal que se monitorean son propiedad de root (usuario) y
systemd-journal (grupo), ninguno de los cuales es spyuser.
Mide el retraso de notificación de inotify.
# Run As: [user], ensure numpy is installed (or pip3)
sudo apt install python3-numpy
# Run As: [spyuser]
cd ~/Linux-File-Notification-Attacks/temporal-resolution
./run.sh
watcher abre una vigilancia de inotify en un archivo de prueba y marca con tiempo cada IN_ACCESS
que recibe. accessor lee ese mismo archivo 1000 veces con un retraso aleatorio de 5-10ms entre lecturas, marcando con tiempo cada lectura él mismo. stats.py compara las dos
grabaciones de marcas de tiempo e imprime el retraso promedio/desviación estándar/mínimo entre la lectura
que ocurre y la notificación que llega, es decir, la resolución temporal de
inotify.
No es el ataque completo del artículo, sino solo la primitiva de prueba de concepto de filtrado
sobre la que se construye el ataque: por cada tecla presionada en cualquier lugar del
sistema, imprime una notificación con marca de tiempo, sin leer nunca /dev/input
directamente.
# Run As: [spyuser]
cd ~/Linux-File-Notification-Attacks/inter-keystroke-timing
make
./find-keyboard.sh
Escribe en cualquier ventana (quizás una nueva terminal como user). Cada pulsación imprime una
línea KEYPRESS. La ventana de supresión (que elegimos heurísticamente para esta
demostración es de 130ms) fusiona varios eventos IN_ACCESS generados por una sola
pulsación física de tecla. En la práctica, hemos notado que esta ventana es diferente
para diferentes hardware (por ejemplo, teclados mecánicos, estilos de escritura).
Si la autodetección elige el dispositivo incorrecto (o ninguno), verifica
/proc/bus/input/devices y ejecútalo directamente con ./build/keystroke-notify /dev/input event4.
Demostramos poder detectar cuándo
(pkexec)[https://polkit.pages.freedesktop.org/polkit/] se ejecuta, y
además dibujar una ventana falsa encima de él. Como mostramos en la Sección 4.4.3, este
'ataque de redirección de UI de autenticación' es posible en KDE Plasma 5 y 6 con
Wayland. Ejecutamos este ataque en el modelo de amenaza de atacante del mismo usuario: el socket de Wayland está limitado a la sesión iniciada, y una cuenta sin privilegios separada
no puede dibujar en él.
En una instalación estándar de KDE, pkexec es incluido por el escritorio, pero esta ISO live
es una imagen más ligera y, por lo tanto, no lo tiene instalado. Por lo tanto, lo instalamos
manualmente mientras (intentábamos) mantener la imagen de la VM pequeña.
# Run As: [user]
cd ~/Linux-File-Notification-Attacks/auth-ui-redress
make
./inotify-watcher-with-gui
Déjalo ejecutándose en una terminal. Desde otra terminal (el directorio no
importa), activa un aviso real de pkexec, por ejemplo, pkexec ls. El vigilante ve
el acceso a /usr/bin/pkexec y dibuja un diálogo falso de "Authentication Required"
(window-launcher) en la pantalla encima del real. Escribir en el
diálogo falso y pulsar Authenticate imprime el texto introducido en la terminal del vigilante, luego lo cierra. Ten en cuenta que la ventana falsa es deliberadamente
diferente de la ventana real para facilitar la comparación.
Vigilar los directorios de fuentes mientras se carga una página revela qué archivos de fuentes tocó. Diferentes sitios utilizan diferentes fuentes, por lo que el conjunto de rutas impresas mientras se carga una página ya es una huella digital, sin necesidad de tiempo ni clasificador para esta versión mínima.
Primero, como usuario, abre Firefox (haz clic en él mediante el icono en el dock del gestor de tareas en
la parte inferior de la pantalla), y asegúrate de que no haya sitios web abiertos. Luego, en una
terminal como spyuser:
# Run As: [spyuser]
cd ~/Linux-File-Notification-Attacks/website-fingerprinting-fonts
./compare-fonts.sh
Esto compila font-spy que comienza a monitorear los directorios de fuentes utilizados por
Firefox. El script compare-fonts te pide que visites dos sitios web.
Primero, visita un sitio web (quizás wikipedia.com) y espera unos segundos para que se cargue, abre una nueva pestaña, cierra la pestaña antigua (con el sitio web), y luego pulsa ENTER en la terminal.
Segundo, haz lo mismo con otro sitio web (quizás reddit.com): visita el sitio web y espera unos segundos para que se cargue, abre una nueva pestaña, cierra la pestaña antigua, y luego pulsa ENTER en la terminal.
El script debería imprimir la diferencia en las fuentes accedidas por sitio web. Ten en cuenta que en el artículo, también utilizamos la información temporal, es decir, cuándo se accedió a la fuente. Para una prueba de concepto simple, ignoramos esta información y simplemente imprimimos la diferencia entre los dos conjuntos de accesos a fuentes. Aunque el conjunto exacto de accesos a fuentes puede diferir entre ejecuciones, hay ciertos archivos de fuentes que siempre son accedidos de forma única por un sitio web.
Ten en cuenta que los sitios web pueden cambiar con el tiempo y, por lo tanto, los accesos a los archivos de fuentes pueden
diferir. En el momento de redactar este artefacto, notamos que Wikipedia siempre
accede a /usr/share/fonts/truetype/liberation/LiberationSans-Bold.ttf y
Reddit siempre accede a
/usr/share/fonts/truetype/vlgothic/VL-Gothic-Regular.ttf.
Un dispositivo físico o emulador ejecutando una versión de Android cuyo modelo de Almacenamiento con Ámbito
todavía permita registrar un FileObserver (el envoltorio a nivel de Java alrededor de
inotify) en los directorios de medios compartidos de WhatsApp, y un segundo dispositivo/cuenta
para actuar como remitente del mensaje. Ya sea compila el código fuente proporcionado
(Android/source/) o instala el APK suministrado directamente
(Android/app-release.apk).
Android expone la misma primitiva inotify utilizada en todos los hallazgos de Linux
a través de android.os.FileObserver. La Sección 5.4.3 muestra que una
app sin privilegios y sin permisos puede registrar tal observador en los directorios de medios de
WhatsApp y, puramente a partir del flujo resultante de
eventos de apertura/cierre/acceso, inferir que se recibió un medio privado, sin
poseer ningún permiso que le permitiera leer el contenido en sí.
Lanza la app y activa la acción de actualización; el servicio observador se conecta
y comienza a emitir entradas periódicas de actividad. Desplázate hasta el final de la
vista de registro y continúa actualizando hasta que aparezcan entradas repetidas de ObserverService: Still Running, confirmando que la vigilancia está activa y estable.
Desde una segunda cuenta, envía una imagen o documento a la
conversación observada y, si aún no está en caché, descárgalo en el dispositivo
observado. Esto produce una ráfaga de líneas de registro de eventos de archivos; inmediatamente después
de la última entrada ObserverService: Still Running antes de la ráfaga, el registro
debería mostrar eventos de apertura/cierre/acceso cuyas rutas corresponden al archivo
recibido, demostrando que su llegada es observable puramente a partir de los metadatos de notificación del sistema de archivos.
Proporcionamos el código fuente que puede compilarse con msys2. De lo contrario, el archivo exe (Windows/firefox-fingerprint/monitor.exe) también puede usarse.
Una máquina Windows (o VM) con MSYS2 instalado, y
la cadena de herramientas g++ de MinGW-w64 (pacman -S mingw-w64-ucrt-x86_64-gcc, ejecutado desde
un shell de MSYS2). Firefox instalado.
Esta prueba de concepto utiliza
ReadDirectoryChangesW
para vigilar recursivamente todo C:\, y solo imprime eventos cuya ruta contiene
http (directorios de almacenamiento por origen que Firefox nombra según el esquema/host del sitio, por ejemplo, bajo sus carpetas cache/IndexedDB). No se
requieren derechos de administrador para vigilar un directorio que puedes listar. Este almacenamiento por origen se escribe
en cada carga de página, por lo que vigilar desde fuera del proceso del navegador todavía
revela qué sitio se acaba de visitar.
Ya sea usa el exe que proporcionamos (Windows/firefox-fingerprint/monitor.exe) o compila desde un shell MSYS2 UCRT64:
# Run in an MSYS2 UCRT64 shell
cd Windows/firefox-fingerprint
g++ -municode -static -O2 -o monitor.exe monitor.cpp
Usa g++, no gcc. También ejecuta monitor.exe desde una terminal (no haciendo
doble clic en él), de lo contrario no hay consola adjunta para imprimir.
El vigilante se ejecuta como una segunda cuenta local sin privilegios, separada de la que navega. Primero, crea esa cuenta a través de Configuración:
attacker, y una contraseña, luego Siguiente.Esto crea una cuenta local (no vinculada a una cuenta de Microsoft, sin inicio de sesión en red), con privilegios estándar (no administrador) por defecto.
A continuación, coloca monitor.exe en algún lugar donde la nueva cuenta pueda realmente leerlo y
ejecutarlo. Copia el binario compilado en el directorio público y legible por todos
en su lugar:
copy monitor.exe C:\Users\Public\monitor.exe
Ahora, desde tu cuenta principal (víctima), lánzalo bajo la cuenta attacker
sin cambiar de escritorio ni cerrar sesión, usando runas:
runas /user:attacker "cmd /k C:\Users\Public\monitor.exe"
Introduce la contraseña de attacker cuando se solicite. cmd /k (en lugar de ejecutar
monitor.exe directamente) mantiene la ventana de consola abierta para que puedas ver su
salida, mientras que simplemente runas /user:attacker C:\Users\Public\monitor.exe también
funciona, pero su ventana se cierra en el instante en que el proceso termina. Esto es puramente por
conveniencia.
Deja la ventana de monitor.exe ejecutándose, luego, de vuelta en tu cuenta principal, abre
Firefox y visita un par de sitios web diferentes, por ejemplo,
arstechnica.com y reddit.com.
Cada línea impresa es una creación/modificación/renombrado de archivo bajo una ruta de almacenamiento que coincide
con http. Diferentes sitios obtienen diferentes directorios de origen y, por lo tanto, el conjunto de
rutas tocadas mientras se carga una página ya es una huella digital.
Por simplicidad, usamos fswatch, una
herramienta CLI existente, mínima y ampliamente utilizada que envuelve la API nativa FSEvents. Un
atacante también puede usar la API FSEvents sin esta herramienta.
Instala fswatch, o compila desde el código fuente:
brew install fswatch
Vigila /Applications recursivamente, como un usuario sin privilegios:
fswatch -xr /Applications
Déjalo ejecutándose, luego, desde el Finder o un navegador, descarga e instala Zoom
(o cualquier otra aplicación), luego desinstálala (puede que también tengas que vaciar la papelera).
fswatch imprime cada ruta que FSEvents reporta bajo /Applications a medida que
ocurre. Para una evaluación rápida, el mismo usuario puede monitorear el directorio.
De lo contrario, puedes configurar un nuevo usuario y usar fswatch como ese usuario.
Publicado bajo la Licencia MIT.