Active Directory пре­дос­тавля­ет мощ­ный набор фун­кций для делеги­рова­ния прав на оли­цет­ворение поль­зовате­лей кон­крет­ной служ­бе. Сущес­тву­ет три вида делеги­рова­ния: неог­раничен­ное, огра­ничен­ное и огра­ничен­ное на осно­ве ресур­сов. Про каж­дый уже рас­ска­зыва­лось мно­го раз, но какие еще воз­можнос­ти таит в себе механизм делеги­рова­ния?

Особенности неограниченного делегирования

При неог­раничен­ном делеги­рова­нии адми­нис­тра­тор при­ходит к служ­бе и говорит: «Теперь ты можешь оли­цет­ворять кли­ентов на дру­гих служ­бах». При­чем на абсо­лют­но любых служ­бах (отсю­да и наз­вание — неог­раничен­ное). Как это работа­ет?

Во‑пер­вых, кли­ент обра­щает­ся к служ­бе с неог­раничен­ным делеги­рова­нием. KDC видит, что эта служ­ба име­ет спе­циаль­ный флаг TRUSTED_FOR_DELEGATION (он сиг­нализи­рует о том, что у служ­бы нас­тро­ено неог­раничен­ное делеги­рова­ние), поэто­му воз­вра­щает кли­енту TGS на эту служ­бу, но со спе­циаль­ным фла­гом OK-AS-DELEGATE. Сле­дующим шагом кли­ент про­веря­ет этот самый флаг. Если он видит, что флаг уста­нов­лен, то понима­ет: служ­ба исполь­зует неог­раничен­ное делеги­рова­ние, поэто­му кли­ент вновь идет к KDC и зап­рашива­ет спе­циаль­ный FORWARDED TGT, который будет отправ­лен служ­бе.

Внут­ри это­го тикета будет лежать так­же сес­сион­ный ключ, что поз­волит служ­бе без проб­лем оли­цет­ворять кли­ента. Далее у кли­ента будет TGS-тикет на служ­бу, а так­же этот FORWARDED TGT, поэто­му пора идти к служ­бе. Генери­рует­ся зап­рос AP-REQ, который содер­жит этот самый FORWARDED TGT.

При­чем тикет будет находить­ся внут­ри так называ­емо­го аутен­тифика­тора. Он поз­воля­ет пре­дот­вра­тить воз­можность релей‑ата­ки на этап AP-REQ, так как аутен­тифика­тор зашиф­рован сес­сион­ным клю­чом, а так­же содер­жит (в слу­чае обыч­ного AP-REQ) имя прин­ципала кли­ента и тай­мстемп. Если же служ­ба нас­тро­ена с неог­раничен­ным делеги­рова­нием, то в зап­рос AP-REQ, который отпра­вит­ся служ­бе, попадет не толь­ко тай­мстемп и имя прин­ципала, но и FORWARDED TGT. При­чем этот самый FORWARDED TGT будет лежать внут­ри аутен­тифика­тора. Сес­сион­ный ключ для шиф­рования аутен­тифика­тора кли­ент получа­ет в отве­те TGS-REP, который идет до AP-REQ.

Та­ким обра­зом, у ата­кующе­го появ­ляет­ся воз­можность рас­шифро­вать аутен­тифика­тор из AP-REQ, а затем получить TGT-билет поль­зовате­ля, который ини­цииро­вал обра­щение к служ­бе с неог­раничен­ным делеги­рова­нием, ведь на руках у него будет зашиф­рован­ный блоб и ключ для его дешиф­ровки.

Особенности эксплуатации

Что­бы успешно получить TGT, нуж­но, что­бы выпол­нялись сле­дующие тре­бова­ния:

• 
  
• служ­ба, к которой обра­щает­ся кли­ент, нас­тро­ена на неог­раничен­ное делеги­рова­ние. Но здесь ничего страш­ного нет — все кон­трол­леры домена нас­тро­ены с неог­раничен­ным делеги­рова­нием;
• 
  
• у нас есть воз­можность выпол­нить код от лица кли­ента.
• 
  

