Только для чтения. Пентестим Read-only Domain Controllers - «Новости» » Самоучитель CSS
Меню
Наши новости
Учебник CSS

Невозможно отучить людей изучать самые ненужные предметы.

Введение в CSS
Преимущества стилей
Добавления стилей
Типы носителей
Базовый синтаксис
Значения стилевых свойств
Селекторы тегов
Классы
CSS3

Надо знать обо всем понемножку, но все о немногом.

Идентификаторы
Контекстные селекторы
Соседние селекторы
Дочерние селекторы
Селекторы атрибутов
Универсальный селектор
Псевдоклассы
Псевдоэлементы

Кто умеет, тот делает. Кто не умеет, тот учит. Кто не умеет учить - становится деканом. (Т. Мартин)

Группирование
Наследование
Каскадирование
Валидация
Идентификаторы и классы
Написание эффективного кода

Самоучитель CSS

Вёрстка
Изображения
Текст
Цвет
Линии и рамки
Углы
Списки
Ссылки
Дизайны сайтов
Формы
Таблицы
CSS3
HTML5

Новости

Блог для вебмастеров
Новости мира Интернет
Сайтостроение
Ремонт и советы
Все новости

Справочник CSS

Справочник от А до Я
HTML, CSS, JavaScript

Афоризмы

Афоризмы о учёбе
Статьи об афоризмах
Все Афоризмы

Видео Уроки


Наш опрос



Наши новости

       
10-02-2023, 00:00
Только для чтения. Пентестим Read-only Domain Controllers - «Новости»
Рейтинг:
Категория: Новости

В сетях на осно­ве Windows сущес­тву­ет спе­циаль­ный под­вид кон­трол­леров домена под наз­вани­ем Read-only Domain Controller. Сегод­ня мы погово­рим об уяз­вимос­тях таких кон­трол­леров и рас­смот­рим век­торы атак, которые мож­но к ним при­менить.
 

Теория


 

Определения и особенности


Read-only Domain Controller был пред­став­лен в Windows Server 2008. Его основная цель — обес­печить безопас­ное вза­имо­дей­ствие сер­вера со служ­бой катало­гов. Очень час­то подоб­ные кон­трол­леры домена ста­вят в каких‑нибудь уда­лен­ных офи­сах ком­пании, ста­рых фили­алах и про­чих мес­тах, где невоз­можно гаран­тировать дос­таточ­ную физичес­кую безопас­ность сер­вера. Получив дос­туп к такому устрой­ству, ни один зло­умыш­ленник не смо­жет тол­ком пов­лиять на домен.


Внут­ри RODC хра­нит­ся копия базы AD, но чуточ­ку изме­нен­ная. Во‑пер­вых, не сох­раня­ется мно­жес­тво атри­бутов, нап­ример ms-Mcs-AdmPwd — в этом атри­буте хра­нит­ся пароль локаль­ного адми­нис­тра­тора при нас­тро­енном LAPS. Во‑вто­рых, раз­решено кеширо­вать учет­ные дан­ные лишь кон­крет­ных поль­зовате­лей. Нап­ример, поль­зовате­лей это­го самого уда­лен­ного офи­са.


Что такое кеширо­вание? Это обыч­ное сох­ранение учет­ных дан­ных поль­зовате­лей. Сох­раня­ются они в фай­ле ntds.dit, рав­но как и на обыч­ном кон­трол­лере домена.


При­чем RODC не соз­дает домен, а добав­ляет­ся в сущес­тву­ющий. Дела­ется это еще на эта­пе уста­нов­ки и выг­лядит вот так.


Только для чтения. Пентестим Read-only Domain Controllers - «Новости»
Нас­трой­ка RODC

При этом исполь­зование RODC дает мно­жес­тво пре­иму­ществ в пла­не безопас­ности: отдель­ный DNS-сер­вер, изме­нения в котором никак не отра­жают­ся на основном, делеги­рова­ние роли адми­нис­тра­тора любому поль­зовате­лю (при­чем этот поль­зователь необя­затель­но дол­жен быть адми­нис­тра­тором на обыч­ных кон­трол­лерах домена).


