Исследование Active Directory — HackZona.Ru
Исследование Active Directory
Исследование Active Directory
Тип статьи:
Со старой ХакЗоны.
Источник:
Учетные записи пользователей и их пароли в каком-то виде хранятся в Active Directory — каталоге данных безопасности домена.
Администраторы домена имеют право сменить пароль пользователя, не зная старого — узнать пароль пользователя не могут даже они. Не могут узнать пароль потому что, как утверждают разработчики Windows 2000 пароль в виде, в котором его набирает пользователь в Active Directory не хранится. Существуют математически обоснованные алгоритмы преобразований, для которых не существует обратных. Если пользователь устанавливает пароль '[email protected]' с помощью такого алгоритма получается какое-то число(hash — хэш), например 0x897dad79be453adfd, при этом вероятность получения из другого пароля такого же числа около нуля. Гарантируется также, что получить из числа 0x897dad79be453adfd снова пароль невозможно. При попытке войти в систему с паролем 'password' система преобразует его с помощью той же функции в число — 0x243052bde34097adafa23d267. Сравнивает полученное число с хранящимся в Active Directory — они не совпадают — пароль не верен. Взлом такой системы возможен — если все-таки найдется преобразование, обратное заданное, в противном случае используется только (brute-force attack) — атака перебором.
Помимо этого в домене Windows 2000 существует возможность включить для пользователя обратимое шифрование пароля, цитируя другие источники:
Создатели операционной системы Windows 2000 предлагают новую учетную политику Store password using reversible encryption for all users in the domain. В соответствии с этой политикой, пароли пользователей хранятся в AD в текстовом виде, так что любой желающий может отыскать их и прочесть.
Политика ослабляет безопасность сети и применятся в ряде случаев. В частности, её необходимо использовать при удаленном подключении пользователей к RAS (Remote Access Server — Серверу удаленного доступа) с использованием протокола проверки подлинности CHAP(Challenge HAndshake Protocol). Согласно спецификации протокола — пароль передается не в открытом виде, а в зашифрованном, причем применяется алгоритм MD5. Стандартными же методами шифрования в среде Windows являются: NTLM или OWF, с их помощью зашифрованные пароли как раз и хранятся Active Directory. MD5 также алгоритм необратимого шифрования, но пароли в таком виде в Active Directory не хранятся. Для проверки его правильности на стороне сервера приходится применять такое же преобразование (MD5) к исходному паролю пользователя(незашифрованному) и сравнивать полученные результаты. Наверное, разработчики могли бы добавить к хранимым в AD паролям, зашифрованный еще по одному алгоритму(MD5), но так как применяется такая проверка подлинности далеко не в каждом домене, вносить в AD еще один атрибут посчитали нецелесообразным. Кроме этого существуют (или могут появиться) другие методы необратимого шифрования. Целью исследования является получение паролей пользователей домена Windows 2000, зашифрованных обратимым образом.
Исследование
А теперь собственно о том, как получить пароль пользователя, если для его учетной записи определена политика: «Хранить пароли, используя обратимое шифрование». Изучим как реализовано хранение паролей и признака обратимого шифрования.
Пароли, зашифрованные с помощью алгоритмов NTLM (NT Lan Manager) и OWF (One-Way Format) хранятся в атрибутах пользователя: DBCS-Pwd (пароль учетной записи Lan Manager) и Unicode-Pwd (пароль пользователя, преобразованный в формат OWF).
Замечание. Хранение паролей в формате NTLM также ослабляет безопасность сети есть возможность его отключить, создав параметр NoLMHash в разделе HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsa.
Признак обратимого шифрования определяется битом 0x80 в атрибуте User-Account-Control (в lmaccess.h: #define UF_ENCRYPTED_TEXT_PASSWORD_ALLOWED 0x0080). Попытаемся прочитать атрибуты DBCS-Pwd и Unicode-Pwd возможно в них находится пароль в открытом виде, если установлен бит ENCRYPTED_TEXT_PASSWORD_ALLOWED.
В базе знаний Microsoft встречается следующее утверждение: The password attribute used by Active Directory is «unicodePwd.» This attribute can be written under restricted conditions, but cannot be read атрибут не может быть прочитан.
Попытаемся разобраться, на каком уровне происходит блокирование чтения таких атрибутов.
В схеме Active Directory у этого атрибута такие свойства отсутствуют он ничем не отличается от тех, что читать можно. То есть изменением схемы положение вещей не изменить. Таким образом, чтение блокируется где-то глубже ниже ldap. Попытаемся понять, как контроллер домена обрабатывает пришедший запрос на чтение атрибута.
Вычислим процесс, принимающий на стороне сервера ldap-запросы от клиентов, определим, какой «слушает» порт 389(воспользуемся программой fport). Это LSASS.EXE.
Кроме этого, посмотрим с другой стороны со стороны хранилища данных. Известно, что Active Directory хранится в файле NTDS.DIT (NT Directory Services — Directory Information Tree). С помощью Process Explorerа(www.sysinternals.com) определим какой процесс открыл этот файл. Опять LSASS.EXE.
То есть обработка ldap-запроса к Active Directory от получения его из порта до чтения данных с диска производится в рамках процесса LSASS.EXE. Воспользовавшись Dependency Walkerом(Windows Support Tools) определим используемые им библиотеки: нас интересует путь, который проделывают данные, от закрытого хранилища к открытым интерфейсам.
В списке используемых DLL встречаются например — NTDSAPI.DLL её интерфейс является открытым (функции определены, например в ntdsapi.h), затем уже интереснее NTDSA.DLL (NT Directory Services Agent), посмотрим экспортируемые функции, попытаемся найти описание в Internet… Например, интерес представляет следующие: DirRead, DirBind,. при поиске на Microsoft.com результатов запроса не найдено. Вот и он, закрытый интерфейс. Попытаться подобрать параметры видимо можно, но времени уйдет много.
Продолжим изучение списка DLL ниже NTDSA находится ESENT.DLL да, нам сообщали — для хранения Active Directory используется Extensible Storage Engine (расширяемый механизм хранения). Вот в ней он видимо и реализован.
Посмотрим, какие функции реализованы в этой библиотеке: много разных, начинающихся со слова Jet, притягивают взгляд: [email protected](один параметр), [email protected](четыре параметра), [email protected](три параметра), [email protected](пять параметров), [email protected](семь параметров), [email protected]… Попытаемся найти описание этих функций Jet использовался также как хранилище данных Exchange: на сайте Microsoft есть описание ошибок, происходивших при вызове этих функций Параметры не описаны. Посмотрим на сам файл(ESENT.DLL) внимательнее если поискать в файле строку Jetinit попадается следующее: JetInitEx(pinstance). Уже интересно то есть какой то намек на параметр.
Сделаем lib-файл для esent.dll с помощью, например dumpbin и lib.
Создадим примерно такое объявление функции: typedef int INSTANCE;
DECLSPEC_IMPORT DWORD WINAPI JetInit(INSTANCE *pinstance);
Вызовем эту функцию, передав ей указатель на instance:
INSTANCE pin; error=JetInit(&pin;);
Попробуем выполнить эту функцию. Ошибок нет она работает. То есть не только процесс LSASS, но и мы видимо можем вызывать все эти функции.
Следующим шагом видимо будет являться функция JetBeginSessionEx( instance, psesid, szUsername, szPassword ) (опять встречается подсказка в ESENT.DLL), похоже что эта функция возвращает идентификатор сессии, который далее используется в JetAttachDatabaseEx( sesid, szFilename, 0, grbit ), затем JetOpenDatabaseEx( sesid, szDatabase, szConnect, pdbid, grbit ), которая уже в свою очередь возвращает идентификатор базы данных. Далее JetOpenTableEx( sesid, dbid, szTableName, pvParameters, cbParameters, grbit, ptableid ), и JetRetrieveColumnsEx( sesid, tableid, pretrievecolumn, cretrievecolumn )
Опуская подробности получения структур параметров (что собственно и отняло времени больше всего остального) приходим к написанной программе которая умеет получать данные из файла NTDS.DIT. Конечно использовать её на рабочей базе нельзя(LSASS блокурует файл при работе) необходимо иметь копию NTDS.DIT.
C помощью программы мы можем получать из таблицы c именем TableName определенные поля.
Пора приступить к изучению структуры базы данных. Поинтересовавшись у знакомых exe и dll-файлов, приходим к тому, что все описание базы данных находится в таблице MSysObjects. Jet позволяет нам получать описание полей таблицы, включая их имена и размер данных — JetGetColumnInfo.
Найдем какое-то более открытое хранилище данных, для экспорта структуры NTDS.DIT. Попробуем сделать экспорт в базу MDB — Microsoft Access(с использованием ADO).
По какому-то счастливому совпадению в MDB уже присутствует скрытая таблица MSysObjects(виновато видимо слово Jet), причем имеющая другое строение.
И все таки что же находится в таблице MSysObjects? Ниже приведен её фрагмент: ColtypOrPgnoFDP Id Name ObjIdTable Type
4 2 MsysObjects 2 1
4 1 ObjIdTable 2 2
3 2 Type 2 2
……………
33 6 datatable 6 1
4 1 DNT_col 6 2
……………
12 314 ATTm590691 6 2
4 315 ATTm590672 6 2
……………
Похоже на то что поле Type = 1 определяет таблицу, 2 поле, 3 — индекс, таким образом в базе определены следующие таблицы:
MSysObjects, MsysObjectsShadow(видимо резервная копия предыдущей), Datatable, link_table, Hiddentable(содержит одну запись), Sdproptable(пустая), MSysDefrag1(содержит одну запись).
Поле ColtypOrPgnoFDP определяет тип поля или номер страницы
Причем из более чем 900 записей в таблице MSysObjects — более 800 описывают поля таблицы datatable примерно следующего вида: ATTm590472, ATTb591170, ATTk590709, ATTm131203, ATTm1376258, ATTq590327, ATTq590326, ATTm12, ATTj131126.
Попытаемся перенести для анализа таблицу datatable в базу MDB, и тут попадается ограничение на 255 полей в таблице базы MDB. Неприятный сюрприз.
То есть Access оказался недостаточно хорош, на этот раз попытаемся перенести базу в SQL Server 2000, благодаря ADO это должно выполняться с минимумом исправлений в коде. Должно.
И тут возникает следующая проблема если строки Unicode переносить как строки (а не поля text) суммарная длина такой записи превосходит размер страницы 8 КБайт. И SQL Server не смог достойно принять данные.
Получается, что хранилище данных ESE отличает возможность работы с достаточно большим количеством столбцов и длинными записями. И тут выбор пал на XML. А почему бы и нет? Всё получилось.
Выполняется экспорт базы ntds.dit в XML-файл, при этом главную ценность представляет таблица datatable. Можно сказать что эта таблица и есть Active Directory.
Учитывая возможность Microsoft Excel работать с файлами XML (с тысячами колонок) появляется подозрение, что разрабатывали Active Directory именно в этой программе.
Недостатком разработанной программы является невозможность выполнить экспорт в рабочем домене. И тут на помощь приходит ntbackup. А почему бы не сделать на ходу резервную копию? Потому что ntbackup делает архив SystemState целиком? И нельзя восстановить один только NTDS.DIT?
А как собственно он делает копию SystemState? Оказывается по частям. Отдельно Active Directory, реестр и так далее. То есть внутри NTBackup эти операции разделены, но сделать копию и восстановить можно только все вместе. Наверное это имеет определенный смысл
И все-таки к вопросу об архивации Active Directory для этого используются вполне документированные функции библиотеки NTDSBCLI.DLL (NT Directory Services Backup CLIent) DsBackupPrepare, DsBackupOpenFile, DsBackupRead. С их помощью мы можем получить копию рабочей базы. Причем для этого необходимо иметь права Backup Operatorа, а делать копию можно на любом компьютере члене домене, а не обязательно контроллере.
Как же сервер отдаёт клиенту заблокированный процессом LSASS файл NTDS.DIT? Если поискать, на сервере оказывается присутствует партнер NTDSBCLI.DLL NTDSBSRV.DLL. И как теперь можно догадаться и проверить в Dependency Walker'е конечно же она используется процессом LSASS.EXE.
В результате получаем программу, которая делает резервную копию рабочей базы или может работать с уже «отцепленным» файлом, и экспортирует базу данных ESE в формат XML.
Причем возможности программы не ограничиваются Windows 2000 Server'ом. Она также была проверена с библиотекой ESENT.DLL и базой NTDS.DIT из состава Windows 2003 Server.
Кроме этого если посмотреть какие еще модули системы используют ESE — получается интересный список(названия говорят сами за себя): DHCPSVC.DLL, CERTDB.DLL, LSERVER.EXE, NTFRS.EXE, SFCFILES.DLL, RSTORE.EXE, WINS.EXE. То есть ESE хранилище является стандартным хранилищем Windows 200x, и теперь появился инструмент для исследования его структуры.
Представляется возможным добавление в программу и обратного действия создание ESE базы данных из XML.
Итоги проведенного исследования
Защита домена Windows 2000 базы Active Directory построена в том числе и на блокировании файла NTDS.DIT процессом LSASS.EXE. При насильственном снятии процесса происходит автоматическое выключение контроллера домена в течении одной минуты.
Сама база Active Directory представляет собой можно сказать одну таблицу, добавление атрибута в схему приводит к появлению в этой таблице новой колонки.
Некоторое открытие закрытой архитектуры Active Directory, как и следовало ожидать, не привело к обнаружению каких-то огромных дыр в безопасности.
Возможно специалисты Microsoft найдут в статье какие-то неточности, объяснить их можно тем, что мы с ними находимся по разные стороны компилятора.
А как же пароли, хранимые с использованием обратимого шифрования?
Продолжение следует
Администраторы домена имеют право сменить пароль пользователя, не зная старого — узнать пароль пользователя не могут даже они. Не могут узнать пароль потому что, как утверждают разработчики Windows 2000 пароль в виде, в котором его набирает пользователь в Active Directory не хранится. Существуют математически обоснованные алгоритмы преобразований, для которых не существует обратных. Если пользователь устанавливает пароль '[email protected]' с помощью такого алгоритма получается какое-то число(hash — хэш), например 0x897dad79be453adfd, при этом вероятность получения из другого пароля такого же числа около нуля. Гарантируется также, что получить из числа 0x897dad79be453adfd снова пароль невозможно. При попытке войти в систему с паролем 'password' система преобразует его с помощью той же функции в число — 0x243052bde34097adafa23d267. Сравнивает полученное число с хранящимся в Active Directory — они не совпадают — пароль не верен. Взлом такой системы возможен — если все-таки найдется преобразование, обратное заданное, в противном случае используется только (brute-force attack) — атака перебором.
Помимо этого в домене Windows 2000 существует возможность включить для пользователя обратимое шифрование пароля, цитируя другие источники:
Создатели операционной системы Windows 2000 предлагают новую учетную политику Store password using reversible encryption for all users in the domain. В соответствии с этой политикой, пароли пользователей хранятся в AD в текстовом виде, так что любой желающий может отыскать их и прочесть.
Политика ослабляет безопасность сети и применятся в ряде случаев. В частности, её необходимо использовать при удаленном подключении пользователей к RAS (Remote Access Server — Серверу удаленного доступа) с использованием протокола проверки подлинности CHAP(Challenge HAndshake Protocol). Согласно спецификации протокола — пароль передается не в открытом виде, а в зашифрованном, причем применяется алгоритм MD5. Стандартными же методами шифрования в среде Windows являются: NTLM или OWF, с их помощью зашифрованные пароли как раз и хранятся Active Directory. MD5 также алгоритм необратимого шифрования, но пароли в таком виде в Active Directory не хранятся. Для проверки его правильности на стороне сервера приходится применять такое же преобразование (MD5) к исходному паролю пользователя(незашифрованному) и сравнивать полученные результаты. Наверное, разработчики могли бы добавить к хранимым в AD паролям, зашифрованный еще по одному алгоритму(MD5), но так как применяется такая проверка подлинности далеко не в каждом домене, вносить в AD еще один атрибут посчитали нецелесообразным. Кроме этого существуют (или могут появиться) другие методы необратимого шифрования. Целью исследования является получение паролей пользователей домена Windows 2000, зашифрованных обратимым образом.
Исследование
А теперь собственно о том, как получить пароль пользователя, если для его учетной записи определена политика: «Хранить пароли, используя обратимое шифрование». Изучим как реализовано хранение паролей и признака обратимого шифрования.
Пароли, зашифрованные с помощью алгоритмов NTLM (NT Lan Manager) и OWF (One-Way Format) хранятся в атрибутах пользователя: DBCS-Pwd (пароль учетной записи Lan Manager) и Unicode-Pwd (пароль пользователя, преобразованный в формат OWF).
Замечание. Хранение паролей в формате NTLM также ослабляет безопасность сети есть возможность его отключить, создав параметр NoLMHash в разделе HKEY_LOCAL_MACHINESYSTEMCurrentControlSetControlLsa.
Признак обратимого шифрования определяется битом 0x80 в атрибуте User-Account-Control (в lmaccess.h: #define UF_ENCRYPTED_TEXT_PASSWORD_ALLOWED 0x0080). Попытаемся прочитать атрибуты DBCS-Pwd и Unicode-Pwd возможно в них находится пароль в открытом виде, если установлен бит ENCRYPTED_TEXT_PASSWORD_ALLOWED.
В базе знаний Microsoft встречается следующее утверждение: The password attribute used by Active Directory is «unicodePwd.» This attribute can be written under restricted conditions, but cannot be read атрибут не может быть прочитан.
Попытаемся разобраться, на каком уровне происходит блокирование чтения таких атрибутов.
В схеме Active Directory у этого атрибута такие свойства отсутствуют он ничем не отличается от тех, что читать можно. То есть изменением схемы положение вещей не изменить. Таким образом, чтение блокируется где-то глубже ниже ldap. Попытаемся понять, как контроллер домена обрабатывает пришедший запрос на чтение атрибута.
Вычислим процесс, принимающий на стороне сервера ldap-запросы от клиентов, определим, какой «слушает» порт 389(воспользуемся программой fport). Это LSASS.EXE.
Кроме этого, посмотрим с другой стороны со стороны хранилища данных. Известно, что Active Directory хранится в файле NTDS.DIT (NT Directory Services — Directory Information Tree). С помощью Process Explorerа(www.sysinternals.com) определим какой процесс открыл этот файл. Опять LSASS.EXE.
То есть обработка ldap-запроса к Active Directory от получения его из порта до чтения данных с диска производится в рамках процесса LSASS.EXE. Воспользовавшись Dependency Walkerом(Windows Support Tools) определим используемые им библиотеки: нас интересует путь, который проделывают данные, от закрытого хранилища к открытым интерфейсам.
В списке используемых DLL встречаются например — NTDSAPI.DLL её интерфейс является открытым (функции определены, например в ntdsapi.h), затем уже интереснее NTDSA.DLL (NT Directory Services Agent), посмотрим экспортируемые функции, попытаемся найти описание в Internet… Например, интерес представляет следующие: DirRead, DirBind,. при поиске на Microsoft.com результатов запроса не найдено. Вот и он, закрытый интерфейс. Попытаться подобрать параметры видимо можно, но времени уйдет много.
Продолжим изучение списка DLL ниже NTDSA находится ESENT.DLL да, нам сообщали — для хранения Active Directory используется Extensible Storage Engine (расширяемый механизм хранения). Вот в ней он видимо и реализован.
Посмотрим, какие функции реализованы в этой библиотеке: много разных, начинающихся со слова Jet, притягивают взгляд: [email protected](один параметр), [email protected](четыре параметра), [email protected](три параметра), [email protected](пять параметров), [email protected](семь параметров), [email protected]… Попытаемся найти описание этих функций Jet использовался также как хранилище данных Exchange: на сайте Microsoft есть описание ошибок, происходивших при вызове этих функций Параметры не описаны. Посмотрим на сам файл(ESENT.DLL) внимательнее если поискать в файле строку Jetinit попадается следующее: JetInitEx(pinstance). Уже интересно то есть какой то намек на параметр.
Сделаем lib-файл для esent.dll с помощью, например dumpbin и lib.
Создадим примерно такое объявление функции: typedef int INSTANCE;
DECLSPEC_IMPORT DWORD WINAPI JetInit(INSTANCE *pinstance);
Вызовем эту функцию, передав ей указатель на instance:
INSTANCE pin; error=JetInit(&pin;);
Попробуем выполнить эту функцию. Ошибок нет она работает. То есть не только процесс LSASS, но и мы видимо можем вызывать все эти функции.
Следующим шагом видимо будет являться функция JetBeginSessionEx( instance, psesid, szUsername, szPassword ) (опять встречается подсказка в ESENT.DLL), похоже что эта функция возвращает идентификатор сессии, который далее используется в JetAttachDatabaseEx( sesid, szFilename, 0, grbit ), затем JetOpenDatabaseEx( sesid, szDatabase, szConnect, pdbid, grbit ), которая уже в свою очередь возвращает идентификатор базы данных. Далее JetOpenTableEx( sesid, dbid, szTableName, pvParameters, cbParameters, grbit, ptableid ), и JetRetrieveColumnsEx( sesid, tableid, pretrievecolumn, cretrievecolumn )
Опуская подробности получения структур параметров (что собственно и отняло времени больше всего остального) приходим к написанной программе которая умеет получать данные из файла NTDS.DIT. Конечно использовать её на рабочей базе нельзя(LSASS блокурует файл при работе) необходимо иметь копию NTDS.DIT.
C помощью программы мы можем получать из таблицы c именем TableName определенные поля.
Пора приступить к изучению структуры базы данных. Поинтересовавшись у знакомых exe и dll-файлов, приходим к тому, что все описание базы данных находится в таблице MSysObjects. Jet позволяет нам получать описание полей таблицы, включая их имена и размер данных — JetGetColumnInfo.
Найдем какое-то более открытое хранилище данных, для экспорта структуры NTDS.DIT. Попробуем сделать экспорт в базу MDB — Microsoft Access(с использованием ADO).
По какому-то счастливому совпадению в MDB уже присутствует скрытая таблица MSysObjects(виновато видимо слово Jet), причем имеющая другое строение.
И все таки что же находится в таблице MSysObjects? Ниже приведен её фрагмент: ColtypOrPgnoFDP Id Name ObjIdTable Type
4 2 MsysObjects 2 1
4 1 ObjIdTable 2 2
3 2 Type 2 2
……………
33 6 datatable 6 1
4 1 DNT_col 6 2
……………
12 314 ATTm590691 6 2
4 315 ATTm590672 6 2
……………
Похоже на то что поле Type = 1 определяет таблицу, 2 поле, 3 — индекс, таким образом в базе определены следующие таблицы:
MSysObjects, MsysObjectsShadow(видимо резервная копия предыдущей), Datatable, link_table, Hiddentable(содержит одну запись), Sdproptable(пустая), MSysDefrag1(содержит одну запись).
Поле ColtypOrPgnoFDP определяет тип поля или номер страницы
Причем из более чем 900 записей в таблице MSysObjects — более 800 описывают поля таблицы datatable примерно следующего вида: ATTm590472, ATTb591170, ATTk590709, ATTm131203, ATTm1376258, ATTq590327, ATTq590326, ATTm12, ATTj131126.
Попытаемся перенести для анализа таблицу datatable в базу MDB, и тут попадается ограничение на 255 полей в таблице базы MDB. Неприятный сюрприз.
То есть Access оказался недостаточно хорош, на этот раз попытаемся перенести базу в SQL Server 2000, благодаря ADO это должно выполняться с минимумом исправлений в коде. Должно.
И тут возникает следующая проблема если строки Unicode переносить как строки (а не поля text) суммарная длина такой записи превосходит размер страницы 8 КБайт. И SQL Server не смог достойно принять данные.
Получается, что хранилище данных ESE отличает возможность работы с достаточно большим количеством столбцов и длинными записями. И тут выбор пал на XML. А почему бы и нет? Всё получилось.
Выполняется экспорт базы ntds.dit в XML-файл, при этом главную ценность представляет таблица datatable. Можно сказать что эта таблица и есть Active Directory.
Учитывая возможность Microsoft Excel работать с файлами XML (с тысячами колонок) появляется подозрение, что разрабатывали Active Directory именно в этой программе.
Недостатком разработанной программы является невозможность выполнить экспорт в рабочем домене. И тут на помощь приходит ntbackup. А почему бы не сделать на ходу резервную копию? Потому что ntbackup делает архив SystemState целиком? И нельзя восстановить один только NTDS.DIT?
А как собственно он делает копию SystemState? Оказывается по частям. Отдельно Active Directory, реестр и так далее. То есть внутри NTBackup эти операции разделены, но сделать копию и восстановить можно только все вместе. Наверное это имеет определенный смысл
И все-таки к вопросу об архивации Active Directory для этого используются вполне документированные функции библиотеки NTDSBCLI.DLL (NT Directory Services Backup CLIent) DsBackupPrepare, DsBackupOpenFile, DsBackupRead. С их помощью мы можем получить копию рабочей базы. Причем для этого необходимо иметь права Backup Operatorа, а делать копию можно на любом компьютере члене домене, а не обязательно контроллере.
Как же сервер отдаёт клиенту заблокированный процессом LSASS файл NTDS.DIT? Если поискать, на сервере оказывается присутствует партнер NTDSBCLI.DLL NTDSBSRV.DLL. И как теперь можно догадаться и проверить в Dependency Walker'е конечно же она используется процессом LSASS.EXE.
В результате получаем программу, которая делает резервную копию рабочей базы или может работать с уже «отцепленным» файлом, и экспортирует базу данных ESE в формат XML.
Причем возможности программы не ограничиваются Windows 2000 Server'ом. Она также была проверена с библиотекой ESENT.DLL и базой NTDS.DIT из состава Windows 2003 Server.
Кроме этого если посмотреть какие еще модули системы используют ESE — получается интересный список(названия говорят сами за себя): DHCPSVC.DLL, CERTDB.DLL, LSERVER.EXE, NTFRS.EXE, SFCFILES.DLL, RSTORE.EXE, WINS.EXE. То есть ESE хранилище является стандартным хранилищем Windows 200x, и теперь появился инструмент для исследования его структуры.
Представляется возможным добавление в программу и обратного действия создание ESE базы данных из XML.
Итоги проведенного исследования
Защита домена Windows 2000 базы Active Directory построена в том числе и на блокировании файла NTDS.DIT процессом LSASS.EXE. При насильственном снятии процесса происходит автоматическое выключение контроллера домена в течении одной минуты.
Сама база Active Directory представляет собой можно сказать одну таблицу, добавление атрибута в схему приводит к появлению в этой таблице новой колонки.
Некоторое открытие закрытой архитектуры Active Directory, как и следовало ожидать, не привело к обнаружению каких-то огромных дыр в безопасности.
Возможно специалисты Microsoft найдут в статье какие-то неточности, объяснить их можно тем, что мы с ними находимся по разные стороны компилятора.
А как же пароли, хранимые с использованием обратимого шифрования?
Продолжение следует
Комментарии