Windows был модифицирован отключен patchguard

Обновлено: 02.07.2024

Когда Microsoft представила Vista, компания сообщила о серьезных изменениях в принципе работы Windows. Возможно, самым заметным из этих изменений была функция под названием PatchGuard.

Она была разработана с целью создания более безопасного компьютерного окружения, но стала причиной дискуссий между производителями и пользователями. В данной статье мы протестируем PatchGuard и узнаем, почему несмотря на спорную реализацию, данная функция помогает сделать Windows более безопасной.

Перед тем, как начать тестировать PatchGuard, необходимо поговорить о внесении изменений в ядро. Внесение изменений или исправлений в ядро, также известный как подключение к ядру, - процесс по модифицированию поведения ядра операционной системы или перехвату определенных событий. Некоторые производители продуктов по обеспечению безопасности, в частности McAfee и Symantec, используют подключение к ядру для реализации своих антивирусных служб, защиты ОС и своих приложений путем перехвата обращений и блокирования потенциально вредоносных процессов и служб.

PatchGuard, иначе известная как Kernel Patch Protection, стала причиной дискуссий потому, что блокирует такой тип модификации операционной системы. PatchGuard проводит мониторинг кода ядра и системных ресурсов, используемых ядром, и инициирует автоматическое выключение системы в случае обнаружения неавторизированных изменений.

PatchGuard и защита от руткитов
У Microsoft есть серьезная причина, чтобы блокировать ядро ОС: предотвращение работы руткитов. По сути дела, руткит - вредоносный файл, который позволяет реализовать доступ к компьютеру или сети с администраторскими правами. Так как руткиты подключаются к ядру, это повзоляет им избегать обнаружения, при этом они имеют неограниченный доступ ко всем ресурсам системы.

В 2005 году весь мир узнал, что Sony BMG Music Entertainment использовала ПО для защиты от копирования на основе руткита. Руткит от Sony использовал подключение к ядру, чтобы препятствовать и блокировать попытки записи копий диска. Чтобы заблокировать возможность руткитам или другому вредоносному ПО подключаться к ядру, Microsoft усилила защиту своего ядра с помощью PatchGuard.

Является ли PatchGuard средством обеспечения безопасности?
Сторонние производители программного обеспечения, в частности разработчики антивирусов и продуктов по обеспечению безопасности бурно возмущались тем, что они не будут иметь возможности подключатся к ядру, что, в свою очередь, привело бы к необходимости созданию их программного обеспечения с нуля. Они заявляли, что блокируя независимых разработчиков Microsoft может оставить ядро открытым для атак вредоносного ПО. Как и любая функция безопасности PatchGuard неидеальна, но вместе с тем сможет выявить манипуляции с ядром вне зависимости от того, кто их проводит - вредоносное или антивирусное ПО, так что возмущения антивирусных компаний о том, что данная технология блокирует только хороших парней бессмысленны.

Некоторые производители продуктов безопасности до сих пор заявляют, что без неограниченного доступа к системному ядру они не могут проводить комплексные функции, необходимые для предотвращения вторжений в систему. По определению - системы предотвращения вторжений должны уметь проводить мониторинг и анализ всего, что входит и выходит из компьютера, а также всех запускаемых служб и процессов, включая те, которые принадлежат ядру, чтобы иметь возможность правильно их оценить и соответствующе отреагировать. Производители продуктов по обеспечению безопасности должны развить свои модели безопасности так, чтобы полностью доверять ядру и инспектировать все другие процессы и события, при этом Microsoft уже работает с производителями продуктов безопасности над новыми API, которые бы позволили им работать с ядром в авторизированном режиме.

Хотя стратегия Microsoft вынуждает производителей продуктов безопасности изменить способы защиты компьютеров, кажется бессмысленным просить Microsoft нарочно оставить ядро открытым, чтобы облегчить производителям ПО для обеспечения безопасности защитить ОС. В конечном итоге, PatchGuard - взаимоисключающее условие для для индустрии программного обеспечения для организации защиты: пользователи Windows и независимые разработчики в одинаковой степени требовали, чтобы Microsoft встроила больше функций безопасности в Windows, результатом чего стала функция PatchGuard. Однако, несмотря на то, что внутренне Windows стала безопасней, PatchGuard вынудил некоторых производителей переосмыслить свою стратегию безопасности Windows после того, как они потеряли возможность модифицировать ядро операционной системы. Некоторые производители антивирусов, к примеру Sophos, поддерживают новую модель безопасности Microsoft и заявляют, что их конкуренты тратят время на войну с Microsoft, вместо того, чтобы разрабатывать работающие программы. Хорошо то, что PatchGuard реализована только в х64-редакциях Windows Vista, доля которой на рынке растет, но которой пользуется малая толика от общего процента пользователей Windows Vista.

