Студопедия

КАТЕГОРИИ:


Архитектура-(3434)Астрономия-(809)Биология-(7483)Биотехнологии-(1457)Военное дело-(14632)Высокие технологии-(1363)География-(913)Геология-(1438)Государство-(451)Демография-(1065)Дом-(47672)Журналистика и СМИ-(912)Изобретательство-(14524)Иностранные языки-(4268)Информатика-(17799)Искусство-(1338)История-(13644)Компьютеры-(11121)Косметика-(55)Кулинария-(373)Культура-(8427)Лингвистика-(374)Литература-(1642)Маркетинг-(23702)Математика-(16968)Машиностроение-(1700)Медицина-(12668)Менеджмент-(24684)Механика-(15423)Науковедение-(506)Образование-(11852)Охрана труда-(3308)Педагогика-(5571)Полиграфия-(1312)Политика-(7869)Право-(5454)Приборостроение-(1369)Программирование-(2801)Производство-(97182)Промышленность-(8706)Психология-(18388)Религия-(3217)Связь-(10668)Сельское хозяйство-(299)Социология-(6455)Спорт-(42831)Строительство-(4793)Торговля-(5050)Транспорт-(2929)Туризм-(1568)Физика-(3942)Философия-(17015)Финансы-(26596)Химия-(22929)Экология-(12095)Экономика-(9961)Электроника-(8441)Электротехника-(4623)Энергетика-(12629)Юриспруденция-(1492)Ядерная техника-(1748)

Целостность системы




 

Компонент User Account Control (UAC) (управление учетными записями пользователей)

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

Упрощенно механизм работы UAC можно представить в виде схемы на рисунке 8.2. При входе в систему под учетной записью администратора создаются два маркера доступа — маркер доступа обычного пользователя, с которым запускается процесс explorer.exe (от него маркер доступа наследуют все процессы, запущенные пользователем) и административный. При входе в систему под учетной записью обычного пользователя, создается только один маркер доступа.

 

Рис 8.2. Вход администратора в систему.

Операции, которые выполняет UAC при запуске приложения, представлены на рис 8.3. При запуске процесса ShellExecute() вызывает функцию CreateProcess(), которая обращается к базе данных совместимости приложений, манифесту, если он имеется и к компоненту InstallerDetection. Манифест исполняемого файла определяет, связаны ли с исполняемым файлом флаги совместимости RequireAdministrator или RunAsInvoker. База данных совместимости приложений хранит информацию о решении проблем с совместимостью приложений. InstallerDetection для 32-разрядных приложений с помощью следующих эвристик определяет, является ли исполняемый файл установщиком:

· имя файла включает в себя такие ключевые слова как "install", "setup", "update" и др;

· ключевые слова содержатся в таких полях как продавец, компания-изготовитель, имя продукта, описание файла, оригинальное имя файла, внутреннее имя и экспортное имя;

· ключевые слова содержатся в манифесте файла;

· ключевые слова в записях StringTable в исполняемом файле;

· ключевые слова в ресурсах исполняемого файла;

· определенная последовательность байт в исполняемом файле.

 

Рис 8.3. Операции, выполняемые UAC при запуске приложения.

 

Если для приложения было определено, что оно требует запуска с административными привилегиями, CreateProcess() возвращает ошибку ERROR_ELEVATION_REQUIRED, которую ожидает ShellExecute() и в случае ее появления обращается к Application Information service (AIS) с целью запуска приложения с повышенными полномочиями. AIS получает вызов от ShellExecute() и еще раз оценивает запрошенный уровень выполнения и требования групповых политик. Устанавливается, разрешено ли повышение прав и определяется их конфигурация. Если для запрошенного уровня выполнения требуется повышение полномочий, то служба выводит на экран пользователя предупреждение (определяется из групповой политики). Для этого используется дескриптор HWND, полученный от ShellExecute(). После того, как пользователь дал согласие на это действие или ввёл учётные данные, AIS затребует, если необходимо, соответствующий маркер доступа, связанный с соответствующим пользователем. AIS повторно выполняет вызов CreateProcessAsUser(), предоставляя маркер доступа администратора и указывая рабочий экран пользователя.

Для совместимости с системой приложений, написанных без учета UAC и требующих административных привилегий, используется виртуализация реестра и файлов. Виртуализация реестра предоставляется ядром системы. Виртуализованные разделы реестра включают большую часть ветви HKEY_LOCAL_MACHINE\Software, но есть и исключения, например следующие:

