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

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

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

В итоге, с малой надеждой на какой либо результат, я начал искать пути эксплуатации потенциальной уязвимости.
Немного поразмыслив, я нашел решение первой из трёх вышеперечисленных задач. Предлагаю читателю тоже подумать над этой задачкой. У нас есть, на первый взгляд, относительный путь /path/to/some/page, который добавляется к домену сайта http://ift.tt/1IejHNk и в итоге получается адрес http://ift.tt/1HEhuHR. Как нам сформировать урл со сторонним доменом? Кто догадался, может поставить себе плюсик за сообразительность. Кто хочет узнать ответ, читает дальше. Так вот, если мы вместо /path/to/some/page добавим .some.domain.com, то получится ссылка для переадресации вида http://ift.tt/1IejKc9

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

Для выполнения пункта 2 я попробовал авторизоваться в интернет-банк не с адреса http://ift.tt/1IejHNk, а с http://ift.tt/1HEhvvh. И о чудо, сервер произвел двухфакторную авторизацию и в итоге перенаправил меня сперва на адрес http://ift.tt/1IejKcb, а потом на http://ift.tt/1HEhuHR. Мне осталось разлогиниться и авторизовать с адреса
http://ift.tt/1HEhvvj. Сделав это, меня перекинуло на адрес http://ift.tt/1IejHNo, таким образом пункт 3 выполнился автоматически. Зачем данный токен использовался в редиректах при авторизации, я так и не понял, но в итоге я имел возможность по ссылке http://ift.tt/1HEhuY5 авторизоваться с любого компьютера без ввода логина, пароля и смс.

Mission completed.

А что дальше? А дальше регистрируем домен второго уровня, например como.wtf, распространяем в Интернете ссылку http://ift.tt/1IejHNs и получаем доступ к чужим аккаунтам в интернет-банке благодаря пересылке авторизационных токенов на http://ift.tt/1HEhuY7

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

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

This entry passed through the Full-Text RSS service - if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.