Специалисты по кибербезопасности из компании Deep Instinct обнаружили, что встроенный в Windows механизм изоляции контейнеров можно использовать не по назначению — для того, чтобы проводить файловые операции незаметно для защитных решений организации.
Как устроены контейнеры Windows
Контейнеры изменили сам подход к упаковке и изоляции приложений: каждое из них получает собственное окружение выполнения, что важно и для эффективного использования ресурсов, и для безопасности. Технологию Windows Container компания Microsoft представила ещё в Windows Server 2016, и с тех пор она работает в двух режимах — изоляции процессов (process isolation mode) и изоляции на базе Hyper-V (Hyper-V isolation mode).
В основе механизма лежат объекты Job, появившиеся в системе ещё в Windows Server 2003: они группируют процессы для единого управления и контролируют такие параметры, как использование CPU, ввод-вывод, память и сетевой трафик. Для многопроцессных приложений применяются вложенные Job (Nested Jobs), а более продвинутую функциональность добавляют так называемые Silo — именно их контейнеры используют в виде «Server Silo» для группировки процессов и перенаправления ресурсов. Определить, что процесс относится к силосу, ядро Windows может через API PsIsCurrentThreadInServerSilo и PsIsProcessInSilo.
Где именно кроется проблема
Ключевую роль в изоляции контейнеров играют точки повторного разбора (reparse points) — они хранят пользовательские данные, которые обрабатываются mini-filter драйверами файловой системы по уникальным идентифицирующим тегам. Чтобы не копировать файлы операционной системы для каждого контейнера, Windows использует динамические образы, ссылающиеся на оригиналы именно через reparse points.
Как поясняется в отчёте Deep Instinct, за разделение файловой системы контейнера и хост-системы отвечает mini-filter драйвер wcifs, который управляет перенаправлением «призрачных» файлов через reparse points с тегами IO_REPARSE_TAG_WCI_1 и IO_REPARSE_TAG_WCI_LINK_1.
Mini-filter драйверы подключаются к файловой системе не напрямую, а через диспетчер фильтров Microsoft (filter manager), который поддерживает работу устаревших фильтров, управляет их встраиванием, обработкой запросов и кросс-платформенной совместимостью, а для типовых операций предоставляет отдельный API — Flt API. Подключение происходит по числовым значениям altitude, и именно здесь обнаружился разрыв: драйвер wcifs.sys работает в диапазоне высот 180000–189999, тогда как антивирусные фильтры — в диапазоне 320000–329999. Из-за этого разрыва часть файловых операций может проходить, не вызывая callback-функции антивирусных драйверов, — то есть оставаясь вне поля зрения защитного ПО.
Обычно вендоры безопасности как раз и устанавливают собственные mini-filter драйверы для мониторинга ввода-вывода, применяя алгоритмы обнаружения вредоносной активности на уровне файловой системы. Но описанный разрыв altitude-диапазонов позволяет злоумышленнику обойти эту линию защиты.
Как закрыть брешь
Исследователи Deep Instinct предложили организациям и разработчикам защитных решений несколько мер:
- отслеживать вызовы
DeviceIoControlв сочетании сFSCTL_SET_REPARSE_POINTдля тегаIO_REPARSE_TAG_WCI_1, проверять их в callback-функцииPRE_WRITEи сканировать вPRE_CLEANUP, даже если файл не изменился; - проверять, что порт связи wcifs не используется процессами, не относящимися к системным;
- всегда сверять контейнер, сравнивая исходный и целевой тома;
- убедиться, что драйвер wcifs подключается пользовательским процессом, а не системным, либо когда функция контейнеров вовсе отключена.
Эти рекомендации адресованы прежде всего разработчикам систем защиты конечных точек — именно им предстоит скорректировать altitude-диапазоны и логику проверки reparse points, чтобы контейнерная изоляция Windows не превращалась в слепую зону для антивируса.
Источник: Cybersecurity News.