Угнать за 9 символов

- КиТ :: Будь в СЕТИ!

Сегодня я расскажу вам историю об уязвимости, которая существовала в одном интернет-банке много лет

Её эксплуатация была настолько элементарной, а опасность была настолько не очевидна, что ни кто так и не обратил на неё внимание.

С этим банком у меня была договорённость о поиске уязвимостей и все мои действия были санкционированными. В тот вечер я уже потратил приличное время на поиск более-менее критичной уязвимости и так не найдя ничего стоящего, было уже отчаялся. Но тут мой взгляд зацепился за один параметр в череде запросов к серверу в момент авторизации. К слову, этот банк использовал передовую и очень надежную технологию авторизации, а именно двухфакторную авторизацию через смс. Так вот, параметр GET запроса, на который я обратил внимание, имел вид: go=/path/to/some/page и формировался на стороне сервера для дальнейшей переадресации. Но проблемой было то, что путь для переадресации был относительным и добавлялся к домену сайта и поэтому я игнорировал этот запрос в своих предыдущих исследованиях. К тому же, что бы в нем существовала потенциальная уязвимость, должен был иметь место ряд факторов, а именно:

1). возможность при помощи значения параметра go обеспечить переадресацию на сторонний домен

2). возможность на клиенте задавать значение этого параметра

3). и наконец, после авторизации при редиректе на сторонний домен должна передаться какая нибудь ценная информация

В итоге, с малой надеждой на какой либо результат, я начал искать пути эксплуатации потенциальной уязвимости.

Немного поразмыслив, я нашел решение первой из трёх вышеперечисленных задач. Предлагаю читателю тоже подумать над этой задачкой. У нас есть, на первый взгляд, относительный путь /path/to/some/page, который добавляется к домену сайта https://internet-bank.com и в итоге получается адрес https://internet-bank.com/path/to/some/page. Как нам сформировать урл со сторонним доменом? Кто догадался, может поставить себе плюсик за сообразительность. Кто хочет узнать ответ, читает дальше. Так вот, если мы вместо /path/to/some/page добавим .some.domain.com, то получится ссылка для переадресации вида https://internet-bank.com.some.domain.com

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

Для выполнения пункта 2 я попробовал авторизоваться в интернет-банк не с адреса https://internet-bank.com, а с https://internet-bank.com?go=/path/to/some/page. И о чудо, сервер произвел двухфакторную авторизацию и в итоге перенаправил меня сперва на адрес https://internet-bank.com/path/to/some/page/?token=37C853F2CA868D819BD9514C3CCEB, а потом на https://internet-bank.com/path/to/some/page. Мне осталось разлогиниться и авторизовать с адреса

https://internet-bank.com?go=.some.domain.com. Сделав это, меня перекинуло на адрес https://internet-bank.com.some.domain.com?token=37C853F2CA868D819BD9514C3CCEB, таким образом пункт 3 выполнился автоматически. Зачем данный токен использовался в редиректах при авторизации, я так и не понял, но в итоге я имел возможность по ссылке https://internet-bank.com?token=37C853F2CA868D819BD9514C3CCEB авторизоваться с любого компьютера без ввода логина, пароля и смс.

Mission completed.

А что дальше? А дальше регистрируем домен второго уровня, например como.wtf, распространяем в Интернете ссылку https://internet-bank.com?go=o.wtf и получаем доступ к чужим аккаунтам в интернет-банке благодаря пересылке авторизационных токенов на https://internet-bank.como.wtf

В итоге получается, что для того, что бы иметь возможность угнать чужой аккаунт, нам достаточно добавить к совершенно безопасному адресу сайта интернет-банка всего 9 символов зловредного кода: "?go=o.wtf"

А для себя я сделал следующий вывод: если есть хоть малейшая вероятность существования потенциальной уязвимости, её нужно устранять.

ПодпискаБудь в СЕТИ! Новости социальных сетей - всегда актуальное
 
Группы: ВК | OK | Tg