OAuth от и до. Ищем цепочки уязвимостей при атаках на авторизацию

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

Что будет, если не проверять redirect_uri

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

При­ложе­ние на пер­вом эта­пе авто­риза­ции по OAuth, или, в тер­миноло­гии спе­ки, эта­пе Authorization Request, фор­миру­ет ссыл­ку и ука­зыва­ет в качес­тве это­го парамет­ра под­кон­троль­ный ему эндпо­инт.

Ког­да ты вхо­дишь через Discord на сайт Midjourney, ссыл­ка выг­лядит при­мер­но так:

В этом зап­росе говорит­ся о том, что в кон­це флоу сер­вер авто­риза­ции не толь­ко выда­ет код, но и дол­жен вер­нуть поль­зовате­ля на сайт при­ложе­ния midjourney.como/auth2/authorize.

По‑хороше­му в парамет­ре redirect_uri дол­жен быть вай­тлист ссы­лок, на которые мож­но редирек­тить. Такие ссыл­ки обыч­но ука­зыва­ет вла­делец при­ложе­ния, ког­да его регис­три­рует. Это поз­воля­ет обру­бать зап­рос, если кто‑то под­ста­вит свой redirect_uri.

Ес­ли вай­тлис­та нет, это соз­дает прос­транс­тво для манипу­ляций. Зло­умыш­ленник может взять ссыл­ку из пер­вого эта­па и заменить в ней redirect_uri под­кон­троль­ным ему сер­висом, выложить ее где‑нибудь в соци­аль­ных сетях и украсть токен пос­ле того, как кто‑нибудь уже авто­ризо­ван­ный в Discord и в Midjourney перей­дет по ней (то же спра­вед­ливо и для дру­гих пар при­ложе­ний и OAuth-про­вай­деров).

Сей­час мы раз­берем это под­робнее на реаль­ном при­мере.

Лаба: OAuth account hijacking via redirect_uri

• Ла­бора­тор­ная работа на сай­те PortSwigger

Стар­туем и ока­зыва­емся на глав­ной стра­нице со стран­ной кар­тинкой.

Как и рань­ше, про­ходим весь флоу с логином, что­бы соб­рать все зап­росы и спо­кой­но про­ана­лизи­ровать их. Заходим под акка­унтом wiener.

И ока­зыва­емся в лич­ном кабине­те.

Флоу авто­риза­ции прой­ден, перехо­дим в Burp. Находим Authorization Request (тот зап­рос на сер­вер авто­риза­ции, на который нас перенап­равило при­ложе­ние) и отправ­ляем его в Repeater.

Имен­но в этой ссыл­ке есть уяз­вимый redirect_uri, который мы и будем экс­плу­ати­ровать.

Уяз­вимость зак­люча­ется в том, что в при­ложе­нии сер­вера авто­риза­ции дол­жным обра­зом (вооб­ще никак) не про­веря­ется redirect_uri. А это зна­чит, что, под­менив его, мы можем нап­равить поль­зовате­ля на собс­твен­ную стра­ницу, что­бы залоги­ровать чужой токен.

Пос­мотрим, как это про­исхо­дит на прак­тике. Меня­ем в нашем зап­росе тот URI, который был ука­зан, на адрес экс­пло­ит‑сер­вера. Он выда­ется в лабора­тори­ях вро­де этой, и его мож­но най­ти в вер­хнем меню.

Пе­рехо­ди туда, копируй ссыл­ку и встав­ляй ее в качес­тве парамет­ра redirect_uri.

У меня это выг­лядит так.

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

Ниг­де ничего вво­дить уже не надо (так как мы уже вош­ли на всех сай­тах и дали сог­ласие), прос­то ты про­шел цепоч­ку редирек­тов, и вот уже токен залоги­рован на нашем экс­пло­ит‑сер­вере или сер­вере зло­умыш­ленни­ка.

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

У меня получи­лось так.

Встав­ляем HTML-раз­метку в поле Body и сох­раня­ем кноп­кой Store.

Те­перь у нас есть стра­ница, на которую может зай­ти адми­нис­тра­тор, и тог­да мы укра­дем его учет­ку. При посеще­нии стра­ницы про­изой­дет цепоч­ка редирек­тов для авто­риза­ции. Пос­коль­ку он уже залоги­нен в соци­аль­ной сети, в кон­це кон­цов он будет перенап­равлен на наш сер­вер, где мы и залоги­руем его OAuth-токен из URL.

На­жима­ем Deliver exploit to victim. В зависи­мос­ти от наг­рузки на сер­веры PortSwigger зап­рос может прий­ти с неболь­шой задер­жкой. Мне приш­лось подож­дать нес­коль­ко минут (в течение которых я жал одну и ту же кноп­ку), и в кон­це кон­цов мне при­лете­ло нес­коль­ко десят­ков зап­росов с токеном адми­нис­тра­тора.

Ко­пиру­ем пос­ледний при­шед­ший токен и встав­ляем в зап­рос /oauth-callback. Если все прой­дет нор­маль­но, сер­вер дол­жен отдать куки и показать, что мы залоги­нены. Так и про­изош­ло. Появи­лась ссыл­ка на панель адми­нис­тра­тора, а это зна­чит, что мы не прос­то заш­ли, а заш­ли как админ.

За­ходим через бра­узер, уда­ляем поль­зовате­ля carlos и нас­лажда­емся победой над еще одной лабой.

Злоупотребление открытым редиректом в связке с OAuth

Да­вай крат­ко вспом­ним, что вооб­ще такое Open Redirect.

Нап­ример, у нас есть сайт Google. Он не нуж­дает­ся в пред­став­лении, у него боль­шой кре­дит доверия, и все ком­пании счи­тают, что домен google.com безопас­ный, поэто­му дают ему некото­рые пос­лабле­ния, добав­ляя в собс­твен­ные белые спис­ки.

Но если зло­умыш­ленни­ки най­дут на нем Open Redirect, то они смо­гут вос­поль­зовать­ся этим довери­ем и исполь­зовать его, что­бы соз­дать ссыл­ку на собс­твен­ный C2-сер­вер, обхо­дя детек­тирова­ние некото­рых анти­виру­сов.

Вот при­мер такой ссыл­ки:

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

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

К при­меру, сайт может про­верять, что redirect_uri начина­ется толь­ко с https://example.com. Если на этом example.com получит­ся най­ти Open Redirect, то мож­но будет и прой­ти про­вер­ку, и экс­плу­ати­ровать уяз­вимость, что­бы украсть токен через OAuth.

Лаба: Stealing OAuth access tokens via an open redirect

• Ла­бора­тор­ная работа на сай­те PortSwigger

Как всег­да, откры­ваем лабора­торию и попада­ем на глав­ную стра­ницу бло­га.

Ло­гиним­ся через соци­аль­ную сеть.

Смот­рим исто­рию зап­росов, берем Authorization Request и пыта­емся пов­торить трюк из пре­дыду­щей лабы — для это­го заменя­ем redirect_uri каким‑нибудь сво­им, нап­ример адре­сом экс­пло­ит‑сер­вера.