В компаниях суть проблемы отпадает, так как они доверяют Microsoft самой создавать продукты безопасности. При условии, что ядро действительно защищено PatchGuard, Microsoft надеется, что большая часть того, что реализуют независимые разработчики не будет необходима. У разработчиков продуктов безопасности есть несколько успешных разработок по обходу PatchGuard, которые предполагают, что атакующие также смогут обойти PatchGuard. Компании, которые используют Vista х64 и полагаются на PatchGuard, должны удостоверится в том, что у них установлены новейшие обновления от Microsoft, чтобы смочь избежать таких атак. Однако, они также должны заставить своего производителя продуктов по обеспечению безопасности рассказать компании, как их продукт работает с PatchGuard и нет ли какого-либо сокращения функциональности или уровня безопасности из-за нарушенной безопасности ядра, обеспечиваемой PatchGuard.

Вместо того, чтобы толкать Microsoft к тому, чтобы вернуться к более слабой модели безопасности, оставив ядро ОС открытым, компании должны поощрять своих разработчиков продуктов по обеспечению безопасности разрабатывать продукты, которые смогут работать в тандеме с PatchGuard. Производителям необходимо постоянно обновлять свой подход к безопасности и адаптироваться к изменения в самой Windows. Им нужно методично эволюционировать в понимании того, что необходимо защищать и как это делать, а разработчикам необходимо сотрудничать с Microsoft, чтобы получить необходимую им функциональность. Но гораздо разумнее потребовать, чтобы независимые разработчики развивали свое видение безопасности вместе с Microsoft вместо того, чтобы требовать, чтобы Microsoft стала инертной или вернулась к менее безопасным системам.

Безопасность ядра
Ядро - это сердце и душа операционной системы. В то время, как малейшая ошибка при внесении изменений в ядро может привести к нестабильности и ненадежности системы, наличие руткита, скрыто ингегрированного в ядро операционной системы, чтобы избежать его обнаружения самой операционной системой или сторонними продуктами безопасности - намного больший риск для компаний. Именно по этой причине PatchGuard представляет собой наиболее эффективный способ борьбы с сегодняшним вредоносным ПО и наиболее совершенной защитой ядра.

Периодически, как правило во вторую среду месяца, можно услышать истории о том, что Windows после очередного обновления перестает загружаться, показывая синий экран смерти. В большинстве случаев причиной такой ситуации оказывается либо руткит, либо специфичное системное ПО, фривольно обращающееся со внутренними структурами ОС. Винят, конечно, все равно обновление, ведь «до него все работало». С таким отношением не удивительно, что «Майкрософт» не поощряет использование всего, что не документировано. В какой-то момент, а именно с релизом Windows Server 2003, MS заняла более активную позицию в вопросе борьбы с чудо-поделками сторонних разработчиков. Тогда появился механизм защиты целостности ядра — kernel patch protection, более известный как PatchGuard.

С самого начала он не позиционировался как механизм защиты от руткитов, поскольку руткиты работают в ядре с теми же привилегиями, а следовательно, PatchGuard может быть обезврежен. Это скорее фильтр, отсекающий ленивых разработчиков руткитов.

Что охраняет PatchGuard

Самым популярным местом модифицирования ядра была таблица системных вызовов. При помощи модификации указателей на функции системных вызовов можно было легко их перехватывать, фильтровать, логировать и т. п. Причем этот патч был популярен как для руткитов, так и для антивирусного ПО. Другие интересные для патча объекты — таблицы дескрипторов (GDT, IDT). Через модифицирование глобальной таблицы дескрипторов можно было изменять атрибуты сегментов, создавая бекдоры для кода, а через таблицу дескрипторов прерываний можно было перехватывать… прерывания! Продвинутые же парни сплайсили непосредственно функции ядра.

таблицы системных вызовов (SST),
глобальную таблицу дескрипторов (GDT),
таблицу дескрипторов прерываний (IDT),
образ ядра,
ядерные стеки.

множество системных образов, не только образ ядра (nt, hal, WerLiveKernelApi, tm, clfs, pshed, kdcom, bootvid, ci, msrpc, ndis, ntfs, tcpip, fltmgr),
критически важные структуры данных ядра (например, список процессов),
набор MSR (например, model specific регистр IA32_LSTAR),
KdpStub — процедура отладчика, получающая управление после исключений.

Как охраняет PatchGuard

Стоит отметить, что PatchGuard активно использует новую реализацию обработки исключений, введенной в x64-версиях Windows. Используется он как для обфускации самого PatchGuard, так и для проверки целостности защищаемых образов.

