Как смотреть SDDL и не ломать глаза о точки с запятыми05.03.2019 17:07

anhdtognmb0n09yu9hgh1cyducg.png

Мой путь в ИБ начался с удивительного открытия: «безопасно ≠ зашифровано». Это сейчас такое утверждение выглядит простым и очевидным, а на первом курсе осознание этого факта произвело эффект сравнимый с ментальной атомной бомбой. Информационная безопасность атаковала расширением границ предметной области: оказалось, что криптография — это только один рубеж защиты, а ещё есть юридические, организационные, да и просто физические, в конце концов. Один из теоретических аспектов гласил «Все вопросы безопасности информации описываются доступами субъектов к объектам». Заучил, нарисовал мандатную и дискреционную модели доступов, рассказал, сдал и забыл.

Я специализируюсь на анализе безопасности Windows приложений. Довольно часто изучение именно различных прав доступа занимает существенную долю исследования. Чтобы автоматизировать процесс поиска странных или неправильных прав доступа пришлось разбираться в SDDL (Security Descriptor Definition Language). Кому интересно научится читать права в форме SDDL (например что-то такое O: SYG: SYD:(A; CCLCSWLOCRRC;;; IU)(A; CCLCSWLOCRRC;;; SU)(A; CCLCSWRPWPDTLOCRRC;;; SY)(A; CCDCLCSWRPWPDTLOCRSDRCWDWO;;; BA)) и познакомится с моей утилитой для работы с дескрипторами в таком формате, добро пожаловать под кат.

SDDL формат


SDDL — это строка с описаниями прав доступа в текстовом виде. Чаще всего состоит из 3 частей: владельца, группы и прав доступа DACL. Иногда ещё добавляется часть SACL — аудиторская часть (если действия с объектом подойдут под правила SACL, то будет создано системное событие, которое легко отслеживать различными системами). Описатель выглядит так:

O: <владелец>G: <группа>D: <правила доступа DACL>S: <правила аудита SACL>

wnvgojdxtm7uz3qpq_tqwebbxuu.png

Таким образом пример выше можно разложить так:

  • O: SY
  • G: SY
  • D:(A; CCLCSWLOCRRC;;; IU)(A; CCLCSWLOCRRC;;; SU)(A; CCLCSWRPWPDTLOCRRC;;; SY)(A; CCDCLCSWRPWPDTLOCRSDRCWDWO;;; BA)


Владелец и группа может указываться как SID пользователя или группы ОС, либо как специальные сокращения. Например, в данном случае владелец и группа SY — это Local System Account (NT AUTHORITY\SYSTEM). Список сокращений (к сожалению, не исчерпывающий) можно посмотреть по ссылке.

Правила доступа состоят из перечисления флагов DACL и строк ACE (Access Control Entries). Подробный разбор ACE представлен по ссылке, мы же рассмотрим самое важное. Каждая строка ACE заключена в круглые скобки, внутри которых данные разделены символом «точки с запятой».
Наибольший интерес представляют первая, третья и последняя группы. Это тип доступа (разрешён «A», запрещён «D»), список действий и имя субъекта доступа. Первое правило DACL из примера выше: (A; CCLCSWLOCRRC;;; IU), рассмотрим подробно.

7d__o6fgbxas7azzzqmu24ou27k.png

  • «A» — правило разрешает действия субъекту;
  • «CC», «LC», «SW», «LO», «CR», «RC» — список разрешенных действий;
  • «IU» — данное сокращение означает группу Interactive Logged-on Users.


Осталось понять, что же именно разрешено. Что означают эти загадочные «CC», «LC», «SW», «LO», «CR», «RC»?

Тут нас ждёт очередной подводный камень — не всегда по сокращению можно точно указать действие. Они, так сказать, контекстозавимые. Например, если речь идёт о правах работы с сервисами, то WP — это «остановка сервиса», если о файлах, то «исполнение», а если о папках, то «траверс» (доступ к файлам в папке по имени, при отсутствии возможности перечислить содержимое). Некоторые описания есть тут, некоторые здесь, с миру по нитке.

Эй ты же так много пропустил, про DACL флаги, ACE флаги, наследование

Да, правда, это все очень важно и интересно, но встречается не так часто. Я делаю упор на массовость. В случае единичных проявлений необычных флагов проще будет разобраться в ручном режиме.


Автоматизация


Мне очень помогают утилиты Sysinternals, а именно Process Monitor и Access Check (также известные как procmon и accesschk). Первая позволяет посмотреть на обращения к файлам и реестру в реальном времени, а вторая — собрать информацию из ОС по дескрипторам безопасности.

Кстати, в самой OС окно с правами выглядит так, если кто-то не видел:

ft9tvzevuox0vy0yia5vta812k8.png

К сожалению, вывод accesschk нельзя отфильтровать, сузив запрос на права до конкретных действий. Process Monitor показывает только фактические обращения в конкретный момент и получается слишком точный запрос, на который нет прямого влияния. Кроме того, хотелось бы иметь памятку по тому, что же за группа пользователей NO или NS, и какие же действия скрываются за CC и RC.

Так и родилась несложная утилита для просмотра и фильтрации SDDL-записей.

Как пользоваться


Работать с утилитой просто, всего три этапа:

  1. Получить записи SDDL.
  2. Определить фильтры правил.
  3. Просмотреть отчёт.


lyulkdqjevgwn8iqpejwekonkia.png

Подробнее о каждом этапе.

Получение SDDL. Чтобы получить SDDL-записи можно воспользоваться встроенными в утилиту функциями (кнопки 1, 2, 3 или 4), либо загрузить полученный ранее список (кнопка 5). Обратите внимание, что запрос прав доступа производится от имени того пользователя, который запустил SDDL Viewer, поэтому в некоторых ситуациях стоит запускать программу не только от имени обычного пользователя, но и администратора. Ну и вообще само поле с SDDL строками доступно для редактирования — можно хоть вручную переписать.

Фильтрация происходит по двум параметрам: группы пользователей и права доступа. Список групп и пользователей строится на основе всех упомянутых в SDDL пользователях. Обратите внимание на чекбокс Translate SIDs (6) — если он установлен, то SID пользователей и групп по возможности будут переведены в имена относительно текущего компьютера. Список прав устроен чуть более хитро — необходимо выбрать категорию прав (если SDDL заполняется самой утилитой, то автоматически выбирается нужная категория) Кроме того в самом списке прав более ярко подсвечены те права, которые присутствуют в SDDL.

Отчёт же — просто результат расшифровки SDDL и наложения фильтров. Более подробную информацию по каждой строке можно узнать, если выбрать её в списке (да, именно с этой функцией у меня вышел затык, который дал начало небольшому исследованию внутренностей .NET).

Итоги


Исходный код доступен на github. Бинарные файлы там же в разделе Release.

Мои планы по утилите:

  1. Добавить поиск в поля ввода SDDL — всё же только фильтрации не хватает.
  2. Добавить параметры запуска, которые позволили бы строить отчёты без визуальной части.
  3. Возможно стоит добавить заполнение SDDL от процессов, общих папок и принтеров?


Буду рад услышать пожелания в комментариях.

© Habrahabr.ru