Программа PsExec, контроль учетных записей и границы защищенной зоны

Около полутора лет назад я ввел в программу PsExec параметр -l, упрощающий исполнение процессов с правами обычного пользователя в контексте учетной записи администратора в среде Windows XP. В записи «Простой способ запуска программ от имени пользователя с ограниченными правами» я рассказываю, как с помощью программы PsExec, которая, в свою очередь, обращается для этого к API CreateRestrictedToken, можно создать контекст безопасности, являющийся аналогом текущей учетной записи пользователя за тем лишь исключением, что он не предусматривает членства в локальной группе администраторов и не предоставляет присущих администраторам привилегий, таких как Debug Programs (Отладка программ).  Процесс, исполняемый в таком контексте безопасности, получает привилегии и права доступа стандартной учетной записи пользователя, что не позволяет ему вносить изменения в системные файлы и разделы реестра, а также реализовывать полномочия, предоставленные только администраторам (например, загружать драйверы устройств).

Виртуальная песочница, которая создается маркером ограниченного доступа, имеет одну существенную особенность -  процессы в песочнице исполняются от имени текущей учетной записи, так что все файлы, разделы реестра и даже другие процессы, к которым текущая учетная запись имеет доступ, открыты для чтения и записи. Это обстоятельство создает серьезные бреши в стенках песочницы, за счет которых вредоносный код, написанный с учетом особенностей среды ограниченного доступа, может добиться выхода за пределы песочницы и приобретения полномочий полного администратора. Прорвать пределы песочницы для вредоносной программы не так уж сложно - достаточно при помощи функции OpenProcess обратиться к любому процессу, исполняемому вне песочницы, вставить в него код и организовать поток для его исполнения. Так как другие процессы исполняются от имени текущей учетной записи, а в рамках модели безопасности Windows этой учетной записи предоставляется полный доступ к ее собственным процессам, последние могут быть открыты процессами, исполняемыми в песочнице. Есть и другой способ - отправка оконных сообщений ограниченным процессом обычному процессу (например, проводнику), путем которой последнему передаются инструкции, замаскированные под входные данные с мыши и клавиатуры, и следовательно, код исполняется так, как это нужно для целей вредоносной программы.
Так почему же, зная об этих брешах, я тем не менее рекомендую запускать PsExec для исполнения процессов в среде Windows XP с ограниченными правами, а не с правами администратора? Дело в том, что такие песочницы используются довольно редко, поэтому авторы вредоносных программ до сих пор не озаботились написанием кода, необходимого для выхода за их пределы. Существующим вредоносным программам преодолеть стенки песочниц не удается.

С выходом ОС Windows Vista ситуация несколько изменилась. Усовершенствованный вариант такой песочницы применяется при контроле учетных записей (UAC) и при работе обозревателя Internet Explorer в защищенном режиме. Рассмотрим реализованную в ОС Windows Vista версию песочницы, разберемся с механизмом запуска программ в этой песочнице посредством обновленной версии PsExec и проанализируем связанные с этим угрозы безопасности.

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

В терминологии контроля учетных записей действие, связанное с предоставлением исполняемому файлу прав администратора, называется «повышением прав». Существует два режима повышения прав: запрос на повышение прав (осуществляется из учетной записи стандартного пользователя) и режим одобрения администратором (запускается из учетной записи администратора). Вне зависимости от режима, речь идет о создании процессов, исполняемых с правами администратора, в той же среде, в которой другие процессы исполняются с правами обычного пользователя. Так как процессы с повышенными по сравнению с обычным пользователем правами исполняются в контексте одной учетной записи, а процессы с правами обычного пользователя исполняются в другой, в модели безопасности Windows предусмотрена стенка, возводимая вокруг процессов с повышенными правами и предотвращающая вставку в такие процессы кода из процессов с обычными правами. В то же время, стандартная модель безопасности Windows не предотвращает отправку сфальсифицированных входных данных из процессов с обычными правами в процессы с повышенными правами. Более того, она не предусматривает создание песочницы вокруг процессов с обычными правами, исполняемых в контексте учетной записи администратора. Таким образом, нет никакой гарантии, что такие процессы не нарушат безопасность процессов с повышенными правами, также исполняемых в контексте учетной записи администратора. С учетом этих обстоятельств в ОС Windows Vista введен механизм обеспечения целостности Windows, который создает дополнительную защиту песочницы, окружающей процессы с низким уровнем прав.

