Чуть менее года назад я рассмотрел вопрос,
почему до Window Vista группа Power Users была во
многом практически эквивалентна группе
Administrators. Я знал, что ответ на этот вопрос
лежит в области того, что дефолтовые разрешения Window
позволяют модифицировать некоторые записи
реестра и файлы так, что члены группы легко
могут поднять свои права до Local System или
Administrators, но до тех пор у меня не было ни
одного конкретного примера. Я мог бы
вручную исследовать безопасность каждого
файла, директории и ключа реестра, но решил
написать утилиту AccessChk,
которая бы дала ответ на волнующий меня
вопрос автоматически. Программа быстро
показала мне директории, файлы, ключи и даже
службы Windows, написанные сторонними
производителями, которые члены группы Power
Users могли модифицировать и тем самым
поднять свои привилегии. Тогда я описал
свои изыскания в статье The
Power in Power Users (русскую версию статьи вы
можете найти на нашем сайте - Очень
Опытный Пользователь: повышение привилегий
до Админа).
С момента ее опубликования AccessChk завоевал
популярность как инструмент аудита,
помогающий определить слабые места с
разрешениями. Недавно я получил запрос от
группы Microsoft и других источников с просьбой
расширить ее функциональность и включить в
анализ область Object Manager (в которой хранятся
именованные мьютексы, семафоры и файлы в
памяти), Service Control Manager и именованные каналы.
Когда я переделал утилиту и добавил такую
поддержку, я запустил процедуры подобные
тем, что я проводил при написании первой статьи,
например, посмотрел, какие глобальные
объекты могут модифицировать группы Everyone и
Users. Возможность такого изменения
практически всегда означает для непривилегированного
пользователя возможность взлома других
аккаунтов, поднятие привилегий до
системных или административных,
воспрепятствование запуску программ или
сервисов системой или другими
пользователями. Например, если обычный
пользователь может изменить исполняемый
файл в директории %programfiles%, он может
заставить другого пользователя выполнить
свой произвольный код. Некоторые
приложения включают сервисы Windows, так что
если взломщик может изменить файл сервиса,
значит, он может получить системные
привилегии.
Такие локальные повышения прав или отказы
в обслуживании не существенны для
однопользовательской системы, где
пользователь и есть администратор, но во
многих случаях безопасная работа юзера
критически важна, его необходимо отделить
от других пользователей и системы -
например, на разделяемых между многими
работниками станциях, на серверах
терминалов, на компьютерах в киосках.
В моих тестах я запускал AccessChk для каждого
из поддерживаемых namespace-ов. В командах,
приведенных ниже, ключ -s означает рекурсию
namespace-ов, -w - перечислять только объекты, к
которым указанная группа - Everyone в примере -
имеет право на запись, -u - не сообщать об
ошибках в случае, если к объекту не удалось
получить доступ. Другие аргументы
указывают на область, которую следует
сканировать:
File system: accesschk everyone -wsu “%programfiles%”
File system: accesschk everyone -wsu “%systemroot%”
Registry: accesschk everyone -kwsu hklm
Processes: accesschk everyone -pwu *
Named Objects: accesschk everyone -owu \basenamedobjects
Services: accesschk everyone -cwu *
Я запустил
подобную команду для определения прав на
запись для групп Authenticated Users и Users. Программа
показала нечто типа “RW C:\Program Files\Vendor”, что
сразу же говорит о возможной дыре в
безопасности.
К моему удивлению и разочарованию, я
нашел дыры в нескольких namespace-ах. Параметры
безопасности в одном из приложений,
касающиеся синхронизации и мепинга
объектов в памяти, также как и файлов в
установочной директории, позволяли непривилегированному
пользователю выключать приложение,
изменять конфигурационные файлы, заменять
исполняемые файлы для повышения своих
привилегий до Local System. Какая же из программ
имела такие небезопасные правила
безопасности? Как бы не было иронично, но
принадлежала она одному из ведущих вендоров из
занимающихся компьютерной безопасностью.
Например, AccessChk показал, что самые обычные
пользователи имеют права на запись в
конфигурационную директорию приложения
(имя изменено):
RW C:\Program Files\SecurityVendor\Config\
RW C:\Program Files\ SecurityVendor\Config\scanmaster.db
RW C:\Program Files\ SecurityVendor\Config\realtimemaster.db
…
Так как вредоносные программы будут
запущены в группе Users, они смогут
модифицировать настройки или создать свои
собственные, могут не дать программе изменить их.
Кроме того, вирусы и трояны смогут наблюдать
за обновлениями файлов и сбрасывать их
содержание.
Для области объектов вывод программы будет похож
на этот:
RW [Section] \basenamedobjects\12345678-abcd-1234-cdef-123456789abc
RW [Mutant] \basenamedobjects\87654321-cdab-3124-efcd-6789abc12345
…
Я выполнил поиск хендлов в Process
Explorer и определил, какой процесс открыл эти
объекты, они также принадлежали этой
программе, отвечающей за безопасность.
Секции показали наличие разделяемой
памяти, так что похоже, что программный
агент, запущенный под пользователем,
использовал ее для обмена данными с
сервисом, запущенным под Local System. В данной
ситуации вредоносный софт может изменить
содержание памяти, возможно, вызвать сбой в
службе и таким образом получить
администраторские права. Как минимум же
способен манипулировать данными,
препятствуя общению.
"Мутанты" - это внутреннее имя для
мьютексов Windows (Мьютекс - одноместный семафор, служащий в программировании для синхронизации одновременно выполняющихся потоков.
Единственная задача мьютекса - защита объекта от доступа к нему других потоков (отличных от того, который завладел мьютексом). Если другому потоку будет нужен доступ к переменной, защищённой мьютексом, то этот поток просто засыпает до тех пор, пока мьютекс не будет освобождён.
Цель использования мьютексов — защита данных от повреждения.),
и в данном случае программа
использовала их для синхронизации. Это
означает, что вирусы могут перехватить
мьютекс и заблокировать выполнение службы. Я
обнаружил сразу несколько таких объектов,
открытых всем, что может привести к взлому
или выключению программы, которая как раз и
призвана обеспечивать безопасность.
В свете моего открытия я проанализировал
остальную часть моей системы, триальные
версии security-программ, игр, потребительских
программ. Ряд самых популярных в своей
категории имели проблемы, схожие с описываемой. Я
почувствовал, что обнаружил огромную гниль в
фундаменте крепкого на вид строения. Пока
наше сообщество сфокусировало свои усилия
локального повышения привилегий на
переполнении буфера или непроверяемых
параметрах, оно совершенно упустило из виду
очевидную проблему.
Почем возникают такие дыры? Я могу только
предполагать, но думаю, что они присущи
программам, написанным для Windows 9x или для
одного, административного пользователя.
Когда авторы столкнулись с разрешением
вопросов, возникающих при переходе на новые
версии Windows с лучшей безопасностью, или
возникших при запуске их программ от имени
стандартных пользователей, они пошли по
самому простейшему пути и просто выключили
безопасность.
Независимо от причин, настало время для
производителей программ - особенно
отвечающих за безопасность - заняться их
безопасностью.
Еще статьи Марка Руссиновича на
Хакере:
История неизвестного Автостарта:
http://www.xakep.ru/post/38316/default.asp
История пропавшей DLL
http://www.xakep.ru/post/36637/default.asp
Windows Defender: история одного торможения
http://www.xakep.ru/post/33974/default.asp
Руткит от Sony: история в деталях
http://www.xakep.ru/post/28597/default.asp
Очень Опытный Пользователь : повышение
привилегий до Админа:
http://www.xakep.ru/post/31825/default.asp
