Adversary-in-the-Middle: эволюция фишинга

Ти­пич­ный сце­нарий соци­отех­ничес­кого пен­теста: соб­рал спи­сок кор­поратив­ных email-адре­сов, нас­тро­ил инс­тру­мент для про­веде­ния фишин­говых рас­сылок, про­вел рас­сылку, получил учет­ные дан­ные сот­рудни­ков для дос­тупа в кор­поратив­ную инфраструк­туру.

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

MFA не дает ата­кующе­му вос­поль­зовать­ся укра­ден­ной учет­кой, потому что для дос­тупа к дан­ным тре­бует­ся вто­рой фак­тор, который оста­ется у сот­рудни­ка. Для обхо­да средств MFA ата­кующий смес­тил фокус с кра­жи пароля на кра­жу поль­зователь­ской сес­сии. Так появи­лись ата­ки Adversary-in-the-Middle (AitM).

Тех­ники AitM осно­ваны на исполь­зовании прок­си‑инс­тру­мен­тов, сто­ящих меж­ду жер­твой и пор­талом для логина (нап­ример, SSO-пор­талом: Okta, Google Workspace и так далее). То есть поль­зователь видит реаль­ную стра­ницу для логина, но где‑то меж­ду поль­зовате­лем и этой стра­ницей ата­кующий получа­ет под свой кон­троль поль­зователь­скую сес­сию. И даже не нуж­но красть пароль от учет­ной записи, потому что поль­зователь­ские сес­сии могут оста­вать­ся активны­ми боль­ше месяца.

Материал подготовлен для авторской колонки в журнале “Хакер”

ЧЕЙ-ТО БРАУЗЕР ПОСЕРЕДИНЕ: ИНСТРУМЕНТЫ BITM-ФИШИНГА

Для про­веде­ния AitM-фишин­га сущес­тву­ют две основные тех­ники: Browser-in-the-Middle (BitM) и Reverse Web Proxy.

Тех­ника «бра­узер посере­дине» осно­вана на интегра­ции инфраструк­туры ата­кующе­го в соеди­нение меж­ду бра­узе­ром жер­твы и целевым веб‑при­ложе­нием. Как толь­ко жер­тва перей­дет по фишин­говой ссыл­ке, ата­кующий нап­равит ее бра­узер на свою плат­форму, которая будет перенап­равлять все зап­росы к ори­гиналь­ному веб‑ресур­су. И заод­но перех­ватывать дан­ные в этом соеди­нении.

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

1. Кас­томизи­рован­ный бра­узер с минималь­ным GUI, что­бы не отвле­кать поль­зовате­ля необыч­ными эле­мен­тами интерфей­са. Для это­го час­то исполь­зует­ся Chromium, раз­верну­тый на базе дис­три­бути­ва с Fluxbox.
2. VNC-сер­вер, который обес­печива­ет дос­туп к бра­узе­ру ата­кующе­го и уста­нав­лива­ется в его инфре.
3. VNC-кли­ент. Нап­ример, noVNC. Работа­ет в кон­тек­сте бра­узе­ра жер­твы и под­клю­чает­ся к VNC-сер­веру. Под­клю­чение про­исхо­дит с помощью набора JS-скрип­тов и кода HTML5 и не тре­бует уста­нов­ки допол­нитель­ных модулей.

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

Вот набор ути­лит, которые упростят про­веде­ние BitM-атак для Red Team:

• EvilnoVNC — с при­мене­нием Docker поз­воля­ет быс­тро раз­вернуть все ком­понен­ты плат­формы для про­веде­ния BitM-атак;
• CuddlePhish — ана­логич­ная плат­форма, но на базе тех­нологии WebRTC.

Blue Team, готовь детек­ты!

ОБХОД МНОГОФАКТОРНОЙ АУТЕНТИФИКАЦИИ С ПОМОЩЬЮ REVERSE WEB PROXY

Ог­раниче­ния BitM-атак не поз­воля­ют исполь­зовать эту тех­нику для мас­сового фишин­га. Ког­да кон­тент отоб­ража­ется в бра­узе­ре через про­токо­лы уда­лен­ного дос­тупа, поль­зовате­лю дос­таточ­но изме­нить раз­мер окна бра­узе­ра, что­бы заметить что‑то подоз­ритель­ное в отоб­ражении стра­ницы. А еще в кор­поратив­ной сети у Blue Team могут быть детек­ты скрип­тов noVNC. Поэто­му BitM хорошо под­ходит для точеч­ных атак, но не годит­ся для широко­го при­мене­ния.

Тех­ника Reverse Web Proxy осно­вана на исполь­зовании инс­тру­мен­тов, которые перенап­равля­ют HTTP-зап­росы от бра­узе­ра жер­твы к ресур­су через прок­си‑сер­вер ата­кующе­го.