За счет того, что адрес начала и конца любой функции можно получить прямо в рантайме, задача подсчета контрольной суммы отдельно взятой функции становится тривиальной. Для сравнения — в x86-версиях контроль целостности образов невозможен из-за того, что непонятно, как определить границы отдельной функции, а образ целиком (или даже отдельные его секции) накрывать контрольной суммой нельзя, поскольку в том же ядре присутствуют функции, которые патчатся самим ядром на лету.

При загрузке ОС PatchGuard создает от 1 до 4 контекстов — структур данных, в которых хранятся копии используемых им функций, контрольные суммы защищаемых структур и ключи шифрования самого контекста. Эти контексты хранятся в неподкачиваемом пуле в зашифрованном виде. О проверке контекстов поговорим чуть позже.

Инициализируются контексты PatchGuard в фазе 1 загрузки ОС. Функция, непосредственно занимающаяся созданием контекста, не имеет публичного символа (будем называть ее KiInitializePatchGuardContext), но найти ее можно внутри функции KiFilterFiberContext. Мы нашли два места, в котором возможно создание контекста PatchGuard:

Первый вариант всегда создает хотя бы один контекст, в то время как второй только в 4% случаев. Также первый вариант примечателен тем, что вызывает функцию KiFilterFiberContext неявно, а именно через «вброс» исключения.

Функция sub_14071815C очевидно не имеет публичного символа, поскольку связана с проверкой лицензии ОС.

Ниже приведен псевдокод функции KiFilterFiberContext, выбирающей способ проверки конкретного контекста и вызывающей функцию создания самого контекста.

Функция, создающая контекст PatchGuard, обфусцирована настолько, что автоматические средства с ней не справляются, а исследователям внезапно становится неинтересно ее реверсить. В статике это полная каша, 10K+ строк декомпилированного «в лоб» кода (сама декомпиляция в IDA Pro занимает около 40 минут).

даже простейшая операция, такая как взятие случайного числа, размазана на 50+ строк ассемблерного кода;
все циклы развернуты;
вставлено много «мертвого» кода;
используется косвенное обращение к переменным и внешним функциям.

При подключенном отладчике входит в бесконечный непрерываемый цикл.
Загружает временную невалидную таблицу дескрипторов прерываний. Если мы следили за доступом к отладочным регистрам, произойдет отладочное исключение, которое при данных условиях приведет к tripple fault с последующей перезагрузкой.

Индекс DPC функции, которая будет вызвана для проверки контекста и может быть одной из следующих:
- KiTimerDispatch
- KiDpcDispatch
- ExpTimerDpcRoutine
- IopTimerDispatch
- IopIrpStackProfilerTimer
- PopThermalZoneDpc
- CmpEnableLazyFlushDpcRoutine
- CmpLazyFlushDpcRoutine
- KiBalanceSetManagerDeferredRoutine
- ExpTimeRefreshDpcRoutine
- ExpTimeZoneDpcRoutine
- ExpCenturyDpcRoutine
Метод планирования проверки:
1. KeSetCoalescableTimer
  Создается объект таймера, который запустит проверку через 2м:05с ± 5 с.
2. Prcb.AcpiReserved
  DPC сработает при определенном ACPI событии, например, при переходе в состояние низкого энергопотребления. Сработает не раньше чем через 2м:05с ± 5 с.
3. Prcb.HalReserved
  DPC сработает при тике таймера HAL. Не раньше чем через 2м:05с ± 5 с.
4. PsCreateSystemThread
  Создается отдельный системный поток, спящий 2м:05с ± 5 с. После этого вызывается проверка контекста.
5. KeInsertQueueApc
  Создается regular kernel APC, срабатывающая сразу, но ждущая 2м:05с ± 5 с внутри work item.
6. KiBalanceSetManagerPeriodicDpc
  DPC сработает по таймеру менеджера балансировки, не раньше чем через 2м:05с ± 5 с.
