книги хакеры / журнал хакер / 203_Optimized

логики немало). А данный центр, сверяясь с базой, принимает какие-то разрешительные или запретительные решения. При этом, если избавиться от хуков, приложение перестанет работать, так как ему запрещено практически все. Иными словами, данное решение реализует в чистом виде принцип «Что не разрешено, то запрещено». Однако в таком подходе есть ряд минусов, связанных, во-пер- вых, с быстродействием (каждый перехват должен быть обработан), во-вто- рых, с совместимостью с антивирусными решениями (они не очень любят хуки, даже пользовательского режима), в-третьих, с совместимостью с программами, защищенными протекторами (там своя песня, и они тоже очень не любят хуки, иногда предательски от них избавляясь). Ну и «портянка» разрешительных правил весьма велика, что влечет за собой проблемы совместимости и быстродействия.

НЮАНС № 4, ИЛИ ПОЧЕМУ ПЛОХО ПИЛИТЬ СУК, НА КОТОРОМ СИДИШЬ

В большинстве реализаций изолируемое приложение запускается под тем же пользователем, что и неизолируемое. Для реализации изоляции недостаточно фильтровать работу с файловой системой и реестром. Надо отслеживать открытие handle’ов, работу с COM-объектами, с ALPC в целом, с окнами и много чего еще, что штатно умеет делать Windows, в частности SRM (Security Reference Monitor). По своей старой традиции производители защитных технологий решают эти задачи хуками. Мы уже подробно писали об этом выше. При этом другая защитная технология, PatchGuard, с хуками как раз борется. Впрочем, производители песочниц уже нашли решение в своем стиле, задействовав механизмы виртуализации. Там же по ссылке можно увидеть, почему это решение, мягко говоря, не очень хорошее. И именно по этой причине разработчикам зачастую непросто реализовать свою изоляцию для каждого из процессов.

Очень часто маркетологи антивирусных компаний (и не только) подают нам использование аппаратной виртуализации как некую фичу, которая кардинально увеличит безопасность. Это сейчас тренд такой, активно подогреваемый нами, системными программистами. Мы же любим большие, сложные, наукоемкие и многобюджетные проекты! Но на самом деле в большинстве случаев уход на уровень гипервизора — это побег от PatchGuard, не более того. Возможность ставить хуки безнаказанно. Во всяком случае, пока :). Ну и да, это во всех отношениях дорого, начиная с требования к железу и заканчивая дороговизной разработки. Гипервизоры писать недешево. За все платит потребитель, разумеется.

НЕМНОГО О ВСТРОЕННЫХ МЕХАНИЗМАХ БЕЗОПАСНОСТИ WINDOWS И ИЗОЛЯЦИИ ПРОЦЕССОВ С ИХ ПОМОЩЬЮ

Как мы заметили выше, на рынке крайне мало решений, которые в принципе используют встроенные механизмы безопасности Windows. То, о котором мы

Мы видим некоторую неизвестную учетную запись, имеющую SID S-1-5-5- 0-80701. Это Logon SID. Разрешения процесса для Logon SID: Query limited information, Query information, Read memory, Terminate, Synchronize, Read. Разрешения токена для Logon SID: Assign as primary token, Duplicate, Impersonate, Query, Query source and Read. Разрешения потока для Logon SID: Query limited information, Query information, Get context, Synchronize and Read.

Все это означает, что если процесс стартует под другим пользователем посредством Run As (который запускает процесс с текущим Logon SID), то в большинстве случаев поток данного процесса сможет получить токен другого процесса (целевого, запущенного под исходным пользователем), имперсонировать контекст безопасности целевого процесса и получить все права, которыми обладает целевой процесс, что будет означать выход из изоляции.

Таким образом, при анализе средства изоляции процессов нужно обращать внимание на Logon SID, с которым был запущен изолируемый процесс. Даже если процесс запущен под другим пользователем, то в случае совпадения Logon SID побег из песочницы может быть возможен.

Существует всего три документированных способа запустить процесс от имени другого пользователя:

•CreateProcessWithLogonW. На вход принимает логин и пароль, создает процесс с тем же Logon SID. Не подходит.

•CreateProcessAsUser. Создает процесс с тем же Logon SID. Не подходит.

•CreateProcessWithTokenW. Единственная подходящая функция.

Именно CreateProcessWithTokenW необходимо использовать для запуска приложений под другим пользователем. Это единственно верное решение.

КОВАРНЫЙ ДЕСКТОП И ИЗОЛЯЦИЯ

Начиная с Vista в ОС Windows появился защитный механизм UIPI (User Interface Privilege Isolation). Этот механизм регулирует обмен сообщениями между приложениями с разными уровнями доверия (Integrity levels). А теперь вспомним старушку Windows XP.

А здесь ситуация гораздо более интересная. Если UIPI включен (переменная gbEnforceUIPI равна TRUE), то проверка пользователей, под которыми запущены приложения, на эквивалентность опускается!

Иными словами, если ты запускаешь приложение под другим пользователем в Windows Vista и выше на том же рабочем столе, что и приложения других пользователей, и при этом для приложения выставлено право доступа рабочего стола DESKTOP_HOOKCONTROL, то побег из такой песочницы становится тривиальным. Право доступа рабочего стола DESKTOP_HOOKCONTROL разрешает перехватывать любые оконные сообщения и позволяет устанавливать оконные перехваты. Если отключить DESKTOP_HOOKCONTROL, то большой ряд приложений перестанет работать. Например, рантайм MS Visual Studio требует, чтобы присутствовало это право доступа. В противном случае все приложения, скомпилированные с помощью MS Visual Studio, не будут функционировать.