· HKLM\Software\Microsoft\Windows;

· HKLM\Software\Microsoft\Windows NT;

· HKLM\Software\Classes.

Виртуализуются только разделы, которые часто изменяются приложениями. ОС Windows перенаправляет операции изменения виртуализуемых разделов приложением в виртуальный корневой раздел реестра пользователя в разделе HKEY_CURRENT_USER\Software\Classes\VirtualStore. Этот раздел расположен в файле %LocalAppData%\Microsoft\Windows\UsrClass.dat, в кусте Classes пользователя. Состояние виртуализации раздела хранится в виде флага REG_KEY_DONT_VIRTUALIZE в самом разделе.

Виртуализация файлов предоставляется драйвером luafv.sys. Виртуализуются следующие области файловой системы — %ProgramFiles%, %ProgramData% и %SystemRoot%, за исключением некоторых подкаталогов. Из виртуализации исключаются файлы с некоторыми расширениями, в том числе EXE, BAT, SCR, VBS и другие. Дополнительные расширения добавляются в разделе реестра HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Luafv\Parameters\ExcludedExtensionsAdd. Изменения, производимые в виртуализованных каталогах устаревшими процессами, перенаправляются в виртуальный корневой каталог пользователя, %LocalAppData%\VirtualStore. Виртуализация не предоставляется процессам, работающим на уровне ядра, 64-разрядным процессам и процессам, осуществляющим операцию имперсонации пользователя.

Администрирование UAC осуществляется с помощью локальных политик безопасности.

 

Технология Mandatory Integrity Control (MIC) (принудительный контроль целостности)

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

Технология MIC разделяет процессы на шесть уровней целостности (Integrity Level) (IL):

· Доверенный инсталлятор. Объекты, имеющие статус доверенного инсталлятора имеют наивысший уровень доверия из возможных и могут вносить изменения в ОС.

· Системный. Объекты, имеющий данный статус, являются общими службами или объектами, которые являются частью ОС. С данным приоритетом, к примеру, запускаются учётные записи локальных или сетевых служб.

· Высокий. Учётная запись администратора запускается с высоким уровнем доверия, впрочем, как и другие учётные записи продвинутых пользователей, таких как оператор архива или оператор шифрования. Практически во всех случаях, когда код запущен с высоким уровнем доверия, он может вносить изменения в ОС.

· Средний. Это обычный уровень для стандартных учётных записей и связанных с ними данных.

· Низкий. Такой статус имеют учётная запись Everyone и временные файлы.

· Недоверенный. Такой статус присваивается анонимной и гостевой учётным записям.

IL представлены идентификаторами безопасности (Security Identification Number) (SID), которые представляют также пользователей и группы, уровень которых закодирован в относительном идентификаторе (Relative Identification Number) (RID) идентификатора SID.

Уровни целостности конфигурируются с помощью Label политик уровней целостности и политик уровней целостности маркеров доступа. Первые определяются в Label ACE и определяют как ограничивается доступ к объекту, вторые определяют как Label политики уровней целостности применяются к субъекту, представленному маркером доступа.

Уровень целостности маркера доступа, т.е. субъекта, который им представлен, определяется исходя из того, к какой группе принадлежит пользователь:

· LocalSystem, LocalService, NetworkService ¾ System;

· Administrators, Backup Operators, Network Configuration Operators, Cryptographic Operators ¾ High;

· Authenticated Users ¾ Medium;

· Everyone (World) ¾ Low;

· Anonymous ¾ Untrusted.

Уровень целостности объекта представляет Access Control Entry (ACE) нового типа, представленного в ОС Windows Vista, — Label ACE, в списке управления системным доступом (System Access Control List) (SACL) дескриптора безопасности объекта. SID в Label ACE соответствует IL объекта, а с помощью флагов ACE кодируется политика целостности объекта, это показано на рис. 8.4. Чтобы процесс мог изменить IL объекта, он должен иметь доступ "Смена владельца" (WRITE_OWNER) к объекту и IL, равный или более высокий, чем у объекта. При этом процесс может установить IL, только равный его собственному IL или ниже. Привилегия "Изменение метки объекта" (SeReLabelPrivilege) дает процессу возможность изменить IL любого объекта, к которому процесс имеет доступ, и даже установить IL выше собственного IL процесса. Однако по умолчанию эта привилегия не назначается никакой учетной записи.

