Вскрываем защиту ProtectedLite процессов на уровне пользовательского кода
| Начну немного с теории - как это работает и для чего это нужно. При разработке нового ядра, отличного от ядра Windows XP, в Microsoft придумали такую штуку как изоляция критических процессов. Следствием этого стали защищенные процессы (Process Protected), которые могли создавать только при наличии соответствующей подписи и сертификата. Доступ к дескрипторам таких процессов был заблокирован на уровне ядра и чтобы их получить нужен подписанный драйвер режима ядра. Именно таким действием Microsoft и изолировала системные процессы от внедрения в них пользовательского кода. Впервые Process Protected (далее PP) были введены в Windows Vista. В купе с тем, что помимо изолированных процессов, Microsoft ввела новую модель изоляции окружения (Session 0 для системных процессов и служб, и Session 1 для пользовательских процессов), начался невиданный хаос в разработке нового и адаптации старого ПО под новые требования. PP процессы были настолько защищены, что даже разработчики антивирусов толком не могли адаптировать свои продукты под новую архитектуру ядра ОС (The Windows Vista and Windows Server 2008 Developer Story: Application Compatibility Cookbook) Поэтому, с релизом Windows 8.1 в Microsoft решили ввести новый тип процессов - Process ProtectedLite (далее PPL). PPL это тоже защищенные процессы, требующие подпись и сертификат. Их дескрипторы всё также заблокированы на уровне ядра и получить их стандартными методами из пользовательского кода невозможно. Но чем тогда отличаются PP от PPL? В основе модели PP лежит исполняемый файл и его родительский процесс. Всё просто и банально - есть подписанный файл, который при запуске создаёт процесс. Именно процесс и управляет тем, что ему предписано. А вот модель PPL кардинально отличается от PP. В основе всё также лежит исполняемый файл, но его запуск происходит через сервис (если быть точный через менеджер ServiceManager). Поэтому таким процессом управляет сервисная служба. Вместе с PPL в Microsoft ввели ещё одну защиту - SERVICE_LAUNCH_PROTECTED_INFO и вот такое небольшое пояснение Цитата:
In order to apply any protection type to a service, the service must be signed with an appropriate certificate.
... Once the service is launched as protected, other unprotected processes will not be able to call the following APIs on the protected service: • ChangeServiceConfig • ChangeServiceConfig2 • ControlService • ControlServiceEx • DeleteService • SetServiceObjectSecurity (*Для самообразования есть вот такая интересная статья о защите сервисов подписью AntiMalware Protecting Anti-Malware Services) Давайте рассмотрим более детально один из процессов svchost.exe (скриншот выше) Он является PPL процессом. Получить его DACL и оставшуюся часть SACL невозможно, защита процесса не позволяет открыть дескриптор с необходимыми флагами чтения, лишь только некоторую лимитированную информацию и то из-под LocalSystem (обычный пользовательский процесс, запущенный даже с правами администратора, сразу выдаст Отказано в доступе). Этот процесс имеет сервис управления wscsvc (Центр обеспечения безопасности) и как мы видим он подписан сертификатом Windows (как и родительский процесс) и относится к защищенным сервисам. Кроме того он находится в запущенном состоянии, и имеет определенный набор флагов допуска. Эти флаги позволяют управлять его состоянием (останавливать, запускать, удалять сервис и т.д.). Остановим этот сервис и посмотрим что произойдёт c родительским процессом Итак, сервис остановлен и родительский процесс отсутствует. Именно так и работает модель PPL процессов (управление таким процессом происходит через его сервис). И вот теперь самое интересное. В процессе исследования я обнаружил: либо эксплойт в системе защиты сервисов, позволяющий при определенных правах обойти сертификат и подпись, либо специально оставленный Microsoft бекдор. Elevated процесс, и даже LocalSystem процесс (со стандартным набором прав) не способны изменить защиту сервиса на другой тип. Вот что выдаёт ProcessHacker, запущенный от имени администратора (для Elevated процесса) с включенным драйвером режима ядра Кликните здесь для просмотра всего текста
Я расширил функционал своей программы и дал ей определенные привилегии, которые возможны без использования драйвера режима ядра. В результате была написана функция, способная изменять тип защиты сервиса. Как можно видеть я отключил защиту у сервиса wscsvc (None). Снова запустим сервис и по идентификатору (Process Id) откроем его родительский процесс. И вот - процесс запущен без защиты, его дескрипторы открыты для чтения и записи, выводится полная информация о DACL и SACL. Можно делать всё что угодно - инжектить свой код в адресное пространство процесса, добавлять DACL и пользователей, которые имеют доступ к процессу, и т.д. В Windows 10 20H2 есть следующие сервисы, имеющие защиту: WinDefend (Служба антивирусной программы Microsoft Defender) - защита уровня AntimalwareLight WdNisSvc (Служба проверки сети антивирусной программы Microsoft Defender) - защита уровня AntimalwareLight wscsvc (Центр обеспечения безопасности) - защита уровня WindowsLight (в Windows 11 в доступе к этой службе отказано) WaaSMedicSvc (Служба Medic центра обновления Windows) - защита уровня WindowsLight DoSvc (Оптимизация доставки) - защита уровня WindowsLight AppIDSvc (Удостоверение приложения) - защита уровня WindowsLight AppXSvc (Служба развертывания AppX) - защита уровня WindowsLight Со всех этих сервисов спокойно снимается защита: сперва сервис останавливается (при этом автоматически уничтожается его родительский процесс), затем меняется защита, и снова запускается сервис (при этом его родительский процесс будет также без защиты). Но есть сервисы, у которых накручен кое-какой скилл. К примеру: ClipSVC (Служба лицензий клиента) - защита уровня WindowsLight Под WindowsLight сервис спокойно запускается и останавливается. Затем меняется его защита, но при попытке запуска сервиса родительский процесс сразу падает. Sense (Служба Advanced Threat Protection в Защитнике Windows) - защита уровня WindowsLight По умолчанию сервис находится в остановленном состоянии. Защита спокойно меняется. Но при попытке запуска на любом уровне защиты процесс сразу падает. sppsvc (Защита программного обеспечения) - защита уровня Windows Под Windows сервис спокойно запускается и останавливается. Затем меняется его защита, но родительский процесс всегда запускается под защитой уровня Windows вне зависимости от уровня защиты сервиса. И ещё 2 интересных сервиса: SecurityHealthService (Служба "Безопасность Windows") - защита уровня WindowsLight (в Windows 11 в доступе к этой службе отказано) SgrmBroker (Брокер мониторинга среды выполнения System Guard) - защита уровня Windows Защита спокойно меняется, но оба этих сервиса не останавливаются, выдавая сообщение ERROR_INVALID_SERVICE_CONTROL (The requested control is not valid for this service) - в их accept control банально нет флага SERVICE_CONTROL_STOP Снятие защиты с обоих сервисов и последующая перезагрузка компьютера не снимает защиту с родительских процессов. Скачать программу вы можете ЗДЕСЬ Добавлено (22.03.2022) Microsoft прикрыла данную лазейку в Windows 11 - все сервисы, имеющие любую защиту, отказывают в доступе к программе с правами СИСТЕМА. Сделано это было после того, как я опубликовал исходный код KernelExplorer. |
Всего комментариев 0
Комментарии