В рамках модели обеспечения целостности, действующей в ОС Windows Vista, каждый процесс исполняется на определенном уровне целостности (integrity level, IL) и каждому защищаемому объекту также присваивается определенный уровень целостности. Существует 4 основных уровня целостности: низкий, средний (он применяется по умолчанию), высокий (для процессов с повышенным уровнем прав) и системный. Уровни целостности помогают оконной системе ограничить набор сообщений, которые процессы с относительно низким уровнем целостности могут отправлять процессам с более высоким уровнем целостности, небольшим рядом информационных оконных сообщений. Эта схема называется ограничением привилегий пользовательского интерфейса (User Interface Privilege Isolation, UIPI). Кроме того, в результате изменений, внесенных в модель безопасности ОС Windows Vista, процесс может открыть объект для доступа на запись только в том случае, если уровень целостности, присвоенный процессу, равен или превышает уровень целостности, присвоенный объекту. Для предотвращения доступа к секретам, хранящимся в памяти, процессы не могут открывать процессы с более высоким уровнем целостности даже для доступа на чтение.

 

Добавив в окно программы Process Explorer столбец Integrity Level (Уровень целостности), как показано на нижеследующем снимке экрана, вы сможете убедиться в том, что системные процессы, не исключая и процессы служб Windows, исполняются на системном уровне целостности. Большинство процессов, открытых в рамках текущего сеанса входа в систему, исполняются на среднем уровне целостности. Процессы, для которых уровень прав был явно повышен, исполняются на высоком уровне целостности, а обозреватель и Internet Explorer в защищенном режиме исполняется на низком уровне целостности. Встроенная служебная программа icacls.exe позволяет просматривать и изменять уровни целостности, присвоенные файлам и каталогам. Служебная программа AccessChk производства компании Sysinternals показывает уровень целостности файлов, каталогов, разделов реестра и процессов. По умолчанию объектам присваивается средний уровень целостности. Запустив программу AccessChk с параметром -e, можно провести поиск объектов, для которых уровень целостности задан явно.

 

Новая версия программы Psexec работает с усовершенствованным вариантом песочницы, реализованным в ОС Windows Vista, при запуске с параметром -l. При этом указанный исполняемый файл исполняется с маркером стандартного пользователя на низком уровне целостности. Песочница, которая при этом создается программой PsExec, почти идентична песочнице, окружающей обозреватель Internet Explorer в защищенном режиме. Поэкспериментировать с ограничениями, налагаемыми стенками песочницы, можно, если запустить командную строку или редактор реестра с низким уровнем целостности и выяснить, что в такой ситуации можно изменить. Я, к примеру, как видно на следующей иллюстрации, запустил с низким уровнем целостности в командной строке команду psexec -l -d cmd.exe

Для начала с помощью программы “set” я определил в рамках своего профиля временный каталог. Попытка создать в этом каталоге новый файл привела к отказу в доступе, поскольку по умолчанию каталогу был присвоен средний уровень целостности. Это подтверждается тем обстоятельством, что в выходных данных команды Icacl явно заданный уровень целостности не указан. Затем, переместившись во временный каталог обозревателя Internet Explorer, работающего в защищенном режиме с низким уровнем целостности, я, естественно, успешно создал файл.

Дальнейшие эксперименты, без сомнения, приведут вас к выводу о том, что возможности работы на низком уровне весьма ограничены. При этом существует ряд проектных ограничений, которые нужно иметь в виду. Во-первых, за исключением процессов и потоков, стенки рассматриваемой песочницы не блокируют операции чтения. К примеру, командная строка, запущенная на низком уровне целостности, равно как и обозреватель Internet Explorer, работающий в защищенном режиме, могут считывать те же объекты, что и учетная запись текущего пользователя (а если этот пользователь входит в группу администраторов, - ее версия с правами стандартного пользователя). Среди объектов, к которым не исключен доступ через стенки песочницы, следует упомянуть документы пользователя и разделы реестра.

