Kerberoasting для FreeIPA. Как я искал доступ к домену, а нашел CVE

Содержание статьи

• Ищем уязвимость и пишем PoC
• Компрометация домена и путь к эксплуатации
• Общение с вендором
• Выводы

Са­мые веселые баги мож­но най­ти там, где их ник­то не ждал, — нап­ример, в популяр­ных решени­ях управле­ния дос­тупом, таких как FreeIPA. Пред­ставь: у нас есть воз­можность зап­росить важ­ные дан­ные из сис­темы, казав­шей­ся абсо­лют­но защищен­ной. Что, если это не прос­то уда­ча? Забегая впе­ред, ска­жу, что она при­вела меня к нес­коль­ким инте­рес­ней­шим наход­кам. Pentest Award

Этот текст получил пер­вое мес­то на Pentest Award 2024 в катего­рии «Про­бив инфры». Это сорев­нование еже­год­но про­водит­ся ком­пани­ей Awillix.

FreeIPA — это плат­форма для управле­ния иден­тифика­цией и дос­тупом поль­зовате­лей в сети, которая час­то при­меня­ется для цен­тра­лизо­ван­ного кон­тро­ля прав и аутен­тифика­ции. По сути, Active Directory, но для Linux.

Ког­да я в рам­ках пен­теста получил учет­ную запись из домена на FreeIPA, ока­залось, что прав у учет­ки поч­ти нет. Одна­ко выяс­нилось, что с помощью ути­литы kvno мож­но зап­росить тикеты TGS для любого поль­зовате­ля в домене FreeIPA, хотя обыч­ные инс­тру­мен­ты, такие как Impacket, в этом слу­чае не работа­ли. Вспом­нив про метод под­бора паролей, извес­тный как Kerberoasting, я запус­тил hashcat, но и в этом слу­чае ничего не выш­ло — даже при извес­тном пароле для моего поль­зовате­ля.

Тем не менее воз­можность получать TGS для любого поль­зовате­ля домена заин­три­гова­ла меня и под­тол­кну­ла к даль­нейше­му иссле­дова­нию.

warning

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

Ищем уязвимость и пишем PoC

Сна­чала поп­робу­ем поис­кать, что вооб­ще пишут про это.

Вот, нап­ример, Ли Чагол­ла‑Крис­тенсен пишет, что FreeIPA не поз­воля­ет соз­давать сер­висы с паролем, задан­ным поль­зовате­лем (в AD это соот­ветс­тву­ет учет­ной записи с SPN). Обыч­ные учет­ные записи не могут исполь­зовать­ся как сер­висы Kerberos, что дела­ет невоз­можным при­мене­ние ата­ки Kerberoasting. Это дол­жно обес­печивать высокий уро­вень безопас­ности по умол­чанию.

Что ж, раз по теме ничего нет, начина­ем свое иссле­дова­ние. Я раз­вернул тес­товую инфраструк­туру и начал изу­чать MIT Kerberos (который вхо­дит в сос­тав FreeIPA). Важ­но было понять, как он интегри­рует­ся с 389 Directory Server — мес­тным ана­логом Active Directory.

Мне уда­лось уста­новить, что при сме­не пароля поль­зовате­ля меня­ется его ключ AES. Одна­ко если у поль­зовате­лей оди­нако­вые пароли, то клю­чи будут раз­ные. Зна­чит, все дело в соли (в AD все зна­ют, что это домен плюс имя поль­зовате­ля).

Пос­ле дол­гого иссле­дова­ния исходни­ков (так как докумен­тации ниг­де нет) и прос­мотра тра­фика в Wireshark я уста­новил, что для каж­дого поль­зовате­ля во вре­мя его заведе­ния в домен исполь­зует­ся про­изволь­ная соль и при получе­нии TGT-билета в пер­вом отве­те с ошиб­кой о необ­ходимос­ти пре­аутен­тифика­ции она добав­ляет­ся в спе­циаль­ное поле. Так­же ее мож­но обна­ружить при исполь­зовании ути­литы kinit с локаль­ной перемен­ной KRB5_TRACE.

Как видишь, пароль может вооб­ще сос­тоять из про­изволь­ных сим­волов, в том чис­ле с про­бела­ми и обратны­ми сле­шами. Так­же я обна­ружил, что FreeIPA работа­ет толь­ко с AES256, что грус­тно.

Источник: xakep.ru