Мой путь в ИБ начался с удивительного открытия: «безопасно ≠ зашифровано». Это сейчас такое утверждение выглядит простым и очевидным, а на первом курсе осознание этого факта произвело эффект сравнимый с ментальной атомной бомбой. Информационная безопасность атаковала расширением границ предметной области: оказалось, что криптография — это только один рубеж защиты, а ещё есть юридические, организационные, да и просто физические, в конце концов. Один из теоретических аспектов гласил «Все вопросы безопасности информации описываются доступами субъектов к объектам». Заучил, нарисовал мандатную и дискреционную модели доступов, рассказал, сдал и забыл.
Я специализируюсь на анализе безопасности 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>
Таким образом пример выше можно разложить так:
- O:SY
- G:SY
- D:(A;;CCLCSWLOCRRC;;;IU)(A;;CCLCSWLOCRRC;;;SU)(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)
Владелец и группа может указываться как SID пользователя или группы ОС, либо как специальные сокращения. Например, в данном случае владелец и группа SY — это Local System Account (NT AUTHORITYSYSTEM). Список сокращений (к сожалению, не исчерпывающий) можно посмотреть по ссылке.
Правила доступа состоят из перечисления флагов DACL и строк ACE (Access Control Entries). Подробный разбор ACE представлен по ссылке, мы же рассмотрим самое важное. Каждая строка ACE заключена в круглые скобки, внутри которых данные разделены символом «точки с запятой».
Наибольший интерес представляют первая, третья и последняя группы. Это тип доступа (разрешён «A», запрещён «D»), список действий и имя субъекта доступа. Первое правило DACL из примера выше: (A;;CCLCSWLOCRRC;;;IU), рассмотрим подробно.
- «A» — правило разрешает действия субъекту;
- «CC», «LC», «SW», «LO», «CR», «RC» — список разрешенных действий;
- «IU» — данное сокращение означает группу Interactive Logged-on Users.
Осталось понять, что же именно разрешено. Что означают эти загадочные «CC», «LC», «SW», «LO», «CR», «RC»?
Тут нас ждёт очередной подводный камень — не всегда по сокращению можно точно указать действие. Они, так сказать, контекстозавимые. Например, если речь идёт о правах работы с сервисами, то WP — это «остановка сервиса», если о файлах, то «исполнение», а если о папках, то «траверс» (доступ к файлам в папке по имени, при отсутствии возможности перечислить содержимое). Некоторые описания есть тут, некоторые здесь, с миру по нитке.
Автоматизация
Мне очень помогают утилиты Sysinternals, а именно Process Monitor и Access Check (также известные как procmon и accesschk). Первая позволяет посмотреть на обращения к файлам и реестру в реальном времени, а вторая — собрать информацию из ОС по дескрипторам безопасности.
Кстати, в самой OС окно с правами выглядит так, если кто-то не видел:
К сожалению, вывод accesschk нельзя отфильтровать, сузив запрос на права до конкретных действий. Process Monitor показывает только фактические обращения в конкретный момент и получается слишком точный запрос, на который нет прямого влияния. Кроме того, хотелось бы иметь памятку по тому, что же за группа пользователей NO или NS, и какие же действия скрываются за CC и RC.
Так и родилась несложная утилита для просмотра и фильтрации SDDL-записей.
Как пользоваться
Работать с утилитой просто, всего три этапа:
- Получить записи SDDL.
- Определить фильтры правил.
- Просмотреть отчёт.
Подробнее о каждом этапе.
Получение SDDL. Чтобы получить SDDL-записи можно воспользоваться встроенными в утилиту функциями (кнопки 1, 2, 3 или 4), либо загрузить полученный ранее список (кнопка 5). Обратите внимание, что запрос прав доступа производится от имени того пользователя, который запустил SDDL Viewer, поэтому в некоторых ситуациях стоит запускать программу не только от имени обычного пользователя, но и администратора. Ну и вообще само поле с SDDL строками доступно для редактирования — можно хоть вручную переписать.
Фильтрация происходит по двум параметрам: группы пользователей и права доступа. Список групп и пользователей строится на основе всех упомянутых в SDDL пользователях. Обратите внимание на чекбокс Translate SIDs (6) — если он установлен, то SID пользователей и групп по возможности будут переведены в имена относительно текущего компьютера. Список прав устроен чуть более хитро — необходимо выбрать категорию прав (если SDDL заполняется самой утилитой, то автоматически выбирается нужная категория) Кроме того в самом списке прав более ярко подсвечены те права, которые присутствуют в SDDL.
Отчёт же — просто результат расшифровки SDDL и наложения фильтров. Более подробную информацию по каждой строке можно узнать, если выбрать её в списке (да, именно с этой функцией у меня вышел затык, который дал начало небольшому исследованию внутренностей .NET).
Итоги
Исходный код доступен на github. Бинарные файлы там же в разделе Release.
Мои планы по утилите:
- Добавить поиск в поля ввода SDDL — всё же только фильтрации не хватает.
- Добавить параметры запуска, которые позволили бы строить отчёты без визуальной части.
- Возможно стоит добавить заполнение SDDL от процессов, общих папок и принтеров?
Буду рад услышать пожелания в комментариях.
Автор: Кравец Василий
