[Ciko 0]

Снапшоти - це не просто "точка відновлення"

Снапшот віртуальної машини - це повний зліпок стану оперативної пам'яті, диска та іноді навіть стану процесора на конкретний момент часу. Проблема в тому, що цей зліпок фізично зберігається на диску хост-системи у вигляді файлів (наприклад. Vmem для VMware або аналогічних файлів для VirtualBox), і в цих файлах буквально лежить дамп RAM гостьової системи на момент створення снапшота. Якщо ви робили снапшот під час активної сесії – там може бути все: розшифровані дані, ключі з оперативної пам'яті, відкриті сесії у браузері, навіть паролі, якщо вони на той момент перебували у пам'яті у відкритому вигляді.

Найнеприємніше навіть якщо ви потім відкотили снапшот або видалили VM повністю, сам файл снапшота на хості не обов'язково видаляється безпечно. Стандартне видалення файлу просто видаляє запис із таблиці файлової системи, а дані фізично залишаються на диску до перезапису. Тобто форензик-фахівець із доступом до хост-машин може відновити ці файли стандартними інструментами відновлення даних. Гіпервізор веде

Власні

логи - VMware Workstation і VirtualBox пишуть файли конфігурації, логи запуску/зупинки VM, іноді навіть історію змін налаштувань мережі. Це метадані про факт існування та використання віртуальної машини, і ці логи лежать на хості, а не всередині гостьової системи — тобто шифрування диска всередині VM їх взагалі не захищає.

Далі файл підкачки (swap/pagefile) хост-системи. Гіпервізор активно використовує оперативну пам'ять, і якщо у хоста недостатньо RAM, частина даних гостьової VM може вивантажуватись операційною системою хоста у файл підкачки на диску. Це означає, що фрагменти вмісту гостьової пам'яті теоретично можуть опинитися в page file хоста, повністю за межами вашого "захищеного" віртуального середовища.

Схожа історія з файлом глибокого сну хост-системи (hiberfil.sys в Windows) — якщо хост йшов у сон або глибокий сну, поки VM була запущена, в цьому файлі може застрягти знімок всієї оперативної пам'яті, включаючи пам'ять, що відноситься до гостьової системи.

Метадані файлової системи хоста

Навіть без аналізу вмісту, самі тимчасові мітки створення, зміни та доступу до файлів VM (vmdk, vdi, vmem, конфігураційні файли) дають форензику тимчасову лінію активності - коли VM створювалася, коли останній раз використовувалася, скільки разів вносилися зміни. Це не розкриває змісту, але відновлює патерн поведінки, що часто буває достатньо в поєднанні з іншими даними.

Чому Whonix і подібні рішення знижують, але не прибирають цю проблему повністю

. Але вона вирішує проблему форензики лише на рівні хоста, описану вище. Якщо зловмисник чи слідство отримує фізичний чи віддалений доступ до самого хоста, а не до гостьової VM, вся ізоляція всередині гіпервізора не має значення – артефакти лежать зовні периметра, який ця ізоляція захищає.

Практичні висновки, які я вважаю важливими

Повнодискове шифрування хост-системи (а не тільки гостьовий VM) - це не опція, а необхідність, якщо модель загрози має фізичний доступ до пристрою. Без цього всі перелічені файли – снапшоти, page file, hiberfil.sys – лежать у відкритому вигляді на хості незалежно від того, як захищена сама VM.

Відключення файлу глибокого сну на хості та налаштування достатнього об'єму RAM, щоб уникнути активного використання swap, знижує ймовірність витоку фрагментів пам'яті гостьової системи на диск хоста.

Безпечне видалення снапшотів (з перезаписом, а не просто delete) є обов'язковим, якщо снапшот містив чутливу сесію — інакше відновлення стандартними форензик-інструментами тривіальне.