Ито­говый алго­ритм дос­таточ­но прос­той:

1. 
   
2. Об­раща­емся к служ­бе с неог­раничен­ным делеги­рова­нием.
3. 
   
4. По­луча­ем сге­нери­рован­ный AP-REQ.
5. 
   
6. Из­вле­каем сес­сион­ный ключ для рас­шифров­ки аутен­тифика­тора.
7. 
   
8. Рас­шифро­выва­ем аутен­тифика­тор.
9. 
   
10. Из­вле­каем TGT.
11. 
    

Обнаружение нужной службы

Итак, сна­чала соз­даем файл Header.h, в котором ука­зыва­ем все нуж­ные заголо­воч­ные фай­лы, под­гру­жаемые либы, а так­же про­тотип одной‑единс­твен­ной фун­кции.

Те­перь сто­ит пре­дус­мотреть два вари­анта работы инс­тру­мен­та: в пер­вом слу­чае служ­ба с неог­раничен­ным делеги­рова­нием будет обна­руже­на авто­мати­чес­ки (дос­таточ­но толь­ко име­ни домена), а во вто­ром ата­кующий собс­твен­норуч­но смо­жет ука­зать нуж­ный SPN.

Глав­ная фун­кция инс­тру­мен­та не очень боль­шая. Сна­чала получа­ем спи­сок аргу­мен­тов, при­чем про­веря­ем: если их не три, то ата­кующий ука­зал что‑то не то, поэто­му вызыва­ем фун­кцию, которая рас­ска­жет, как исполь­зовать инс­тру­мент.

Ес­ли же поль­зователь ниг­де не напор­тачил, то перехо­дим к пар­сингу аргу­мен­тов. В пер­вом слу­чае, ког­да ука­зыва­ется толь­ко имя домена, вызыва­ется фун­кция GetDomainController().

Эта фун­кция поз­воля­ет получить DNS-имя кон­трол­лера домена. Мы берем кон­трол­лер домена потому, что на нем по умол­чанию вклю­чено неог­раничен­ное делеги­рова­ние. Получить имя мож­но с помощью фун­кции DsGetDcName().

Пос­ле получе­ния име­ни уби­раем из него пер­вые два сим­вола сле­ша (так как фун­кция вер­нула dc01, а нам нуж­но прос­то dc01), а затем добав­ляем к получен­ному име­ни служ­бу CIFS. В ито­ге у нас появ­ляет­ся валид­ный SPN на служ­бу CIFS кон­трол­лера домена.

Фун­кция removeLeadingCharacters прос­то чуть‑чуть сме­щает ука­затель на получен­ную стро­ку, что­бы пер­вые два сим­вола как бы про­пали.

А фун­кция addCIFS() добав­ляет стро­ку CIFS/ к име­ни компь­юте­ра.

Есть и вто­рой вари­ант — поль­зователь дол­жен самос­тоятель­но ука­зать SPN. Здесь никако­го пар­синга тог­да не пот­ребу­ется. Сра­зу переда­ем получен­ный SPN в фун­кцию TgtDeleg(), в которой реали­зова­на логика получе­ния сес­сион­ного клю­ча и бло­ба AP-REQ.

Подключение к службе

Пе­рехо­дим в сер­дце прог­раммы — в фун­кцию TgtDeleg(). Она при­нима­ет один‑единс­твен­ный аргу­мент — это SPN целевой служ­бы. Затем начина­ется, как кто‑то очень инте­рес­но выразил­ся, «магия SSPI». В дей­стви­тель­нос­ти никакой магии нет. SSPI мож­но счи­тать эда­кой апиш­кой, через которую раз­работ­чики могут свя­зывать­ся с пос­тавщи­ками безопас­ности (Security Packages). Воз­можнос­ти SSPI очень боль­шие: шиф­рование, под­пись, выс­тра­ива­ние кон­тек­ста. Имен­но фун­кции SSPI поз­волят нам сымити­ровать обра­щение к служ­бе с неог­раничен­ным делеги­рова­нием.

Теги: CSS