Обзор перспективных исследований. Колонка Дениса Макрушина

Атаки на разработчика: уязвимость в отладчике WinDbg

Нач­ну с иссле­дова­ния, которое про­вела наша коман­да Advanced Research Team. Мы об­наружи­ли инте­рес­ную осо­бен­ность в WinDbg, штат­ном средс­тве отладки Windows. Эта осо­бен­ность дает воз­можность запус­кать про­изволь­ный вре­донос­ный код на хос­те раз­работ­чика и под­менять биб­лиоте­ки.

Не самый извес­тный факт, но фор­мат отла­доч­ных сим­волов PDB поз­воля­ет раз­работ­чикам снаб­жать исполня­емые фай­лы не толь­ко кодовы­ми сим­волами и струк­турами, но и информа­цией о мес­тонахож­дении соот­ветс­тву­юще­го исходно­го кода. Механизм носит наз­вание SrcSrv, и из‑за некор­рек­тной обра­бот­ки его нас­тро­ек ата­кующий может пере­опре­делить путь к рас­ширени­ям WinDbg и про­водить ата­ку DLL Hijacking для под­клю­чения про­изволь­ных DLL, в том чис­ле DLL, рас­положен­ных на уда­лен­ном SMB-сер­вере.

По­вер­хность ата­ки:

1. Ата­ка может зат­ронуть окру­жение раз­работ­чика или ана­лити­ка, который работа­ет над при­ложе­нием для Windows.
2. Штат­ный отладчик не обновля­ется авто­мати­чес­ки, поэто­му пот­ребу­ется руч­ное обновле­ние — это усложня­ет про­цесс исправ­ления.
3. Воз­можные пос­ледс­твия: утеч­ка интеллек­туаль­ной собс­твен­ности или ком­про­мета­ция исходно­го кода раз­рабаты­ваемо­го ПО.

В Microsoft под­твер­дили наличие уяз­вимос­ти и под­готови­ли исправ­ление в вер­сии WinDbg 10.0.22621.0 и выше, а так­же в Windows SDK 11.

От­чет дос­тупен на англий­ском язы­ке. Так­же мы раз­работа­ли ути­литу, которая про­веря­ет фай­лы дам­пов и ищет в них ссыл­ки на фай­лы PDB.

Атаки на разработчика: исследования техники Repo Jacking

Repository hijacking (или Repo Jacking) — ата­ка на репози­торий, которая поз­воля­ет получить пол­ный кон­троль над исходны­ми кодами. В резуль­тате ата­кующий может выпол­нить про­изволь­ный код в том кон­тек­сте, где под­клю­чает­ся ата­кован­ный репози­торий.

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

Лег­кая победа для того, кто стре­мит­ся к мас­совому зараже­нию зависи­мос­тей. Имен­но поэто­му иссле­дова­тели нашей коман­ды ART сде­лали сле­дующее:

1. Из­влек­ли все ссыл­ки на GitHub из кода зависи­мос­тей в двух наибо­лее популяр­ных пакет­ных менед­жерах для Python и JavaScript: PyPI и NPM.
2. Уб­рали дуб­ликаты и прос­каниро­вали все ссыл­ки на наличие репози­тория. Все ссыл­ки, вер­нувшие ответ 404, помети­ли как corrupted_links.
3. Все corrupted_links про­вери­ли на воз­можность про­вес­ти ата­ку account takeover (зах­ват акка­унта).

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

Метод поиска n-day-уязвимостей в бинарном коде

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

В допол­нение к уже извес­тным тех­никам добави­лось све­жее иссле­дова­ние, которое нуж­но будет обя­затель­но вос­про­извести: «BinGo: Identifying Security Patches in Binary Code with Graph Representation Learning».

Это край­не занима­тель­ный метод поис­ка security-пат­чей в бинар­ном коде при­ложе­ний. Акту­ален он для тех слу­чаев, ког­да вла­делец при­ложе­ния скры­то исправ­ляет какие‑нибудь уяз­вимос­ти в сво­ем коде без регис­тра­ции CVE или без упо­мина­ния в чен­жло­ге. Метод BinGo поз­воля­ет выяв­лять n-day-уяз­вимос­ти.

Тех­ника осно­вана на пред­став­лении бинар­ного фай­ла в виде Code Property Graph — про­межу­точ­ном пред­став­лении кода, изна­чаль­но раз­работан­ном для ана­лиза его безопас­ности. CPG вклю­чает в себя абс­трак­тное син­такси­чес­кое дерево, граф потока управле­ния и зависи­мос­ти дан­ных.

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

Уро­вень обна­руже­ния security-пат­чей сре­ди про­чих модифи­каций бинар­ного кода — 80,77%. Отлично! Оста­лось подоб­рать инте­рес­ные тар­геты.

Идея: а что, если исполь­зовать этот метод для выяв­ления умыш­ленно оставлен­ных зак­ладок в бинар­никах? Если мы выд­вига­ем гипоте­зу о том, что это воз­можно, то для ее про­вер­ки нам понадо­бит­ся:

1. Най­ти при­мер (сем­плы) модифи­каций кода, которые точ­но явля­ются зак­ладка­ми.
2. Сфор­мировать CFG для подоб­ранных сем­плов.
3. Обу­чить сиам­скую сеть для опре­деле­ния сходс­тва задан­ного CFG с целевым CFG, получен­ным из сем­плов.

Воз­можно, ты читал мою статью «Как про­вес­ти свое пер­вое security-иссле­дова­ние». Мне кажет­ся, про­вер­ка выд­винутой выше гипоте­зы будет отличной темой для такого иссле­дова­ния!

Атака на атакующего: RCE в популярном фреймворке Empire

Те, кто исполь­зовал опен­сор­сный инс­тру­мент Empire для пен­теста и ред­тимин­га, зна­ют о его богатых воз­можнос­тях, которые при­гож­дают­ся при пос­тэкс­плу­ата­ции.