10.05.2010

Безопасность в Active Directory

Часто при проектировании логической структуры Active Directory возникает вопрос, какую модель выбрать, чтобы она была более безопасной, более надежной и в тоже время более выгодной и управляемой.

Ефимов Геннадий

Вступление.

Часто при проектировании логической структуры Active Directory возникает вопрос, какую модель выбрать, чтобы она была более безопасной, более надежной и в тоже время более выгодной и управляемой.

Не секрет, что отдельный домен в лесу не является изолированной единицей и что полномочный администратор из корневого домена леса может получить доступ к любым единицам данных в лесу. Также любой администратор домена не из корневого домена леса может получить доступ к другим доменам. Это описано во многих руководствах Microsoft. Вот отрывок из руководства по разработке архитектуры службы каталога (Designing and Deploying Directory and Security Services):

Because a domain is not a security boundary, it is possible for a malicious service administrator, such as a member of the Domain Admins group, to use nonstandard tools and procedures to gain full access to any domain in the forest or to any computer in the forest. For example, service administrators in a nonroot domain can make themselves members of the Enterprise Admins or Schema Admins group.

Я достаточно долго пытался найти такие утилиты в Интернете, но так и не нашел.

Далее попробуем обсудить различные логические модели доменов/лесов и рассмотрим получение полномочий в этих самых доменах и лесах.

Получение полномочий.

Есть определенный набор утилит, который позволяет мигрировать учетные записи участников безопасности между доменами/лесами с сохранением SID исходного домена в SIDHistory объекта целевого домена. Вот некоторые из них: ADMT, sidhist.vbs, sidewalk.exe. Две последние утилиты из набора Support Tools. Как же работают эти утилиты/скрипты? Все они используют функцию DsAddSidHistory из библиотеки Ntdsapi.dll. Функция документированная. Использование ее достаточно простое, как-то так (код на Delphi):

if DsBind('\\targetdc.target.com','target.com', @hDs) = 0 then
if DsAddSidHistory(hDs, 0, 'source.com', 'SampleUser04', nil, nil, 'target.com', 'SampleUser03') = 0 then

Функция описана здесь - http://msdn.microsoft.com/en-us/library/ms675918(VS.85).aspx

Но выполнение данной функции налагает определенные ограничения, в частности должны быть выполнены следующие условия:

  1. административные права в домене источнике;
  2. права на добавление SidHistory в целевом домене;
  3. на PDC в исходном домене в реестре должен быть ключ TCPIPClientSupport:DWORD=1;
  4. должна быть создана локальная группа в целевом домене – <SourceNETBIOSDomainName>$$$;
  5. в целевом домене должен быть включен аудит управления учетными записями (Account Management – Success/Failure).

Миграция SID допускается между учетными записями с well-known rid учетными записями (это записи у которых относительный идентификатор во всех доменах одинаковый, но sid домена отличается), например Domain Admins (S-15-21-SidДомена-512). Но нужно соблюсти весь этот список условий (первый уже говорит о бесполезности попыток получения каких-то полномочий, они уже есть).

Попробуем взглянуть на архитектуру Active Directory:

Из схемы приведенной выше (взята из статьи Technical Reference Active Directory Collection, Data Store) видно, что сама база данных AD, а точнее база данных ESE, надежно защищена уровнем DSA. DSA реализует набор интерфейсов и функций для доступа к непосредственно данным, которые находятся в ntds.dit. Ну соответственно он пресекает любые попытки смухлевать.
Зачем стучаться в закрытую дверь, влезем через открытую форточку. :)

Обратимся напрямую к уровню ESE.

Extensible Storage Engine (ESE) – это механизм доступа к данным с использованием индексно-последовательного метода доступа (ISAM). Многие приложения/серверы Windows используют данный механизм для хранения и обработки данных, например DHCP, WINS, AD, Exchange (по-моему, используется какая-то особая версия ESE). Интерфейсы/функции ESE документированы и достаточно хорошо описаны. Подробнее http://msdn.microsoft.com/en-us/library/ms684493(EXCHG.10).aspx.

Открыв ntds.dit обнаружилось небольшое количество таблиц (7): datatable, hiddentable, link_table, quota_rebuild_progress_table, quota_table, sdproptable, sd_table.

Нас интересует таблица datatable. Таблица состоит из множества атрибутов (столбцов), которые соответствуют атрибутам, определенным в схеме AD. Получается, что на уровне ESE у каждого объекта (а объектами являются картежи этой таблицы) есть все атрибуты AD. В этой таблице находятся все объекты AD. По названию других таблиц не трудно догадаться, что там хранится. Атрибуты (большая часть из них) именуются следующим образом: ATTb589856, ATTj589855 и так далее. Что означают цифры в именах и как они связаны с атрибутами в схеме AD выяснить не удалось, может кто-нибудь подскажет :).

Получив список индексов для данной таблици был обнаружен индекс с именем nc_guid_Index, созданный по столбцам NCDNT_col:Long,ATTk589826:LongBinary. Поскольку объекты в Active Directory имеют уникальные object-GUID, этот индекс нам особенно полезен, по нему мы с легкостью определяем, что атрибут ATTk589826 это как раз Object-GUID. Будем использовать данный атрибут для поиска объектов в таблице.

