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

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

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

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

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


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

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

Mission completed.

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


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

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