Од­на из рас­простра­нен­ных уяз­вимос­тей в OAuth воз­ника­ет, ког­да раз­работ­чик неп­равиль­но нас­тра­ивает или срав­нива­ет допус­тимые парамет­ры redirect_uri, поз­воляя зло­умыш­ленни­кам похитить OAuth-токены. Пра­хар Пра­сад информи­ровал ком­панию Slack о том, что он может обой­ти огра­ниче­ния, ука­зан­ные в раз­решен­ном адре­се redirect_uri, за счет добав­ления к нему любых зна­чений. Ины­ми сло­вами, сайт Slack про­верял лишь начало парамет­ра redirect_uri. Если раз­работ­чик регис­три­ровал в Slack новое при­ложе­ние и добав­лял в белый спи­сок https://www.<example>.com, зло­умыш­ленник мог рас­ширить этот URL-адрес и выпол­нить перенап­равле­ние в неп­редви­ден­ное мес­то. Нап­ример, изме­нен­ный адрес вида redirect_uri=https://<attacker>.com откло­нял­ся, но поз­волял передать redirect_uri=https://www.<example>.com.mx.

Что­бы этим вос­поль­зовать­ся, зло­умыш­ленни­ку было дос­таточ­но соз­дать под­ходящий под­домен на сво­ем вре­донос­ном сай­те. Если жер­тва откры­вала заражен­ный URL-адрес, сер­вер Slack переда­вал OAuth-токен сай­ту зло­умыш­ленни­ка. Хакер мог ини­цииро­вать зап­рос от име­ни жер­твы, встро­ив во вре­донос­ную веб-стра­ницу тег <img> вро­де такого:

Это поз­волило бы авто­мати­чес­ки сде­лать HTTP-зап­рос типа GET при отоб­ражении стра­ницы.

Уяз­вимос­ти, свя­зан­ные с недос­таточ­но стро­гой про­вер­кой redirect_uri, явля­ются рас­простра­нен­ным при­мером неп­равиль­ной кон­фигура­ции OAuth. Иног­да это выз­вано тем, что в качес­тве допус­тимого зна­чения redirect_uri регис­три­рует­ся домен вида *.<example>.com. Иног­да при­чина в том, что сер­вер ресур­са не про­водит стро­гую про­вер­ку парамет­ра redirect_uri от начала и до кон­ца. При поис­ке уяз­вимос­тей в OAuth про­веряй­те любые парамет­ры, которые могут учас­тво­вать в перенап­равле­нии.

Прохождение аутентификации с паролем по умолчанию

• 
  Слож­ность: низ­кая


• 
  URL: https://flurry.com/auth/v1/account/
  


• 
  Ис­точник: https://lightningsecurity.io/blog/password-not-provided/
  


• 
  Да­та подачи отче­та: 30 июня 2017 года


• 
  Вып­лачен­ное воз­награж­дение: не раз­гла­шает­ся

По­иск уяз­вимос­тей в любой реали­зации OAuth под­разуме­вает иссле­дова­ние всей про­цеду­ры аутен­тифика­ции, от начала и до кон­ца. Для это­го в том чис­ле необ­ходимо рас­познать HTTP-зап­росы, которые не явля­ются частью стан­дар­тно­го про­цес­са; их наличие час­то сиг­нализи­рует о том, что раз­работ­чик изме­нил механизм аутен­тифика­ции и, воз­можно, сде­лал его уяз­вимым. Джек Кей­бл стол­кнул­ся с подоб­ной ситу­ацией в работе с прог­раммой Bug Bounty от Yahoo, в которую вхо­дил ана­лити­чес­кий сайт Flurry.com.

Что­бы начать тес­тирова­ние, Кей­бл зарегис­три­ровал учет­ную запись на сай­те Flurry, исполь­зуя свой адрес элек­трон­ной поч­ты @yahoo.com и реали­зацию OAuth от Yahoo. Пос­ле того как Flurry и Yahoo сог­ласова­ли OAuth-токен, зак­лючитель­ный POST-зап­рос к сай­ту Flurry выг­лядел так:

Вни­мание Кей­бла прив­лек фраг­мент зап­роса "password":"not-provided". Вый­дя из сво­ей учет­ной записи, он открыл стра­ницу https://login.flurry.com/ и аутен­тифици­ровал­ся не через OAuth, а с помощью поч­тового адре­са и пароля not-provided. Это сра­бота­ло, и Кей­бл смог вой­ти в свою учет­ную запись.

Ког­да поль­зователь регис­три­ровал­ся на сай­те Flurry с помощью сво­ей учет­ной записи Yahoo и про­цеду­ры OAuth, сис­тема соз­давала для него отдель­ную кли­ент­скую учет­ную запись с паролем по умол­чанию not-provided. Кей­бл сооб­щил об уяз­вимос­ти, и проб­лема была устра­нена через пять часов.

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

Похищение токенов для входа на сайт Microsoft