Следующий интересный индекс - NC_Acc_Type_Sid - NCDNT_col:Long,ATTj590126:Long,ATTr589970:LongBinary. Не трудно догадаться, что ATTr589970 это SID объекта. Он конечно полезен для нас, но нас больше интересует SidHistory. Вот тут не получилось найти интуитивно-понятного индекса. Пришлось перебрать значения всех столбцов с типом LongBinary. Методом перебора выяснилось, что SidHistory это атрибут ATTr590433.

Собственно все, что нам нужно есть, осталось только прописать необходимые данные.

Пошагово опишу процесс:

  1. Изменяем глобальные данные нашего будущего экземпляра ESE. Поскольку по умолчанию размер страницы в ESE – 4КБ, а AD использует 8КБ страницы, нужно поменять глобальные настройки.
  2. Создаем экземпляр.
  3. Инициализируем.
  4. Создаем сессию.
  5. Аттачим базу, заем ее открывает базу.
  6. Открываем таблицу datatable.
  7. Устанавливаем текущий индекс INDEX_00090002 (это отдельный индекс для атрибута ATTr590433).
  8. Создаем ключ для поиска, указываем в качестве критерия поиска GUID искомого объекта.
  9. Осуществляем поиск.
  10. В транзакции обновляем столбец ATTr590433, записывая в него необходимые SID’ы.
  11. Закрываем БД, сессию, завершаем экземпляр ESE.

Вот вроде и все.

Испытания.

Теперь попробуем обсудить использование данного метода на различных моделях доменов/лесов Active Directory.

Один домен без RODC.

Если у пользователя (необязательно это должен быть администратор) есть физический доступ к контроллеру домена, то он может себе прописать SidHistory, используя способ описанный выше.

Единственное что замечено, контроллер домена очень трепетно относится к учетной записи Administrator (S-1-5-21-….-500), если добавить этот SID, то прав ни каких не будет. Нужно прописывать Domain Admins/Enterprise Admins.

Плюс еще есть много способов повышение себе полномочий имея физический доступ к контроллеру, например использование rootkitов, или например использование srvany + erd commander.

Домены с RODC.

RODC является Read-only только на уровне DSA. То есть ни что не мешает нам, воспользовавшись описанным методом, прописать себе SID полномочного пользователя. И вот мы прописали себе SID в SIDHistory, аутентифицировались у этого контроллера, получили маркер доступа, все замечательно – есть в нем необходимый SID. Но такой маркер будет получен только на подвластные RODC-контроллеру серверы/службы. Если же у RODC нет долгосрочного ключа для какой-то службы, то нам приходится обращаться к «полноценному» контроллеру домена. У того в свою очередь нет данных о том, что у нас в SIDHistory прописан супер-пупер SID. Более того RODC и «нормальные» контроллеры домена судя по всему используют разные долгосрочные ключи (об этом говорит несколько учеток krbtgt) для шифрования TGT. Соответственно «нормальный» контроллер домена выдаст нам TGT с SIDHistory без полномочного SID, мы его дадим TGS для получения Service Ticket, TGS скопирует набор SID из TGT, передаст Service Ticket нам, мы его предоставим той или иной службе, она создаст на его основе маркер. В этом маркере не будет необходимого нам SIDа, соответственно никаких полномочий мы не получим.

Долгосрочного ключа для служб на «нормальном» контроллере домена (например, службы LDAP, CIFS) у RODC нет, стандартными средствами не удается его направить на RODC, поэтому никаких полномочий в лесу мы не получим.
Вот если бы попробовать реплицировать данные из базы RODC на записываемый контроллер домена, тогда бы все получилось. Входящих соединений для репликации от RODC нет, ни в Configuration, ни в repsFrom. Но мне кажется RODC, как-то все равно в обратную сторону реплицируется. На этот вопрос пока нет ответа.

Ресурсный домен.

Здесь все тоже самое, как и с одним доменом без RODC. Получаем физический доступ к контроллеру домена, производим манипуляции описанные выше. Единственно не получится использовать rootkit’ы и srvany + erd commander. В этом плане конечно модель с использованием ресурсных доменов является более защищенной.

Домены из различных лесов.

Мы можем прописать себе в SIDHistory SID полномочной учетной записи из другого леса. Если у нас созданы доверительные отношения между доменами/лесами, так что исходный домен доверяет целевому домену, а значит может нас аутентифицировать и если фильтрация SidHistory отключена на этом доверии, то мы можем получить определенные права на исходный лес/домен.
Если фильтрация SIDHistory отключена (по умолчанию), то прописывание SID в SIDHistory ничего нам не даст. Можно конечно прописать себе в качестве основного SIDа SID Enterprise Adminа из домена источника (а можно даже несколько SIDов основных прописать), но это ничего не даст.

При прописывании несколько основных SID вываливается ошибка “Internal Error” и аутентификация не проходит. При прописывании в качестве основного SID SID из другого домена, контроллер домена считает эту учетку неродной и аутентификация также не происходит.

