Перспективные исследования за первую половину 2025-го. Колонка Дениса Макрушина

Поиск секретов и уязвимостей dangling DNS в больших данных

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

С перехо­дом инфраструк­туры в обла­ка вто­рой метод может дать инте­рес­ные ре­зуль­таты. Нап­ример, если на боль­шом пуле IP-адре­сов круп­ных облачных про­вай­деров вро­де Google и AWS поис­кать «висячие» DNS-записи (dangling DNS), которые ука­зыва­ют на несущес­тву­ющий ресурс и дос­тупны для зах­вата, то мож­но обна­ружить мно­го воз­можнос­тей для атак subdomain takeover.

Бо­лее 78 тысяч «висячих» DNS-записей, которые ука­зыва­ют на 66 тысяч уни­каль­ных доменов вер­хне­го уров­ня. Сре­ди вла­дель­цев этих доменов есть круп­ные ком­пании и брен­ды, а зна­чит, зло­умыш­ленник может раз­местить на этих доменах свой ресурс, который будет экс­плу­ати­ровать доверие поль­зовате­лей.

Ана­логич­ный под­ход мож­но при­менить и к поис­ку сек­ретов в фай­лах. Если взять источник вро­де VirusTotal и с помощью YARA-пра­вил поис­кать в нем фай­лы с клю­чами и пароля­ми, мож­но обна­ружить более 15 тысяч сек­ретов. Сре­ди них 2500 клю­чей для под­клю­чения к инфраструк­туре OpenAI, 3000 — для AWS и Google Cloud.

Ос­новные прин­ципы это­го под­хода:

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

При­меняй этот под­ход, что­бы осве­жить свои иссле­дова­ния.

Прощай, CSRF! Поиск и эксплуатация уязвимостей client-side path traversal

Из нет­риви­аль­ных уяз­вимос­тей, о которых дав­но извес­тно, но которые пока еще мало кто целенап­равлен­но ищет, мож­но выделить катего­рию client-side path traversal (CSPT).

Ис­сле­дова­тели хорошо зна­ют проб­лемы, свя­зан­ные с обхо­дом катало­га. Уяз­вимость path traversal поз­воля­ет исполь­зовать стро­ки вида ../../../../../ для дос­тупа к дан­ным за пре­дела­ми целево­го катало­га. В отли­чие от уяз­вимос­ти на сто­роне сер­вера, CSPT дает ата­кующе­му воз­можность зас­тавить жер­тву делать зап­росы к инте­рес­ным конеч­ным точ­кам API. И эта воз­можность — пер­вое усло­вие для реали­зации ата­ки.

Вто­рое усло­вие: наличие инте­рес­ного эндпо­инта, к которо­му мож­но обра­тить­ся и осу­щес­твить какое‑либо дей­ствие. Напоми­нает сце­нарий CSRF? Да. При этом у CSPT есть осо­бен­ность: сущес­тву­ющие механиз­мы защиты от CSRF-атак (нап­ример, токены) ока­зыва­ются неэф­фектив­ными для решения это­го клас­са проб­лем.

Пос­ле деталь­ного изу­чения этой уяз­вимос­ти рекомен­дую изу­чить тес­товый стенд для экспе­римен­тов и инс­тру­мен­ты для авто­мати­зации поис­ка.

Технологии AutoFix: исправление 2/3 багов с первой попытки

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

• на­ибо­лее зре­лые модели LLM спо­соб­ны испра­вить при­мер­но 2/3 всех обна­ружен­ных уяз­вимос­тей с пер­вой попыт­ки, но под­сказ­ки со сто­роны поль­зовате­ля поз­воля­ют улуч­шить этот резуль­тат;
• у ком­мерчес­ких и откры­тых моделей схо­жие показа­тели про­изво­дитель­нос­ти при раз­ной сто­имос­ти экс­плу­ата­ции.

То есть исполь­зовать AutoFix мож­но, но внед­рять исправ­ленный код в прод без допол­нитель­ной верифи­кации нуж­но акку­рат­нее. Нап­ример, исправ­ление проб­лемы, свя­зан­ной со сла­бым шиф­ровани­ем или исполь­зовани­ем небезо­пас­ных про­токо­лов, может при­вес­ти к сбо­ям в работе при­ложе­ния.

Есть и дру­гие огра­ниче­ния:

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

С уче­том этих огра­ниче­ний раз­работ­чики тех­нологий AutoFix зап­рашива­ют под­сказ­ки у поль­зовате­лей, а так­же ста­рают­ся рас­ширить кон­текст. Поль­зователь может ука­зать пред­почти­тель­ные биб­лиоте­ки (нап­ример, для логиро­вания, алго­рит­мов шиф­рования и генера­ции слу­чай­ных чисел). Повысить точ­ность отве­тов помога­ет и механизм пов­торных попыток. LLM генери­рует нес­коль­ко исправ­лений для одной и той же уяз­вимос­ти и таким обра­зом уве­личи­вает шан­сы на получе­ние пра­виль­ного вари­анта.

Инструмент для поиска проблем в GitHub Actions CI/CD

Мы уже изу­чили сце­нарии атак, в которых мож­но зак­репить­ся в GitHub Actions, выпол­нить про­изволь­ный код и извлечь сек­реты. Озна­коми­лись с рекомен­даци­ями от OWASP по защите про­цес­сов CI/CD. Поняли, что зна­читель­ная часть этих рекомен­даций отда­ется на откуп раз­работ­чику. Но все же наш­ли инс­тру­мент, который поможет ему выявить зна­читель­ную часть уяз­вимос­тей.