• 
  Слож­ность: высокая


• 
  URL: https://login.microsoftonline.com
  


• 
  Ис­точник: whitton.io/artides/obtaining-tokens-outlook-office-azure-account/
  


• 
  Да­та подачи отче­та: 24 янва­ря 2016 года


• 
  Вып­лачен­ное воз­награж­дение: 13 000 дол­ларов

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

Ком­пания Microsoft вла­деет мно­жес­твом про­ектов, поэто­му зап­росы для аутен­тифика­ции поль­зовате­лей на раз­ных сер­висах нап­равля­ются раз­ным доменам: login.live.com, login.microsoftonline.com или login.windows.net. Эти зап­росы воз­вра­щают поль­зовате­лям сес­сии. Нап­ример, в слу­чае с outlook.office.com про­цеду­ра выг­лядит так:

1. Поль­зователь заходит на сайт https://outlook.office.com.


2. Поль­зователь перенап­равля­ется к https://login.microsoftonline.com/login.srf?wa=wsignin1.0&rpsnv=4&wreply=https%3a%2f%2fbutlook.office.com%2fowa%2f&id=260563.


3. В слу­чае успе­ха по адре­су внут­ри wreply выпол­няет­ся POST-зап­рос с парамет­ром t, который содер­жит токен для поль­зовате­ля.

При попыт­ке поменять wreply на любой дру­гой домен воз­никала ошиб­ка. Уит­тон поп­робовал переда­вать сим­волы с двой­ным кодиро­вани­ем, добав­ляя в конец URL-адре­са %252f, что­бы получить https%3a%2f%2foutlook.office.com%252f. В этом URL-адре­се спе­циаль­ные сим­волы : и / кодиру­ются как %3a и, соот­ветс­твен­но, %2f. Кро­ме того, в исходном адре­се сле­дует закоди­ровать знак про­цен­та (%), что­бы при двой­ном кодиро­вании он прев­ратил­ся в косую чер­ту %252f (кодиро­вание спе­циаль­ных сим­волов обсужда­лось в раз­деле «Раз­деление HTTP-отве­та в Twitter» на с. 77). Ког­да Уит­тон под­ста­вил вмес­то wreply получен­ный URL-адрес, при­ложе­ние вер­нуло ошиб­ку, сооб­щающую, что адрес https://outlook.office.com%f не кор­ректен.

Вслед за этим Уит­тон добавил к домену @example.com и вмес­то ошиб­ки получил https://outlook.office.com%2f@example.com/?wa=wsignin1.0. Дело в том, что URL-адрес име­ет сле­дующую струк­туру: [//[имя_пользователя:пароль@]домен[:порт]][/]путь[?запрос][#фрагмент]. Имя поль­зовате­ля и пароль учас­тву­ют в базовой HTTP-аутен­тифика­ции сай­та. Поэто­му пос­ле добав­ления @example.com домен для перенап­равле­ния боль­ше не выг­лядел как outlook.office.com. Вмес­то это­го поль­зовате­ля мож­но было перенап­равить к любому домену, который кон­тро­лиро­вал­ся зло­умыш­ленни­ком.

По сло­вам Уит­тона, при­чиной этой уяз­вимос­ти было то, что сайт Microsoft выпол­нял декоди­рова­ние и про­вер­ку URL-адре­са в два эта­па. На пер­вом эта­пе сайт про­верял, явля­ется ли домен­ное имя кор­рек­тным и соот­ветс­тву­ет ли оно струк­туре URL-адре­са. Адрес https://outlook.office.com%2f@example.com успешно про­ходил про­вер­ку, пос­коль­ку стро­ка outlook.office.com%2f вос­при­нима­лась как кор­рек­тное имя поль­зовате­ля.

На вто­ром эта­пе сайт рекур­сивно декоди­ровал URL-адрес. Стро­ка
https%3a%2f%2foutlook.office.com%252f@example.com прев­ращалась в https:// outlook.office.com/@example.com, то есть фраг­мент @example.com пос­ле косой чер­ты интер­пре­тиро­вал­ся как часть пути, а домен­ное имя выг­лядело как outlook.office.com.

Сайт Microsoft про­верял струк­туру URL-адре­са, декоди­ровал его и под­тверждал его при­сутс­твие в белом спис­ке. Но в качес­тве отве­та воз­вра­щал­ся адрес, декоди­рован­ный один раз. То есть при посеще­нии такого URL токен жер­твы отправ­лялся сай­ту example.com.

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

В ходе иссле­дова­ния парамет­ров перенап­равле­ния в про­цеду­ре OAuth добавь­те к конеч­ному URI-адре­су @example.com и пос­мотри­те, как поведет себя при­ложе­ние. Это осо­бен­но акту­аль­но, если в про­цес­се аутен­тифика­ции исполь­зуют­ся закоди­рован­ные сим­волы, которые дол­жны быть декоди­рова­ны перед про­вер­кой вхож­дения URL-адре­са в белый спи­сок. Во вре­мя тес­тирова­ния обра­щай­те вни­мание на нез­начитель­ные изме­нения в поведе­нии сай­та.