Последовательности вызовов рекурсивных функций в зависимости от DPC-функции ExpTimerDpcRoutine -> KiCustomAccessRoutine0 -> KiCustomRecurseRoutine0… KiCustomRecurseRoutineN
IopTimerDispatch -> KiCustomAccessRoutine1 -> KiCustomRecurseRoutine1… KiCustomRecurseRoutineN
IopIrpStackProfilerTimer -> KiCustomAccessRoutine2 -> KiCustomRecurseRoutine2… KiCustomRecurseRoutineN
PopThermalZoneDpc -> KiCustomAccessRoutine3 -> KiCustomRecurseRoutine3… KiCustomRecurseRoutineN
CmpEnableLazyFlushDpcRoutine -> KiCustomAccessRoutine4 -> KiCustomRecurseRoutine4… KiCustomRecurseRoutineN
CmpLazyFlushDpcRoutine -> KiCustomAccessRoutine5 -> KiCustomRecurseRoutine5… KiCustomRecurseRoutineN
KiBalanceSetManagerDeferredRoutine -> KiCustomAccessRoutine6 -> KiCustomRecurseRoutine6… KiCustomRecurseRoutineN
ExpTimeRefreshDpcRoutine -> KiCustomAccessRoutine7 -> KiCustomRecurseRoutine7… KiCustomRecurseRoutineN
ExpTimeZoneDpcRoutine -> KiCustomAccessRoutine8 -> KiCustomRecurseRoutine8… KiCustomRecurseRoutineN
ExpCenturyDpcRoutine -> KiCustomAccessRoutine9 -> KiCustomRecurseRoutine9… KiCustomRecurseRoutineN

Проверка контекста состоит из двух этапов: сперва проверка структуры самого контекста, которая происходит на DPC-уровне, затем планируется work item, осуществляющий проверку защищаемых структур в системном потоке. Если проверка была удачной, старый контекст удаляется и вместо него создается новый, который будет запущен через случайный интервал времени. Если проверка не удалась, PatchGuard зачищает все свои следы, в том числе зануляя стек, и демонстрирует синий экран с кодом ошибки 0x109: CRITICAL_STRUCTURE_CORRUPTION.

Гифка с саморасшифровывающимся на первом этапе проверки контекстом:

Как победить
- Такой патч образа ядра, чтобы PatchGuard вообще не инициализировался.
- Патч процедур проверки контекста.
- Хук KeBugCheck с восстановлением состояния системы.
- Отмена запланированных проверок — то, что мы реализовали.
1. KeSetCoalescableTimer
  Необходимо просканировать все таймеры, DPC для которых будет содержать DeferredContext с неканоническим адресом, и увеличить интервал ожидания для найденных до бесконечности.
2. Prcb.AcpiReserved
  Просто занулить данное поле.
3. Prcb.HalReserved
  Просто занулить данное поле.
4. PsCreateSystemThread
  Просканировать спящие потоки и раскрутить их стек. Если он упирается в функцию из структуры KiServiceTablesLocked, это наш клиент. Выставляем время спячки, равное бесконечности.
5. KeInsertQueueApc
  Просканировать все рабочие потоки с раскруткой стека. Если в стеке встречаются функции не из кодовой секции ядра, причем раскручивающиеся с использованием данных для функций FsRtlMdlReadCompleteDevEx и FsRtlUninitializeSmallMcb, это точно рабочий поток PatchGuard. Обезвреживаем так же, как в предыдущем варианте.
6. KiBalanceSetManagerPeriodicDpc
  Восстановить «законную» процедуру — KiBalanceSetManagerDeferredRoutine.
Windows 10

При осмотре KiFilterFiberContext из Windows 10 Technical Preview мы заметили небольшое изменение. Все старые методы планирования остались прежними. Однако появился новый, который пока что безусловно возвращает STATUS_HV_FEATURE_UNAVAILABLE. Немного покопавшись, мы обнаружили функцию KiSwInterruptDispatch, внутри которой явно идет расшифровка и вызов проверки контекста. Очевидно, что будет добавлена возможность осуществлять проверку контекстов по запросу гипервизора Hyper-V. От гипервизора при определенных условиях будет приходить синтетическое прерывание, обработчик которого будет проверять целостность ядра.

История продолжается

В статье мы старались не указывать имена конкретных функций не потому, что нам жалко. Все просто: имена функций, используемых для расшифровки и проверки контекстов, намеренно изменены разработчиками PatchGuard и меняются в разных версиях ОС.

Вот пример несоотвтествия названия функции тому, чем она действительно занимается. Это та самая функция, копия которой используется для саморасшифровки контекста.

Одно хорошо — все эти функции находятся рядом, так что начать можно с функции KiFilterFiberContext. Очевидно, они все лежат в одном файле исходного кода. Однако проверка целостности ядра не ограничивается одним PatchGuard. В различные части ядра вставлены макросы, осуществляющие проверку тех или иных структур. Каждое такое место приходится искать вручную. Пример:

С вероятностью 50% данная функция осуществляет подсчет контрольной суммы для произвольной функции ядра и планирует ее проверку каждые 2 минуты в DPC с функцией CcBcbProfiler.

Так что удачи в поисках! PatchGuard интересен именно тем, что его весело реверсить ;)

21H2

Актуальная версия: Windows 11 10.0.22000.318 Выпуск функций 21H2