Инс­тру­мен­ты для реали­зации со схо­жими воз­можнос­тями:

• Evilginx — пожалуй, самый популяр­ный фрей­мворк, написан­ный на Go. Под­нима­ет свой HTTP- и DNS-сер­вер для перех­вата учет­ных записей и поль­зователь­ских сес­сий для обхо­да MFA.
• Modlishka — ана­логич­ный инс­тру­мент, раз­работ­чик которо­го опи­сыва­ет свое решение как «point-and-click», то есть его прос­то нас­тро­ить и авто­мати­зиро­вать.
• Muraena.
• CredSniper.

Для защиты от этой тех­ники раз­работ­чик веб‑при­ложе­ния с MFA дол­жен исполь­зовать допол­нитель­ные меры. Нап­ример, добавить в свое при­ложе­ние код на JS для про­вер­ки легитим­ности домена, который заг­ружа­ет стра­ницу.

Как защититься: расставляем ловушки с помощью JS- и CSS-канареек

При основном сце­нарии фишин­говых атак с обратным прок­си ата­кующий дела­ет сле­дующее:

1. Ре­гис­три­рует домен­ное имя, похожее на домен­ное имя целево­го веб‑пор­тала, который жер­тва исполь­зует для логина.
2. Раз­меща­ет на фишин­говом домене прок­си и перенап­равля­ет со сво­его домена все зап­росы от бра­узе­ра поль­зовате­ля к целево­му ресур­су и обратно.
3. Пе­рех­ватыва­ет весь про­цесс аутен­тифика­ции и извле­кает из HTTP-зап­росов цен­ные дан­ные: пароли и сес­сион­ные куки.
4. Ис­поль­зует перех­вачен­ные сес­сион­ные куки для обхо­да муль­тифак­торной аутен­тифика­ции.

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

Ис­поль­зование обратно­го прок­си меж­ду бра­узе­ром поль­зовате­ля и пор­талом MFA мож­но обна­ружить с помощью скрип­та на JS, встро­енно­го в веб‑стра­ницу. Этот скрипт может играть роль канарей­ки и сиг­нализи­ровать вла­дель­цу MFA-при­ложе­ния и ана­лити­ку Blue Team о попыт­ке фишин­га:

1. Жер­тва откры­вает фишин­говую ссыл­ку, и в бра­узе­ре сра­баты­вает скрипт на JS.
2. Скрипт опре­деля­ет кон­текст, в котором исполня­ется (нап­ример, URL), и сопос­тавля­ет акту­аль­ное домен­ное имя с ожи­даемым.
3. В слу­чае несов­падения кон­тек­ста скрипт отправ­ляет сиг­нал на сер­вер Blue Team.

Де­лаем похожую канарей­ку на CSS:

1. Для невиди­мого гла­зу изоб­ражения (пик­сель) соз­даем атри­бут url(), который отправ­ляет обра­щение сер­веру Blue Team.
2. В HTTP-заголов­ке обра­щения переда­ется зна­чение Referer.
3. В слу­чае несов­падения зна­чения Referer с тем, что мы задали, отправ­ляем сиг­нал ана­лити­ку Blue Team.

До­бав­ляем в белый спи­сок адре­сов раз­личные CDN и ждем сиг­налы.

ВЫЯВЛЯЕМ ФИШИНГОВЫЕ РЕСУРСЫ С ПОМОЩЬЮ НЕЧЕТКОГО ХЕШИРОВАНИЯ

Раз­витие инс­тру­мен­тов про­веде­ния фишин­говых атак при­водит к рос­ту чис­ла ресур­сов, которые цеп­ляют поль­зователь­ские и кор­поратив­ные учет­ные дан­ные. При этом сущес­тву­ет мно­го эффектив­ных методов выяв­ления этих инс­тру­мен­тов (фиш‑китов): от ана­лиза струк­туры веб‑стра­ниц до при­мене­ния алго­рит­мов глу­боко­го обу­чения.

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

Эф­фектив­ность метода доказа­ли на при­мере извес­тных фиш‑китов и стра­ниц, которые замече­ны в популяр­ных тар­гетиро­ван­ных ата­ках. Иссле­дова­тели вычис­лили нечет­кий хеш (TLSH) для DOM-дерева получен­ной веб‑стра­ницы, срав­нили ее с хешем ранее замечен­ной фишин­говой стра­ницы и таким обра­зом обна­ружи­ли угро­зу.

Ес­ли дума­ешь, как еще улуч­шить свой метод поис­ка угроз и ано­малий, то не спе­ши прик­ручивать ИИ. Со мно­гими задача­ми по‑преж­нему работа­ют алго­рит­мы «до эры ML».