Наз­начение поль­зовате­лей

Так­же сле­дует выделить осо­бен­ность реп­ликации (DCSYNC) — она воз­можна толь­ко со сто­роны обыч­ного кон­трол­лера домена. RODC ничего реп­лициро­вать не может. Так­же при­сутс­тву­ет изо­ляция SYSVOL — любые изме­нения в груп­повых полити­ках оста­ются на RODC и не рас­простра­няют­ся на основной домен.


Ес­ли рас­смат­ривать RODC на «тировой» архи­тек­туре Microsoft, то воз­ника­ют опре­делен­ные слож­ности, так как при­над­лежащие Tier 0 ресур­сы не могут работать в тех мес­тах, где дол­жны находить­ся RODC. А RODC не дол­жны иметь под кон­тро­лем какие‑либо ресур­сы из Tier 0. Поэто­му хос­ты RODC и учет­ные дан­ные для под­клю­чения к ним никак не могут при­над­лежать Tier 0, но вот сами компь­ютер­ные объ­екты RODC сле­дует защищать, как Tier 0.


 

Атрибуты


RODC име­ет мно­жес­тво осо­бен­ностей. Пер­вая — поч­ти вся нуж­ная ата­кующе­му информа­ция находит­ся в атри­бутах компь­ютер­ной учет­ной записи RODC. Наибо­лее инте­рес­ные для нас атри­буты крат­ко опи­саны ниже.


managedBy

Здесь ука­зыва­ется объ­ект, которо­му делеги­рова­но адми­нис­тра­тив­ное управле­ние RODC. Любой поль­зователь или груп­па, ука­зан­ные в этом атри­буте, явля­ются локаль­ными адми­нис­тра­тора­ми на RODC:


Get-ADComputer'RODC'-propmanagedBy
Изу­чение атри­бута
msDS-RevealOnDemandGroup, msDS-NeverRevealGroup

В этом атри­буте ука­зыва­ются объ­екты, учет­ные дан­ные которых могут кеширо­вать­ся. Кеширо­вание нуж­но для того, что­бы эти поль­зовате­ли мог­ли про­ходить про­вер­ку под­линнос­ти на RODC.


Get-ADComputer'RODC'-propmsDS-RevealOnDemandGroup,msDS-NeverRevealGroup
Изу­чение атри­бутов

Со­ответс­твен­но, сущес­тву­ет атри­бут, зап­реща­ющий кеширо­вание про­писан­ных в нем учет­ных дан­ных объ­ектов. Он называ­ется msDS-NeverRevealGroup.


msDS-AuthenticatedToAccountList

Здесь будут хра­нить­ся объ­екты, которые успешно аутен­тифици­рова­лись на RODC:


Get-ADComputer'RODC'-propmsDS-AuthenticatedToAccountList
Изу­чение атри­бута
msDS-Revealed*

Это целая груп­па из нес­коль­ких атри­бутов:



  • msDS-RevealedUsers — спи­сок объ­ектов, учет­ные дан­ные которых ког­да‑либо кеширо­вались на RODC;

  • msDS-RevealedDSAs — спи­сок RODC, которые кеширо­вали пароль поль­зовате­ля;

  • msDS-RevealedList — спи­сок объ­ектов, учет­ные дан­ные которых были успешно сох­ранены на RODC.


Get-ADComputer'RODC'-propmsDS-RevealedList,msDS-RevealedDSAs,msDS-RevealedUsers
Изу­чение атри­бутов 

Аутентификация пользователей


RODC кеширу­ет учет­ные дан­ные опре­делен­ных поль­зовате­лей как раз таки, что­бы про­верить их под­линность. Пос­ле успешной аутен­тифика­ции по всем канонам дол­жен быть сге­нери­рован TGT-билет, но RODC нель­зя счи­тать надеж­ным KDC, поэто­му у него соз­дает­ся собс­твен­ная учет­ная запись krbtgt. Ее пароль исполь­зует­ся для под­писи соз­дава­емых TGT.


