Privesc as a Service. Повышаем привилегии через Active Directory Certification Services

В Windows Server при­сутс­тву­ет роль под наз­вани­ем Active Directory Certification Services (AD CS), которая нуж­на для реали­зации инфраструк­туры откры­тых клю­чей (PKI) в сетях с кон­трол­лером домена. AD CS пред­назна­чена для выдачи сер­тифика­тов поль­зовате­лям и компь­юте­рам. Сер­тифика­ты могут исполь­зовать­ся для шиф­рования, под­писи, аутен­тифика­ции и тому подоб­ного, и в целом эта роль выг­лядит как сер­вис для повыше­ния безопас­ности в домене.

Ча­ще все­го при пен­тесте домена Active Directory конеч­ной целью ста­вит­ся перех­ват учет­ной записи адми­нис­тра­тора. Получив адми­на, мож­но шиф­ровать сис­тему сда­вать отчет и закан­чивать про­ект. Есть мно­жес­тво спо­собов добить­ся ука­зан­ной цели, и один из них — экс­плу­ата­ция неп­равиль­ных кон­фигура­ций шаб­лонов, по которым выпус­кают­ся сер­тифика­ты.

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

Центр сертификации

В рам­ках Active Directory центр сер­тифика­ции реали­зует фун­кцию инфраструк­туры откры­тых клю­чей. В свою оче­редь, инфраструк­тура откры­тых клю­чей (PKI) — это набор служб и ком­понен­тов, поз­воля­ющих управлять клю­чами и сер­тифика­тами в сети.

Ос­новная цель цен­тра сер­тифика­ции сос­тоит в выдаче, отзы­ве, перевы­пус­ке сер­тифика­тов и тому подоб­ном. Центр сер­тифика­ции, раз­верну­тый пер­вым, явля­ется кор­нем инфраструк­туры откры­тых клю­чей. Далее мож­но раз­верты­вать под­чинен­ные ЦС, рас­положен­ные в иерар­хии инфраструк­туры откры­тых клю­чей, в вер­хней час­ти которой находит­ся кор­невой ЦС.

Сертификаты

Cер­тификат в общем смыс­ле — это документ фор­мата X.509, содер­жащий информа­цию о сво­ем вла­дель­це. Может исполь­зовать­ся как средс­тво иден­тифика­ции и аутен­тифика­ции.

Сер­тифика­ты вклю­чают в себя некото­рые парамет­ры. Вот наибо­лее инте­рес­ные из них:

• Subject — вла­делец сер­тифика­та;
• SAN (SubjectAlternativeName) опре­деля­ет одно или нес­коль­ко аль­тер­натив­ных имен, которые может исполь­зовать вла­делец (это нам при­годит­ся в ата­ках);
• Extended/Enhanced Key Usages — набор иден­тифика­торов, которые опре­деля­ют, как будет исполь­зовать­ся сер­тификат.

Сер­тифика­ты выпус­кают­ся по опре­делен­ным шаб­лонам, опи­сыва­ющим парамет­ры, с которы­ми будет выпущен сер­тификат, нап­ример:

• Кто может зап­рашивать сер­тификат по дан­ному шаб­лону?
• Кто может изме­нять шаб­лон?
• Ка­кие EKU (зна­чения Extended Key Usage) будут опре­деле­ны?
• На какой пери­од будет выпущен сер­тификат?

Про­ще говоря, шаб­лоны сер­тифика­тов опре­деля­ют порядок зап­роса и исполь­зования сер­тифика­тов, выдан­ных цен­тром сер­тифика­ции.

В поисках сертификатов

Шаб­лоны сер­тифика­тов хра­нят­ся в сле­дующем кон­тей­нере:

Со­ответс­твен­но, получить шаб­лоны мож­но при помощи сле­дующей коман­ды PowerShell, исполь­зуя модуль AD:

Так­же в Windows есть пре­дус­танов­ленный инс­тру­мент certutil, который может вывес­ти все шаб­лоны для сер­тифика­тов в более удоб­ном и под­робном виде.

Инс­тру­мент Certipy поз­волит сде­лать это с Linux и сра­зу выг­рузить дан­ные, которые мож­но заг­рузить в BloodHound.

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

Зна­чения поля EKU, поз­воля­ющие аутен­тифици­ровать­ся в домене:

• Client Authentication (1.3.6.1.5.5.7.3.2);
• PKINIT Client Authentication (1.3.6.1.5.2.3.4);
• Smart Card Logon (1.3.6.1.4.1.311.20.2.2);
• Any Purpose EKU (2.5.29.37.0);
• SubCA (-).

Атаки на AD CS

Лаборатория

Для про­веде­ния тес­тов нам пот­ребу­ется лабора­тор­ный стенд, сос­тоящий из двух вир­туаль­ных машин: Windows Server 2016 и Kali Linux. Перечис­лим общие тре­бова­ния для всех атак:

• сер­тификат может выпус­кать­ся груп­пой, в которую вхо­дит ваш поль­зователь;
• Manager Approval дол­жен быть отклю­чен;
• под­пись CSR не тре­бует­ся.

Пос­ледние два тре­бова­ния выпол­няют­ся в Windows Server по умол­чанию, и на них мож­но не обра­щать вни­мания (при­вет, адми­ны!). Еще нам пот­ребу­ется воз­можность аутен­тифика­ции в домене с выпущен­ным сер­тифика­том. На нашем лабора­тор­ном стен­де мы будем исполь­зовать поль­зовате­ля Kent.Jill:P@ssw0rd.

Сбор информации

Сбор информа­ции о цели — пер­вый этап тес­тирова­ния на про­ник­новение. Для сбо­ра информа­ции и визу­али­зации мож­но исполь­зовать Certipy + BloodHound. Перед этим нуж­но заг­рузить под­готов­ленные раз­работ­чиками Certipy зап­росы на свой хост.

По­лучить информа­цию из цен­тра сер­тифика­ции поз­воля­ет модуль find:

BloodHound дает воз­можность визу­али­зиро­вать информа­цию по объ­ектам AD CS и пра­вам на них, а так­же опре­делить век­торы повыше­ния при­виле­гий.

Modifiable SAN. ESC1

Это ата­ка осно­выва­ется на изме­нении парамет­ра SAN, который поз­воля­ет ука­зать аль­тер­натив­ное имя поль­зовате­ля. Это поз­волит нам выпус­тить сер­тификат на дру­гого поль­зовате­ля, даже адми­нис­тра­тора домена. Что­бы ата­ка прош­ла успешно, шаб­лон сер­тифика­та дол­жен иметь уста­нов­ленный флаг ENROLLEE_SUPPLIES_SUBJECT.