Решений проблемы не особо много:

1.Использовать хуки (проблема с PatchGuard и все те прелести, о которых мы говорили выше).

2.Запускать приложение с выключенным UIPI, который прибит гвоздями к UAC (User Account Control), что автоматически означает отключение UAC — одного из важнейших механизмов безопасности Windows (путь не для тех, у кого руки растут из плеч). И да, мы видели такое в одном не особо популярном решении по изоляции процессов :).

3.Запускать изолируемые приложения на отдельных рабочих столах (путь для просветленных системных программистов, познавших Истину).

То есть если песочница вообще не использует отдельных рабочих столов в процессе изоляции приложений, то дело нехорошо попахивает одним из двух первых пунктов.

Но и с отдельными рабочими столами поджидают подводные камни. Оказывается, не все приложения любят запускаться на другом рабочем столе. Некоторые особо вредные принципиально проверяют, на каком рабочем столе они запускаются. Например, Firefox может некорректно обновляться на отдельном рабочем столе, завершаясь сразу после запуска. Связано это с тем, что процесс обновления запускается явно на winsta0/default, что приводит к невозможности запуска из-за отсутствия прав доступа. Если это запатчить или запускать на текущем рабочем столе, все будет работать. К счастью, для Firefox и его форков можно отключить DESKTOP_HOOKCONTROL, что не делает необходимым запуск на отдельном рабочем столе.

Yandex-браузер (версия 13.12.1599.12987) содержит библиотеку C:\ Users\xxx\AppData\Local\Yandex\YandexBrowser\Application\30.0. 1599.12987\browser.dll. В ней где-то рядом с ChromeBrowserMainParts::PreMa inMessageLoopRunImpl есть процедура, в которой вызывается GetStartupInfo,

вырезается имя рабочего стола и сравнивается с именем рабочего стола, полученного через OpenInputDesktop, то есть, по сути, с текущим активным рабочим столом. Если не совпадает, инициализация считается проваленной, браузер завершается.

Отвлечемся от главной темы и заметим, что так сравнивать некорректно. Нельзя проверять только имя рабочего стола, надо учитывать и рабочую станцию. Более того, реальный рабочий стол может быть и вовсе не тот, что вернула GetStartupInfo. По понятной причине такой подход не дает стартовать Yandex-браузер на отдельном рабочем столе. Специалисты Yandex сказали, что это какая-то хитрая защита от прокликивания. Менять ее особо не стали с тех пор. Возможно, немного усовершенствовали. К счастью, Yandex-браузер не требует права доступа DESKTOP_HOOKCONTROL, что позволяет запускать его изолированно на текущем рабочем столе.

Таким образом, чтобы песочница была более универсальной, в ней попросту необходим некоторый набор правил для наиболее популярных приложений — уменьшить вовлеченность пользователя в волшебный мир настройки продукта под себя. Как пример, Firefox и Thunderbird приблизительно после версии 37 не будут корректно отображать окна, если в разрешениях рабочего стола не окажется DESKTOP_JOURNALRECORD и DESKTOP_JOURNALPLAYBACK. О таких мелочах песочнице желательно бы знать заранее.

ИДЕАЛЬНЫЙ МИР, ИЛИ КАКОЙ ДОЛЖНА БЫТЬ ПЕСОЧНИЦА

В результате своих исследований мы поняли, что надежная песочница должна обладать следующими свойствами:

1.С максимальной эффективностью использовать встроенные механизмы безопасности платформы, на которой она работает.

2.Уметь изолировать каждый процесс в отдельно настраиваемой изолированной среде.

3.Давать возможность регулировать доступ для каждого из процессов к объектам файловой системы и реестра, сменным носителям информации, сети, задавать привилегии и уровень доверия. То есть она должна быть максимально настраиваемой под конкретное поле применения.

4.Быть относительно легкой в использовании.

5.Журналировать свою работу. Желательно делать это в журнале ОС.

6.Не использовать хуков ядра ни при каких обстоятельствах.

7.Не ломать существующие механизмы безопасности ОС и вообще саму ОС.

8.Иметь постоянно расширяемую базу первоначальных настроек, чтобы как можно меньше вовлекать пользователя в процесс администрирования.

Все эти требования мы попытались воплотить в жизнь в тулзе под именем ReHIPS. Она абсолютно бесплатна, и поэтому можешь вполне легально ее скачать и поиграться с ней. Кто знает, быть может, удача улыбнется тебе и именно ты сможешь найти способ удрать из нашей песочницы. В любом случае ты всегда можешь прислать нам отзыв о своих впечатлениях от использования продукта, за что мы будем очень благодарны.

НУ И В КОНЦЕ

Задача изоляции процессов только на первый взгляд кажется не такой уж сложной, но на деле тут скрывается большое число подводных камней. Каждый вендор решает эту задачу по-своему, кто-то более успешно, кто-то менее. Теперь ты представляешь все слабые и проблемные места современных песочниц, поэтому, когда понадобится запустить потенциально опасное приложение, сможешь подобрать соответствующий инструмент для его изоляции от основной системы.