Похищение официальных токенов доступа на сайте Facebook

• 
  Слож­ность: высокая


• 
  URL: https://www.facebook.com
  


• 
  Ис­точник: philippeharewood.com/swiping-facebook-official-access-tokens/
  


• 
  Да­та подачи отче­та: 29 фев­раля 2016 года


• 
  Вып­лачен­ное воз­награж­дение: не раз­гла­шает­ся

При поис­ке уяз­вимос­тей обра­щай­те вни­мание на ресур­сы инте­ресу­юще­го вас при­ложе­ния, о которых раз­работ­чики мог­ли забыть. Филип­пе Хэй­рвуд пос­тавил перед собой цель: похитить токен поль­зовате­ля Facebook и получить дос­туп к его кон­фиден­циаль­ной информа­ции. Одна­ко ему не уда­лось най­ти никаких оши­бок в реали­зации OAuth на сай­те Facebook. Не отча­явшись, он поменял свой план и начал искать при­ложе­ние Facebook, которое мож­но зах­ватить как под­домен.

Он знал, что Facebook вла­деет при­ложе­ниями, которые авто­мати­чес­ки авто­ризу­ются с помощью OAuth, исполь­зуя учет­ные записи этой плат­формы. С их спис­ком мож­но было озна­комить­ся на стра­нице https://www.facebook.com/search/me/apps-used/.

В спис­ке Хэй­рвуд нашел один про­ект, который по-преж­нему был авто­ризо­ван, хотя ком­пания Facebook им боль­ше не вла­дела и не исполь­зовала его домен. Это озна­чало, что Хэй­рвуд мог зарегис­три­ровать одоб­ренное домен­ное имя в качес­тве парамет­ра redirect_uri и получить токен любого поль­зовате­ля Facebook, который посещал конеч­ную точ­ку авто­риза­ции OAuth:

В этом URL-адре­се иден­тифика­тор уяз­вимого при­ложе­ния обоз­начен в виде парамет­ра APP_ID, который пре­дос­тавлял дос­туп ко всем областям видимос­ти OAuth. Домен, вхо­див­ший в белый спи­сок, обоз­начен как REDIRECT_URI (Хэй­рвуд не уточ­нил, какое имен­но при­ложе­ние было неп­равиль­но скон­фигури­рова­но). Пос­коль­ку при­ложе­ние уже было авто­ризо­вано для каж­дой учет­ной записи Facebook, при щел­чке по этой ссыл­ке поль­зовате­лю не нуж­но было под­тверждать зап­рашива­емые области видимос­ти. Кро­ме того, вся про­цеду­ра OAuth выпол­нялась пос­редс­твом фоновых HTTP-зап­росов. Открыв этот URL-адрес для аутен­тифика­ции на сай­те Facebook, поль­зователь перенап­равлял­ся к стра­нице с подоб­ным адре­сом http://REDIRECT_URI/#token=сюда_добавлялся_токен/.

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

При поис­ке уяз­вимос­тей обра­щай­те вни­мание на ресур­сы, о которых мог­ли забыть вла­дель­цы сай­та. Иног­да это могут быть записи CNAME для под­доменов и зависи­мос­ти при­ложе­ний, такие как Ruby Gems, биб­лиоте­ки jаvascript и т. д. Перед началом тес­тирова­ния ставь­те перед собой чет­кую цель. В ходе иссле­дова­ния круп­ного при­ложе­ния это поз­волит не отвле­кать­ся на про­вер­ку его бес­числен­ных аспектов.

Итоги

Нес­мотря на то что про­цеду­ра аутен­тифика­ции OAuth явля­ется стан­дарти­зиро­ван­ной, раз­работ­чики могут допус­тить ошиб­ку в ее кон­фигура­ции. Неоче­вид­ные уяз­вимос­ти поз­воля­ют зло­умыш­ленни­ку похитить токены авто­риза­ции и получить дос­туп к кон­фиден­циаль­ным дан­ным жер­твы. Иссле­дуя при­ложе­ния с под­дер­жкой OAuth, тща­тель­но иссле­дуй­те параметр redirect_uri, что­бы понять, нес­коль­ко кор­рек­тно при­ложе­ние его про­веря­ет при отправ­ке токенов. Ищи­те нес­тандар­тные механиз­мы аутен­тифика­ции на осно­ве про­цеду­ры OAuth, которые под­верже­ны уяз­вимос­тям. Если вам не уда­ется най­ти ничего подоз­ритель­ного, не забудь­те про­верить одоб­ренные ресур­сы. Воз­можно, раз­работ­чики забыли о каком-то при­ложе­нии, которо­му кли­ент доверя­ет по умол­чанию.

Теги: CSS