Упо­мяну­тая учет­ная запись име­ет необыч­ное имя: krbtgt_<цифры>. Эти самые циф­ры — спе­циаль­ный иден­тифика­тор клю­ча, который исполь­зовал­ся для шиф­рования TGT-билета. Имя новой учет­ной записи KRBTGT хра­нит­ся в атри­буте msDS-KrbTgtLink объ­екта RODC. А у этой самой новой учет­ной записи KRBTGT в атри­буте msDS-KrbTgtLinkBl содер­жится имя RODC. Таким обра­зом, обна­ружив RODC, мож­но свя­зать его с кон­крет­ным KRBTGT_XXXXX. И, соот­ветс­твен­но, обна­ружив KRBTGT_XXXXX, мож­но свя­зать его с кон­крет­ным RODC.


До­пол­нитель­но отме­чу, что RODC име­ет пра­во на сброс пароля этой самой KRBTGT_XXXXX.


Get-ADUser -filter {name -like "krbtgt*"} -propName,Created,PasswordLastSet,msDS-KeyVersionNumber,msDS-KrbTgtLinkBl
На­хож­дение KRBTGT_XXXXX
Get-ADComputer RODC -PropertiesmsDS-KrbTgtLink
На­хож­дение свя­зан­ного krbtgt
Get-ADUser krbtgt_19160 -PropertiesmsDS-SecondaryKrbTgtNumber,msDS-KrbTGTLinkBl
На­хож­дение свя­зан­ного RODC 

Поиск RODC