Большинство объектов не имеет явного IL (обязательно IL должны иметь процессы (как объекты), потоки, маркеры доступа и задачи), поэтому к ним по умолчанию применяется средний (Medium) уровень целостности. Уровень IL, отличный от среднего, могут иметь объекты, создаваемые процессом, работающим с низким (Low) IL или исполняемый файл которых имеет низкий уровень целостности.

 

Рис. 8.4. Label ACE в SACL объекта.

 

Технология User Interface Privilege Isolation (UIPI) (изоляция привилегий пользовательского интерфейса)

Предыдущая технология все еще позволяет реализовать Shatter-атаку, например, через функцию SendMessage().

UIPI предотвращает такие атаки, запрещая процессу с низким уровнем целостности производить следующие операции по отношению к процессу с более высоким уровнем целостности:

· получения хендла окна процесса с более высокими привилегиями;

· использование функции SendMessage() или PostMessage();

· использовать thread hooks для присоединения к процессу с более высокими привилегиями;

· использовать journal hooks для мониторинга процесса с более высокими привилегиями;

· делать инъекцию DLL в процесс с более высокими привилегиями.

Однако с UIPI некоторые ресурсы пользователя остаются разделяемыми между процессами с разными уровнями целостности, к примеру, такие как буфер обмена, глобальная таблица атомов.

Ограничения UIPI можно обойти, используя атрибут безопасности приложения UIAccess, который объявляется в манифесте приложения. Но приложение, имеющее этот атрибут должно иметь цифровую подпись цепочка сертификатов которой ведет к хранилищу доверенных издателей сертификатов. Также это приложение должно быть запущено из директории %ProgramFiles% или %WinDir%, если это определено в политике UAC.

 

Технология protected processes (защищенные процессы)

Данная технология выделяет новую группу процессов — защищенные. Данная группа была создана для увеличения функциональности технических средств защиты авторских прав (Digital Rights Management (DRM)).

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

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

 

Технология Session 0 Isolation (изоляция сессии 0)

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

Сервисы работают с повышенными привилегиями. В более ранних версиях ОС Windows они запускались в той же сессии что и первый вошедший в систему пользователь, что делало их уязвимыми для атак со стороны вредоноcных приложений. В ОС Windows Vista все сервисы запускаются в сессии с номером 0, первый вошедший в систему пользователь загружается в сессию 1, второй – во вторую и т.д.

При этом могут возникнуть следующие проблемы с совместимостью приложений, написанных без учета этой технологии:

· сервисы не могут отображать какие-либо окна в пользовательской сессии, т.к. они находятся в разных рабочих столах с пользовательскими приложениями;

· сервисы не могут посылать использовать такие функции как SendMessage(), PostMessage(), т.к. разные сессии имеют разные очереди сообщений;

· если архитектура приложения предполагает, что оно находится в одной сессии с сервисом, то могут возникнуть проблемы с совместимостью. Например, сервис из сессии 0 создает какой-то объект в \BaseNamedObjects, а приложение из другой сессии открывает его. По умолчанию, если в пути к объекту не указано никаких префиксов, к пути к объекту дописывается префикс \Local, который в сессии 0 является пустой строкой, а в остальных сессиях — Sessions\< n >, где n — номер сессии. Т.е. в действительности будет открыт объект не из \BaseNamedObjects, а из Sessions\< n >\BaseNamedObjects, которого там не будет. Поэтому при открытии или создании объектов из сессии 0 нужно использовать префикс Global\. Данные проблемы решаются использованием RPC или таких функций как WTSSendMessage(), CreateProcessAsUser().

 

Контрольные вопросы

1. Какие компоненты отвечают в Windows за целостность утра?

2. Как работает UAC?

3. Для чего используется уровень целостности маркера доступа?

4. Как выполняется изоляция сессии 0?

5. Какие процессы в Windows являются защищенными?


Лекция 9.

ЗАЩИТА СЕРВЕРНЫХ СЛУЖБ WINDOWS




Поделиться с друзьями:


Дата добавления: 2014-12-07; Просмотров: 820; Нарушение авторских прав?; Мы поможем в написании вашей работы!


Нам важно ваше мнение! Был ли полезен опубликованный материал? Да | Нет



studopedia.su - Студопедия (2013 - 2024) год. Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав! Последнее добавление




Генерация страницы за: 0.042 сек.