Нет даже полной уверенности в том, что процессы с низким уровнем целостности не смогут проводить операции с объектами, которым присвоен более высокий уровень целостности. Дело в том, что процессы с разными уровнями целостности исполняются в одной настольной среде, в рамках одного и того же «сеанса». Каждое событие входа пользователя в систему приводит к организации нового сеанса, в котором исполняются процессы этого пользователя. Каждый сеанс задает локальное пространство имен, посредством которого процессы пользователя с помощью общих объектов, в том числе объектов синхронизации, а также с помощью общей памяти, могут взаимодействовать. Таким образом, процесс с низким уровнем целостности может создать объект общей памяти (называемый разделом или отображенным в памяти файлом) в расчете на то, что его откроет процесс с более высоким уровнем целостности. Данные, сохраненные в памяти процессом с более низким приоритетом, могут заставить процесс с повышенными правами в отсутствие должным образом реализованной проверки данных исполнить произвольный код. Этот метод выхода за пределы песочницы, называемый атакой с захватом семафора (squatting attack), довольно сложен. Он требует исполнения пользователем процессов в определенном порядке и знания внутренней структуры приложения, подверженного манипуляциям с помощью общих объектов.

Будем, однако, называть вещи своими именами - вне зависимости от сложности, сама возможность подобной атаки означает, что сами по себе уровни целостности не обеспечивают надежность границ защищенной зоны. Что, собственно, представляет собой граница защищенной зоны? Это стенка, через которую код и данные могут проходить только в случае авторизации политикой безопасности. В частности, граница защищенной зоны Windows пролегает между учетными записями пользователей, исполняемыми в контексте разных сеансов. Ни один пользователь не должен иметь возможность производить чтение или вносить изменения в данные другого пользователя, равно как и заставлять других пользователей исполнять произвольный код без явного на то согласия. Любая возможность обойти ограничения, налагаемые политикой безопасности, неизменно свидетельствует об ошибке в системе безопасности ОС Windows или в коде стороннего производителя.

В этом контексте очевидно, что ни повышение уровня прав посредством контроля учетных записей, ни обозреватель Internet Explorer, работающий в защищенном режиме, не создают новых границ защищенной зоны Windows. Корпорация Майкрософт неоднократно заявляла об этом, и я хочу, чтобы эта мысль была хорошо усвоена. Более того, как Джим Олчин (Allchin) отмечает в одной из записей в своем блоге, называемой «Функции безопасности и удобство», в проектном решении ОС Windows Vista соблюден определенный баланс между безопасностью и удобством. Как контроль учетных записей, так и защищенный режим обозревателя Internet Explorer спроектированы таким образом, что при необходимости в целях совместимости приложений и удобства пользователя в стенках уровня целостности могут открываться определенные пути.

 

Один из примеров баланса между безопасностью и удобством - возможность вывода диалогового окна для ввода учетных данных с целью запроса на повышение прав без ввода сочетания клавиш CTRL+ALT+DELETE. Существуют и другие подобные примеры, которые я привожу в статье на веб-узле TechEd/ITForum под названием «Внутреннее устройство контроля учетных записей UAC и влияние на вредоносные программы». В упомянутой записи Джима Олчина перечислены некоторые пути повышения уровня безопасности в ущерб удобству - в частности, настройка вывода диалогового окна для ввода учетных данных по нажатию сочетания клавиш CTRL+AL+DELETE. Исполнение процессов с правами, повышенными в режиме одобрения администратором, в контексте той же учетной записи, что и другие процессы, облегчает доступ процессов с повышенными правами к коду и данным учетной записи, что, с одной стороны, удобно, но, с другой стороны, открывает возможность для изменения этих самых данных и кода процессами с обычными правами, а значит, и для возможной загрузки произвольного кода посредством процессов с повышенными правами.  

 

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

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

В июньском выпуске журнала TechNet Magazine будет опубликована моя подробная статья о внутреннем устройстве механизма контроля учетных записей. Если вам интересны другие изменения, реализованные в ОС Windows Vista, обратитесь к первой из трех частей моей серии «Внутреннее устройство ядра ОС Windows Vista», опубликованной в  февральском выпуске журнала TechNet Magazine.