Дело о небезопасных средствах безопасности
Чуть больше года назад я озаботился прояснением вопроса о том, почему до появления ОС Windows Vista группа безопасности «Опытные пользователи» повсеместно считалась практически эквивалентом группы администраторов. Утверждалось, что разрешения, присваиваемые этой группе по умолчанию, позволяли вносить изменения в ряд разделов реестра и файлов, что, в свою очередь, помогало участникам группы повышать права до уровня системной учетной записи или группы администраторов. В то же время, конкретных примеров мне известно не было. Можно было, конечно, вручную проверить защиту всех значимых файлов, каталогов и разделов реестра, но для автоматического решения этой и подобных задач я решил написать служебную программу AccessChk. Программа AccessChk умеет выводить списки каталогов, файлов, разделов реестра и даже служб Windows, созданных сторонними разработчиками, которые участники группы «Опытные пользователи» могут изменить в целях повышения уровня своих прав. Мои выводы по этому вопросу изложены в записи «Опыты над опытными пользователями».
С момента её опубликования программа AccessChk утвердилась в роли популярного инструмента аудита безопасности систем, способствующего выявлению небезопасных разрешений. В последнее время от самых разных людей, как работающих в корпорации Майкрософт, так и от сторонних наблюдателей, поступали просьбы реализовать в программе AccessChk проверку объектов, входящих в пространство имен диспетчера объектов (к которому относятся именованные объекты взаимного исключения, семафоры и отображаемые в памяти файлы), диспетчера служб и именованных каналов.
Работая над реализацией этой функциональности, я еще раз выполнил некоторые запросы, фигурирующие в упомянутой записи - в частности, позволяющие установить, к каким глобальным системным объектам группы «Все» и «Пользователи» имеют доступ на запись. Способность вносить изменения в эти объекты почти всегда свидетельствует о том, что обычные пользователи могут повысить уровень своих прав до системного или административного, а равно и помешать нормальному функционированию служб и программ, исполняемых системой или другими пользователями. К примеру, если обычный пользователь способен вносить изменения в исполняемые файлы, размещенные в каталоге %programfiles%, то он при желании сможет спровоцировать исполнение произвольного кода другим пользователем. В состав некоторых приложений входят службы Windows, и если пользователь сможет внести изменения в исполняемый файл такой службы, то ему под силу получить права системного уровня.
Подобные уязвимости, имеющие потенциал повышения прав в локальной системе и отказов в обслуживании, несущественны в условиях однопользовательских систем, где единственный пользователь является администратором. Иная ситуация складывается в системах, где пользователь рассчитывает на безопасность, работая на обычном уровне прав (как в ОС Windows Vista), на общих компьютерах, в том числе семейных, где имеются обычные учетные записи, на серверах терминалов и в компьютерах-киосках - здесь повышение прав влечет за собой нарушение границ защищенной зоны, которая организуется операционной системой для разграничения обычных пользователей по отношению друг к другу и к системе.
В ходе тестирования мне пришлось выполнить команды AccessChk, чтобы провести проверку на предмет потенциальных угроз безопасности в поддерживаемых программой пространствах имен. Стоит разъяснить параметры приведенных ниже команд: -s заставляет программу AccessChk выполнить рекурсивную обработку пространства имен, -w ограничивает список выводимых объектов теми, в отношении которых указанная группа (в данном случае группа «Все») имеет доступ на запись, а -u запрещает вывод сообщений об ошибках при неудачных попытках обращения к объектам, к которым текущая учетная запись не предусматривает возможности доступа. Остальные параметры определяют пространство имен для анализа, а по умолчанию сканируется файловая система.
Файловая система: accesschk everyone -wsu “%programfiles%”
Файловая система: accesschk everyone -wsu “%systemroot%”
Реестр: accesschk everyone -kwsu hklm
Процессы: accesschk everyone -pwu *
Именованные объекты: accesschk everyone -owu \basenamedobjects
Службы: accesschk everyone -cwu *
Аналогичные команды в поиске прав доступа на запись я выполнил в отношении групп «Прошедшие проверку» и «Пользователи». Одна из строк отчета, “RW C:\Program Files\Vendor”, демонстрирует изъян в системе безопасности.
К моему удивлению и ужасу, бреши в системе безопасности обнаружились в нескольких пространствах имен. Параметры безопасности глобальных объектов синхронизации и отображения в память, а также каталога установки одного из проверенных приложений позволяют обычным пользователям остановить это приложение, повредить его файлы конфигурации и заменить исполняемые файлы, тем самым повысив права до системного уровня. Какое же приложение, спросите вы, так откровенно создает проблемы в сфере безопасности? Забавно, но это продукт одного из ведущих производителей средств защиты.
Помимо прочего, проверка программой AccessChk показала, что группа «Пользователи» имеет доступ на запись к каталогу конфигурации приложения (имя приложения изменено).
RW C:\Program Files\SecurityVendor\Config\
RW C:\Program Files\ SecurityVendor\Config\scanmaster.db
RW C:\Program Files\ SecurityVendor\Config\realtimemaster.db
…
Поскольку вредоносные программы часто исполняются с правами группы «Пользователи», им не составит труда внести изменения в данные конфигурации или создать собственную версию конфигурации, не позволив приложению восстановить старый вариант. Кроме того, они могут отслеживать сеансы динамического обновления файлов и удалять их содержимое.
Строки отчета о проверки пространства имен объектов выглядят так:
RW [Section] \basenamedobjects\12345678-abcd-1234-cdef-123456789abc
RW [Mutant] \basenamedobjects\87654321-cdab-3124-efcd-6789abc12345
…
С помощью поиска по дескрипторам в программе Process Explorer я попытался узнать, какими процессами эти объекты были открыты, и выяснилось, что это процессы все того же защитного ПО. По всей видимости, агент безопасности, работающий в рамках сеансов входа пользователей, через общую память передавал данные служебному процессу защитного ПО, исполняемому в контексте системной учетной записи. Вредоносные программы в таких условиях могут изменить содержимое памяти, а возможно, и спровоцировать ошибку службы, попытавшись таким образом заполучить права администратора. Как минимум, они могут подменять данные, которыми обмениваются агент и служебный процесс.
“Mutant” - это внутреннее имя объектов взаимного исключения Windows, которые служба защитного ПО задействовала для синхронизации. Следовательно, вредоносная программа могла бы захватить объект взаимного исключения и заблокировать дальнейшее исполнение службы. Мне удалось найти немало незащищенных объектов, посредством которых защитное ПО может быть отключено или взломано.
Памятуя о такой находке, я проанализировал остальные свои системы, а вместе с ними и ознакомительные версии других распространенных защитных, пользовательских и предоставляемых поставщиками услуг Интернета приложений, а также игр. В каждой из этих категорий оказались приложения с аналогичными проблемами. Сложилось такое впечатление, что я исследую фундамент здания, считавшегося прочным, и обнаруживаю в нем прогнившие стыки. Сообщество специалистов по безопасности объединило усилия в борьбе с методиками локального повышения прав через переполнение буфера и непроверенные параметры, но, увы, совершенно забыло об очевидных проблемах, которые зачастую создают продукты независимых поставщиков защитного ПО, а иногда и их собственные приложения.
Почему же в системе безопасности появляются такие бреши? Не могу говорить с уверенностью, но для предоставления группам с обычным уровнем прав доступа на запись к глобальным объектам требуется явное переопределение параметров безопасности по умолчанию, а это сплошь и рядом встречается в программах, которые первоначально разрабатывались для ОС Windows 9x или в расчете на системы с одним пользователем-администратором. Видимо, столкнувшись с трудностями, связанными с поддержкой версий ОС Windows с расширенными средствами защиты, а также со сценарием, в котором программы запускаются в контексте учетной записи обычного пользователя, разработчики таких программ пошли по пути наименьшего сопротивления и фактически свели средства защиты на нет.
Из каких бы соображений они ни исходили, производителям ПО, особенно инструментов защиты, самое время всерьез озаботиться защитой своих продуктов. Если вам случится обнаружить в своей системе незащищенное приложение, пожалуйста, сообщите об ошибке его производителю. Если же вы разработчик ПО, старайтесь следовать принципам, изложенным в книге "Writing Secure Code” (Безопасный код) Майкла Говарда (Michael Howard) и Дэвида Леблана (David LeBlanc).