Итоги.

Наиболее защищенной показала себя модель с использованием RODC (хотя какие-либо права можно получить на подвластные RODC-серверы).

Использование отдельных лесов предоставляет изоляцию ресурсов (особенно если включена фильтрация SIDHistory) и является одним из наиболее надежных средств обеспечения безопасности, но является более ресурсоемкой и затратной затеей.

Использование модели с ресурсными доменами или единственным корневым доменом леса является небезопасным. Изоляция данных и служб не происходит. Как правило, это основные модели проектирования AD.

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

Инструментальное средство.

Кульминация статьи :). Собственно утилита, которая позволяет в оффлайн режиме прописывать себе SID в SIDHistory. Без параметров отображается.

Требует наличия установленного на компьютере .Net Framework 2.0. Необходимо запускать на той версии Windows под которой работает AD (из-за различий в версиях ESE).

http://download.securitylab.ru/_tools/ESEAddSidHistory.zip
MD5: F5489294F66769CAF09CACDA61B26426  ESEAddSidHistory.zip

или введите имя

CAPTCHA
Страницы: 1  2  
Js!
11-05-2010 06:32:07
Если у пользователя... ...есть физический доступ к контроллеру домена, то Совершенно не нужно извращаться вышеприведенным способом. Хотя, программка интересная
0 |
11-05-2010 14:35:01
Физическая доступность серверов?.... проще поставить клавиатурный кейлоггер, и снять админский пароль.
0 |
автор
14-05-2010 09:01:52
можно конечно, но при этом еще нужно заманить ентерпрайс админа или админа корневого домена на этот контроллер.. в этой статье рассказывается про подходы проектирования моделей лесов Active Directory... описываются плюсы и минусы тех или иных моделей...
0 |
Проходящий мимо
13-05-2010 16:08:17
[I]For example, service administrators in a nonroot domain can make themselves members of the Enterprise Admins or Schema Admins group.[/I] Я достаточно долго пытался найти такие утилиты в Интернете, но так и не нашел. Зачем что-то искать? Английским по-белому написано "доменный админ может сделать себя админом схемы или энтерпрайзным админом". Никаких хитрых утилит искать не надо. Плюс еще есть много способов повышение себе полномочий имея физический доступ к контроллеру... p.s. Автор, тебе не кажется что ты перегибаешь палку с подменой сидов?
0 |
автор
14-05-2010 09:05:58
да, конечно есть и другие способы получения эксклюзивных полномочий в лесу без низкоуровневого редактирования базы ntds.dit это один из способов, относительно непростой. на этих техниках можно построить другие сценарии работы с ad.. организация бэкдуров ну и другие. опять же рассказаны способы получения полномочий даже при физическом доступе к RODC.
0 |
проходящий мимо
14-05-2010 12:02:32
насчет RODC - да, интересный вариант повышения привелегий.
0 |
Konstantin Leontiev
18-05-2010 23:17:34
Геннадий, хорошая проделана работа. Но как всегда, есть к чему стремиться и посему мои комментарии: 1) Я бы посоветовал немного повнимательнее следить за языком изложения и за понятностью/восприимчивостью материала читателем. 2) Старайтесь избегать рассуждений типа: очевидно, что «...». Вам это может быть очевидно, а читателю нет. 3) Вы по сути частично (примерно на 10%) повторили работу внутренней утилиты Microsoft под названием Stealth, которая позволяет ходить по базам Jet и в частности ESE. Это похвально. Я бы объяснил как формируются имена атрибутов, но к сожалению NDA не позволяет. 4) Для защиты от физической атаки на DC можно воспользоваться либо утилитой SYSKEY, либо (а можно и вместе) воспользоваться BitLocker (без TPM, т.к. TPM по Российскому законодательству нельзя импортировать). Это довольно надежно ограничит ваши возможности по чтению и модификации БД ntds.dit.
0 |
Konstantin Leontiev
18-05-2010 23:18:24
5) При анализе структуры таблиц и данных советую присмотреться к структуре дампов AD. Не обязательно пользоваться такой сложной логикой поиска по GUID-ам. Дампы по нужным наборам атрибутов можно сделать очень просто: http://msdn.microsoft.com/en-us/library/cc223318(PROT.13).aspx 6) Наконец, обратите внимание еще на одну интересную атаку на AD и ее протоколы аутентификации – Path-The-Hash, которую можно, например, выполнить используя элементарно пропатченый клиент SAMBA или Kerberos. Но для этого опять же нужно украсть ntds.dit. 7) У вас в рассуждениях о фильтрации SID-History на трастах между доменами есть опечатки (скорее ошибки). Обратите внимание на один момент: на трастах внутри леса фильтрация SID-History По-умолчанию выключена, а между лесами включена. Так же на забывайте про весьма эффективный механизм selective authentication возможный на трастах между лесами.
0 |
Автор
20-05-2010 09:33:53
Рассуждение о SID-History идет в контексте разных лесов.. Да верно ошибка с двойным отрицанием.. Конечно же фильтрация SidHistory включена (по умолчанию)...
0 |
Страницы: 1  2