17.09.2026
2 хв
202
Дослідники Технічного університету Граца показали, як штатні механізми Windows, Linux, Android і macOS дозволяють стежити за діями користувачів без читання їхніх файлів. Система може заборонити доступ до документа, але водночас повідомити сторонній програмі про його появу, зміну або видалення. Цих слідів іноді вистачає, щоб визначити відвіданий сайт, помітити обмін файлами у WhatsApp або зафіксувати ритм набору тексту.
У роботі File Notification Attacks автори дослідили ці витоки на кількох платформах і продемонстрували різні сценарії зловживання. Найнеприємніше тут те, що для спостереження не завжди потрібні права адміністратора. Однак це не атака «з будь-якої точки інтернету»: шкідливий код уже має працювати на відповідному пристрої чи сервері. Саме після цього звичайна службова функція може перетворитися на джерело інформації про чужу активність.
Операційна система постійно повідомляє програмам, що відбувається з файлами. Завдяки цьому файловий менеджер одразу показує щойно завантажене фото, редактор помічає зовнішню зміну документа, а програма синхронізації розуміє, що потрібно відправити нову версію у хмару. Без таких повідомлень застосункам довелося б безперервно перевіряти папки. Механізм корисний, швидкий і настільки звичний, що зазвичай залишається поза увагою користувача.
У кожній операційній системі є свій механізм файлових сповіщень, який допомагає програмам реагувати на зміни:
Linux використовує, зокрема, inotify;
Android надає застосункам FileObserver, що спирається на inotify;
Windows має механізм ReadDirectoryChangesW;
macOS використовує FSEvents.
Назви різні, принцип подібний: програма підписується на події та отримує сигнал, коли з файлом чи папкою щось відбувається. Залежно від платформи повідомлення може містити тип операції, ім’я файлу або шлях до нього. Саме на цьому стику між корисною автоматизацією та контролем доступу й виникає проблема.
Уявіть зачинений кабінет. Ви не бачите документів на столі, але отримуєте сповіщення щоразу, коли всередину заносять папку, відкривають шафу чи виносять конверт. Якщо на конверті ще й написано, звідки він прийшов, спостерігачеві не обов’язково знати його вміст. Так працює побічний канал: висновок про приховану дію роблять за її зовнішніми ознаками. У частині Windows-сценаріїв усе ще прямолінійніше: назва сайту фактично опиняється у видимому файловому шляху.
Команда спочатку зіставляла звичайні дії з файловими подіями: запускала програми, відкривала сайти, змінювала налаштування, підключала пристрої. Так утворювалися шаблони поведінки, за якими пізніше можна впізнавати активність. Водночас одне повідомлення не завжди однозначне: різні дії можуть залишати однакові сліди. Тому в дослідженні є і майже пряме розкриття інформації, і статистичне розпізнавання, яке помиляється. Змішувати їх в одну «стовідсоткову шпигунську технологію» було б неправильно.
Базовий сценарій для настільних систем передбачає непривілейований процес, який працює від імені іншого користувача на тій самій машині. Це може бути програма в окремому обліковому записі або скомпрометований сервіс. У випадку Android дослідники розглядали встановлений шкідливий застосунок без додаткових дозволів. Відсутність запиту на доступ до фотографій тут не означає, що програма нічого не здатна дізнатися про появу медіафайлів.
Важлива й межа між «уже запустився» та «вже має повний контроль». Програма з обмеженими правами не повинна автоматично бачити приватні дані інших користувачів. Саме для цього існують облікові записи, дозволи та ізоляція. Дослідження показує, як частина інформації просочується крізь ці межі: читання заборонене, а повідомлення про дії все одно доходять до спостерігача. Це додаткові можливості для вже присутнього коду, а не самостійний спосіб його доставки.
На сайті проєкту автори зазначають, що їм невідомі випадки використання саме цих атак у реальному світі. Вони демонструють дослідницькі сценарії, а не описують викриту масову кампанію. Також результати прив’язані до конкретних версій, конфігурацій і програм. Належність пристрою до Windows чи Android сама собою не означає, що кожен експеримент відтвориться на ньому без змін.
У Windows дослідники виявили особливо промовисту поведінку. Якщо непривілейований користувач підписувався на зміни в корені диска C:\, він міг отримувати повні шляхи до файлів в інших користувацьких профілях. Без права прочитати ці файли і навіть без звичайного доступу до відповідних каталогів. Експерименти проводили на Windows 11 24H2, використовуючи окремий непривілейований обліковий запис для спостереження за активністю іншого користувача.
Браузер виявився зручним джерелом таких слідів. Коли сайт використовує локальне сховище, IndexedDB чи кеш, браузер створює або змінює відповідні файли. У Firefox назва сайту може бути частиною шляху до каталогу цих даних. Тож спостерігачеві не потрібно відкривати історію браузера: достатньо побачити файлову подію з характерним шляхом. Папка формально приватна, але її адреса вже розповідає зайве.
Для перевірки команда взяла список тисячі популярних сайтів. Із них 25 не відповідали, тому оцінювання охопило 975 доступних ресурсів. У Firefox показник F1 склав 97,8%, а в Edge – 48,5%. Різниця пов’язана з поведінкою сховищ у цих браузерах: у перевіреному сценарії Edge залишав потрібні сліди для меншої кількості сайтів. Це не робить його універсальним захистом від усіх файлових витоків, але добре показує залежність результату від конкретної програми.
F1 – це метрика, яка поєднує точність позитивних визначень і повноту виявлення. Її не варто переказувати як «нападник бачить 97,8% усього, що ви робите». У цьому досліді йшлося про визначення відвідувань у заданому наборі сайтів. Автори не зафіксували хибних позитивних спрацьовувань у Windows-тесті, проте частину відвідувань механізм не виявляв. Це конкретний експериментальний результат, а не гарантія для кожного браузера й кожного ресурсу.
І справа не обмежується вебсерфінгом. У роботі описано характерні зміни файлів під час запуску Steam, роботи Zoom, налаштування системи та друку. Окремо дослідники зауважили, що повне сканування Windows Defender могло породжувати події, які розкривали шляхи до файлів, з обмеженням через кешування результатів перевірки. Це не аргумент проти антивіруса. Це аргумент проти ситуації, коли стороння програма отримує зайві відомості про роботу інших компонентів системи.
У Linux команда знайшла розбіжність у перевірці дозволів: спроба підписатися безпосередньо на недоступний файл завершувалася відмовою, але спостереження за доступною батьківською директорією могло видавати події щодо файлів усередині. Особливо цікавим виявився каталог /dev/input, де система представляє пристрої введення. На вразливих конфігураціях файлові події дозволяли помічати натискання й відпускання клавіш без читання самих подій клавіатури.
Тут легко зіпсувати новину гучним заголовком. Дослідники не показали, що цей механізм одразу повідомляє, яку саме літеру набрав користувач. Він видає моменти натискань і часові проміжки між ними. У тестах із сімома учасниками F1 для виявлення клавіатурних подій становив від 93,1% до 100%. Для окремого учасника, який заздалегідь тренувався набирати текст, отримали 100%. Розпізнавання подій і відновлення самого тексту – різні завдання.
Втім, відмахуватися від ритму набору теж не варто. Людина по-різному витрачає час на сусідні й віддалені клавіші, повтори, виправлення та знайомі поєднання. У дослідженнях побічних каналів такі інтервали використовують як додаткові ознаки для аналізу введення. Ця робота показує спосіб отримання сигналу; повне відновлення довільного пароля чи переписки з нього автори цим експериментом не доводять. Загроза реальна, але конкретні можливості потрібно називати чесно.
Схожий ефект перевірили під час роботи через SSH. Спостерігаючий процес запускався на віддаленому сервері й фіксував події псевдотермінала іншого користувача. У досліді з 402 натисканнями отримали F1 100%. Це не перехоплення зашифрованого трафіку десь посеред мережі: нападник уже має можливість виконувати код на сервері. До того ж потрібне текстове оновлення термінала. Введення пароля sudo без відображення символів у цьому сценарії таких сповіщень не давало.
Інший Linux-експеримент стосувався сайтів. Firefox звертається до системних шрифтів, і різні сторінки створюють різні послідовності звернень. Автори спостерігали за 1448 файлами шрифтів, навчали класифікатор на слідах відвідувань сотні сайтів і додали ще 750 сайтів поза цільовим набором. У такій перевірці F1 становив 87,9%. На відміну від Windows, де назва ресурсу могла прямо опинитися у шляху, тут сайт визначали за непрямим малюнком активності.
На Android дослідники працювали з Google Pixel 9a та Samsung Galaxy A54 під керуванням Android 16. Тут проблема виникала на межі між FileObserver і механізмом розмежування доступу до сховища. Система формує для застосунків обмежене представлення файлів: стороння програма не повинна просто перелічувати все, що належить іншому застосунку. Але в експериментах сповіщення показували імена й шляхи об’єктів, яких ця програма не бачила під час звичайного перегляду каталогу.
Показовим прикладом став WhatsApp. Йдеться про медіафайли в каталозі застосунку на спільному, зокрема емульованому, сховищі, а не про довільне читання всіх його внутрішніх баз даних. Коли месенджер завантажував отримане зображення чи документ, виникала файлова подія. Сторонній застосунок міг дізнатися про появу об’єкта, його ім’я та час події, хоча не отримував самого фото чи документа. Для спостереження за активністю цього вже достатньо.
Демонстрація на сайті авторів показує, скільки можна дізнатися лише за розташуванням файлу та файловими подіями:
Отримання медіа. Новий файл у каталозі WhatsApp показує, що застосунок завантажив зображення, відео чи документ.
Надсилання медіа. Окремі підкаталоги Sent допомагають відрізнити надіслані файли від отриманих.
Видалення. Якщо медіафайл прибирають, це теж залишає подію, яку може помітити спостерігач.
За іменем або розширенням файлу іноді можна визначити його тип, а за часом подій скласти хронологію обміну. Водночас ці сліди не розкривають вміст повідомлення й самі по собі не показують, з ким саме спілкувався користувач.
Шифрування месенджера від цього не стає «зламаним»: спостереження відбувається на пристрої, де застосунок уже обробляє отримані дані. Для приватності різниця між вмістом і метаданими важлива, але метадані теж можуть бути чутливими. Коли людина активна, чи обмінюється документами, коли прибирає отримані файли – це вже інформація про поведінку. І дозвіл «не давати доступ до фото» не повинен перетворюватися на декоративну табличку, якщо інший системний механізм видає їхні сліди.
У macOS дослідники побачили менше витоків. Вони не виявили аналогічного обходу, який дозволяв би через FSEvents спостерігати за недоступними приватними директоріями. Джерелом інформації залишалися загальнодоступні системні файли й каталоги. Перевірку проводили на комп’ютері з Apple M2 та macOS Sonoma 14.2.1. Тому результати цієї конфігурації не слід без додаткової перевірки оголошувати повною характеристикою всіх сучасних версій macOS.
Попри ці обмеження, зміни системних файлів дозволяли помічати встановлення й видалення програм, підключення зовнішнього накопичувача, дії з принтерами, мережевим з’єднанням та параметрами живлення. Для деяких застосунків спостерігали характерні сліди запуску чи завершення роботи. Наприклад, операції з Bluetooth-пристроями змінювали відповідні конфігураційні файли. При цьому не кожен окремий сигнал був унікальним: автори прямо зауважують, що певні зміни могли мати кілька причин.
Отже, ставити macOS в один ряд із Windows за масштабом розкриття приватних шляхів було б перебільшенням. Водночас спільна проблема помітна й тут: загальносистемні події можуть повідомляти про поведінку користувача більше, ніж здається на перший погляд. Для стеження корисний не лише документ із секретом усередині, а й факт запуску певної програми або підключення пристрою. Оцінювати потрібно конкретну інформацію, яку система віддає, та того, хто її отримує.
Окремий експеримент показує, навіщо нападнику знати точний момент системної події. У KDE Plasma 6.3.6 з Wayland дослідники використали файлове сповіщення, щоб визначити запуск механізму запиту підвищених прав. Після цього шкідлива програма показувала підроблене вікно поверх справжнього. Людина очікує системний запит і вводить пароль у переконливий діалог, але його вже приймає чужа програма. Файловий канал тут працює як сигнал для вчасного обману.
Для цієї демонстрації модель загрози інша: шкідливий процес працює від імені самого користувача в його графічному сеансі. Це не продовження сценарію, де сторонній обліковий запис автоматично отримує право малювати вікна на чужому екрані. Так само йдеться не про універсальний злам Wayland. Атака поєднує можливість вчасно помітити дію з можливістю перекрити відповідне вікно у дослідженому середовищі.
За викладом авторів, команда KDE відповіла, що механізм запобігання перехопленню фокуса задуманий для боротьби з небажаними спливними вікнами, а не як захисна межа. На сайті проєкту дослідники пропонують локальне правило, яке примусово тримає діалог пароля поверх інших вікон. Це слід розглядати як запропоноване пом’якшення для конкретного сценарію, а не як гарантію проти всіх підроблених системних запитів.
Команда повідомляла про результати виробникам ще у 2025 році. За викладом дослідників, Microsoft спочатку розцінила розкриття імен і шляхів як передбачену поведінку та відокремила його від витоку вмісту файлів. Але для повної картини важливе уточнення, яке автори додали на сайт проєкту: у Windows існує механізм посилення перевірок доступу, що пом’якшує описану поведінку. Тому твердження «Microsoft нічого не зробила і захисту немає» вже не відповідає доступній інформації.
У документі Microsoft KB5058189 зазначено, що виправлення входить до оновлень від 8 квітня 2025 року та пізніших. Воно додає перевірку прав перед передаванням повідомлень і фільтрує події, якщо належного доступу немає. Однак за замовчуванням захист вимкнений через можливі проблеми сумісності. Його вмикають параметром EnforceDirectoryChangeNotificationPermissionCheck зі значенням 1; офіційна інструкція описує варіанти через реєстр і PowerShell. Для адміністратора це привід перевірити не лише встановлені оновлення, а й стан налаштування та сумісність робочих програм.
У Linux частину проблеми закрили виправленням CVE-2025-68788: воно обмежує передавання спостерігачам батьківського каталогу подій доступу й модифікації спеціальних файлів. На сайті дослідження перелічено гілки з виправленням: 5.10.248, 5.15.198, 6.1.160, 6.6.120, 6.12.65 та 6.18.3. Це важливо для найгостріших сценаріїв із файлами пристроїв, але не прибирає всі можливі інформаційні сліди. Для конкретного дистрибутива потрібно дивитися його пакетні оновлення й перенесені патчі, а не лише порівнювати номер ядра; стан, наприклад, відстежує Debian Security Tracker.
Станом на перевірку джерел 29 вересня 2026 року сайт дослідників не вказує окремих виправлень для описаних Android- і macOS-сценаріїв. Це формулювання стосується оприлюдненого авторами статусу, а не доводить уразливість кожної актуальної збірки. Також не можна переносити виправлення спеціальних файлів Linux на Android-проблему зі сховищем WhatsApp: механізми витоку різні. Тут потрібні окремі перевірки та відповідні зміни в реалізації платформи.
Практичний висновок починається з програм, яким ви дозволяєте працювати на пристрої. Відсутність прав адміністратора або запиту на небезпечний дозвіл не робить застосунок автоматично нешкідливим. Менше непотрібного софту, перевірене походження інсталяцій і своєчасні оновлення зменшують можливість опинитися в описаній ситуації. Це не спеціальна «кнопка проти побічних каналів», а спосіб скоротити кількість процесів, здатних скористатися зайвою видимістю системи.
Для спільних комп’ютерів і серверів дослідження дає кілька конкретних приводів перевірити налаштування:
На Linux з’ясувати, чи отримала система виправлення ядра для CVE-2025-68788. Воно обмежує витік через спеціальні файли, хоча не закриває всі описані побічні канали.
На Windows перевірити посилену перевірку прав для файлових сповіщень. Microsoft включила цю можливість до оновлень, але за замовчуванням вона вимкнена.
Для робочих навантажень оцінити, який сторонній код може працювати на тій самій машині та які системні події йому доступні.
Окремі облікові записи залишаються потрібними, але не гарантують приховування всіх метаданих. Ізоляцію теж варто оцінювати за реальною конфігурацією: сама назва «контейнер» ще не означає, що всі системні сліди розділені.
Розраховувати на VPN як на виправлення цієї проблеми немає підстав: досліджені сигнали виникають у файловій системі пристрою або сервера, а не лише на мережевому маршруті. Так само очищення історії браузера після роботи не скасовує повідомлень, які спостерігач уже отримав. Це висновок із механізму атаки, а не окремий тест усіх VPN чи режимів приватного перегляду. Реальний захист має обмежувати джерело витоку та доступ спостерігаючої програми.
Ця історія б’є по зручному уявленню, що приватність закінчується на забороні читання файлу. Насправді система має берегти й те, що можна зрозуміти з його назви, розташування та моменту появи. Якщо чужа програма бачить, коли ви відкриваєте сайт, отримуєте документ або набираєте текст, фраза «сам файл вона не прочитала» звучить слабко. Замок потрібен. Але повідомляти стороннім про кожен рух за дверима теж не варто.