В сетях на осно­ве Windows сущес­тву­ет спе­циаль­ный под­вид кон­трол­леров домена под наз­вани­ем Read-only Domain Controller. Сегод­ня мы погово­рим об уяз­вимос­тях таких кон­трол­леров и рас­смот­рим век­торы атак, которые мож­но к ним при­менить. Теория Определения и особенности Read-only Domain Controller был пред­став­лен в Windows Server 2008. Его основная цель — обес­печить безопас­ное вза­имо­дей­ствие сер­вера со служ­бой катало­гов. Очень час­то подоб­ные кон­трол­леры домена ста­вят в каких‑нибудь уда­лен­ных офи­сах ком­пании, ста­рых фили­алах и про­чих мес­тах, где невоз­можно гаран­тировать дос­таточ­ную физичес­кую безопас­ность сер­вера. Получив дос­туп к такому устрой­ству, ни один зло­умыш­ленник не смо­жет тол­ком пов­лиять на домен. Внут­ри RODC хра­нит­ся копия базы AD, но чуточ­ку изме­нен­ная. Во‑пер­вых, не сох­раня­ется мно­жес­тво атри­бутов, нап­ример ms-Mcs-AdmPwd — в этом атри­буте хра­нит­ся пароль локаль­ного адми­нис­тра­тора при нас­тро­енном LAPS. Во‑вто­рых, раз­решено кеширо­вать учет­ные дан­ные лишь кон­крет­ных поль­зовате­лей. Нап­ример, поль­зовате­лей это­го самого уда­лен­ного офи­са. Что такое кеширо­вание? Это обыч­ное сох­ранение учет­ных дан­ных поль­зовате­лей. Сох­раня­ются они в фай­ле ntds.dit, рав­но как и на обыч­ном кон­трол­лере домена. При­чем RODC не соз­дает домен, а добав­ляет­ся в сущес­тву­ющий. Дела­ется это еще на эта­пе уста­нов­ки и выг­лядит вот так. Нас­трой­ка RODCПри этом исполь­зование RODC дает мно­жес­тво пре­иму­ществ в пла­не безопас­ности: отдель­ный DNS-сер­вер, изме­нения в котором никак не отра­жают­ся на основном, делеги­рова­ние роли адми­нис­тра­тора любому поль­зовате­лю (при­чем этот поль­зователь необя­затель­но дол­жен быть адми­нис­тра­тором на обыч­ных кон­трол­лерах домена). Наз­начение поль­зовате­лейТак­же сле­дует выделить осо­бен­ность реп­ликации (DCSYNC) — она воз­можна толь­ко со сто­роны обыч­ного кон­трол­лера домена. RODC ничего реп­лициро­вать не может. Так­же при­сутс­тву­ет изо­ляция SYSVOL — любые изме­нения в груп­повых полити­ках оста­ются на RODC и не рас­простра­няют­ся на основной домен. Ес­ли рас­смат­ривать RODC на «тировой» архи­тек­туре Microsoft, то воз­ника­ют опре­делен­ные слож­ности, так как при­над­лежащие Tier 0 ресур­сы не могут работать в тех мес­тах, где дол­жны находить­ся RODC. А RODC не дол­жны иметь под кон­тро­лем какие‑либо ресур­сы из Tier 0. Поэто­му хос­ты RODC и учет­ные дан­ные для под­клю­чения к ним никак не могут при­над­лежать Tier 0, но вот сами компь­ютер­ные объ­екты RODC сле­дует защищать, как Tier 0. Атрибуты RODC име­ет мно­жес­тво осо­бен­ностей. Пер­вая — поч­ти вся нуж­ная ата­кующе­му информа­ция находит­ся в атри­бутах компь­ютер­ной учет­ной записи RODC. Наибо­лее инте­рес­ные для нас атри­буты крат­ко опи­саны ниже. managedBy Здесь ука­зыва­ется объ­ект, которо­му делеги­рова­но адми­нис­тра­тив­ное управле­ние RODC. Любой поль­зователь или груп­па, ука­зан­ные в этом атри­буте, явля­ются локаль­ными адми­нис­тра­тора­ми на RODC: Get-ADComputer 'RODC' -prop managedBy Изу­чение атри­бута msDS-RevealOnDemandGroup, msDS-NeverRevealGroup В этом атри­буте ука­зыва­ются объ­екты, учет­ные дан­ные которых могут кеширо­вать­ся. Кеширо­вание нуж­но для того, что­бы эти поль­зовате­ли мог­ли про­ходить про­вер­ку под­линнос­ти на RODC. Get-ADComputer 'RODC' -prop msDS-RevealOnDemandGroup , msDS-NeverRevealGroup Изу­чение атри­бутовСо­ответс­твен­но, сущес­тву­ет атри­бут, зап­реща­ющий кеширо­вание про­писан­ных в нем учет­ных дан­ных объ­ектов. Он называ­ется msDS-NeverRevealGroup. msDS-AuthenticatedToAccountList Здесь будут хра­нить­ся объ­екты, которые успешно аутен­тифици­рова­лись на RODC: Get-ADComputer 'RODC' -prop msDS-AuthenticatedToAccountList Изу­чение атри­бута msDS-Revealed* Это целая груп­па из нес­коль­ких атри­бутов: msDS-RevealedUsers — спи­сок объ­ектов, учет­ные дан­ные которых ког­да‑либо кеширо­вались на RODC; msDS-RevealedDSAs — спи­сок RODC, которые кеширо­вали пароль поль­зовате­ля; msDS-RevealedList — спи­сок объ­ектов, учет­ные дан­ные которых были успешно сох­ранены на RODC. Get-ADComputer 'RODC' -prop msDS-RevealedList , msDS-RevealedDSAs , msDS-RevealedUsers Изу­чение атри­бутов Аутентификация пользователей RODC кеширу­ет учет­ные дан­ные опре­делен­ных поль­зовате­лей как раз таки, что­бы про­верить их под­линность. Пос­ле успешной аутен­тифика­ции по всем канонам дол­жен быть сге­нери­рован TGT-билет, но RODC нель­зя счи­тать надеж­ным KDC, поэто­му у него соз­дает­ся собс­твен­ная учет­ная запись krbtgt. Ее пароль исполь­зует­ся для под­писи соз­дава­емых TGT. Упо­мяну­тая учет­ная запись име­ет необыч­ное имя: krbtgt_

Теги: CSS

Просмотров: 253
Комментариев: 0:   10-02-2023, 00:00
Уважаемый посетитель, Вы зашли на сайт как незарегистрированный пользователь. Мы рекомендуем Вам зарегистрироваться либо войти на сайт под своим именем.

 
Еще новости по теме:



Другие новости по теме:
Комментарии для сайта Cackle