Только для чтения. Пентестим Read-only Domain Controllers

Теория

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

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

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

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

При­чем 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:

msDS-RevealOnDemandGroup, msDS-NeverRevealGroup

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

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

msDS-AuthenticatedToAccountList

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

msDS-Revealed*

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

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

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

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.

Поиск RODC