Ранее мы писали про некоторые механизмы затруднения эксплуатации (mitigation) для Windows и приложений, которые Microsoft пыталась привнести с выпуском новых ОС. Как правило подобные механизмы основываются на следующих концептуальных подходах:
- Разграничение прав доступа приложений к ресурсам ОС (User Account Control, Integrity Level). Vista+
- Особые смягчающие факторы при работе с памятью DEP&ASLR. XP SP2/Vista+. DEP задается системными настройками и в Windows 8+ активен для всех приложений (поддержка процессора). ASLR работает для приложений, скомпилированных с его поддержкой.
- Kernel ASLR/DEP, для компонентов, которые работают в режиме ядра. Vista SP1+. ASLR/DEP активен по умолчанию для модулей режима ядра, DEP от исполнения данных в пуле требует выделений из NonPagedPoolNx (Windows 8+).
- Защита от перезаписи указателей на функции в SEH на уровне ОС (SEHOP). Vista SP1+. По умолчанию активен только для серверных выпусков.
- Бесплатный инструмент EMET (v 4.1 last update) для повышения иммунитета системы от действий эксплойтов. Для Windows XP+.
- Расширенная изоляция процессов AppContainer (aka sandboxing, расширенный Integrity Level). Windows 8+. Используется для Internet Explorer 10+ и всех приложений Modern UI aka Metro.
- Блокирование доступа к получению информации об адресах объектов ядра для недоверенных приложений (KASLR bypass mitigation). Windows 8.1.
Последний пункт заслуживает особого внимания, поскольку такое нововведение было добавлено MS именно в Windows 8.1 как расширение для AppContainer mode или Integrity Level. Условно говоря, недоверенное приложение aka restricted caller (чей Integrity Level < Medium) не имеет права получить информацию об адресах различных объектов в режиме ядра, что означает фактическую компрометацию ограничений KASLR и последующую возможную эксплуатацию LPE (Local Privelege Escalation). Основными функциями разглашения подобной информации были разумеется NtQuerySystemInformation с различными классами, а также NtQueryProcessInformation. Именно к этим функциям ограничен доступ для соответствующих приложений.
В случае c NtQuerySystemInformation приложению с низким Integrity Level будет возвращен STATUS_ACCESS_DENIED если он запрашивает информацию по следующим классам:
- SystemModuleInformation/SystemModuleInformationEx — адреса загруженных драйверов
- SystemLocksInformation — адреса объектов ядра (ERESOURCE)
- SystemStackTraceInformation — адрес стека режима ядра
- SystemHandleInformation/SystemExtendedHandleInformation — адреса объектов ядра
- SystemObjectInformation — адреса объектов ядра
- SystemBigPoolInformation/SystemSessionBigPoolInformation — адреса выделенной системной памяти
- SystemProcessInformation/SystemExtendedProcessinformation/SystemFullProcessInformation — адреса объектов ядра процессов, потоков и их стеков.
Рис. Точки вызова функции проверки Integrity Level в маркере доступа приложения, которое пытается получить доступ к ntoskrnl!NtQuerySystemInformation. ntoskrnl!ExpQuerySystemInformation отвечает за сбор информации для соответствующих классов, в ней и выполняется вызов функции ntoskrnl!ExIsRestrictedCaller, которая осуществляет саму проверку.
Кроме NtQuerySystemInformation доступ блокируется и к функции NtQueryInformationProcess, через которую приложение может получить доступ к адресам различных объектов. Для классов ProcessHandleTracing, ProcessWorkingSetWatch/ProcessWorkingSetWatchEx также возвращается соответствующий статус ошибки.
Автор: esetnod32