Привет.
Я новенький в дипвебе, но не совсем новенький в ИБ. Хочу создать на данном форуме нечто своего блога в котором буду писать опыт пентеста (а точнее WAPT - web application penetration testing; тестирование веб-приложений на проникновение). Имел опыта баг хантинга в платформе HackerOne и Intigriti (ссылки на профили не стану оставлять по понятным причинам), пока не столкнулся с некоторыми проблемами да и в целом решение погрузится в хакинг у меня изначально было ради пути "black hat".
Я не пентестер в обычном понимании, т.е. я не смогу провести аудит безопасности корпоративной сети, не шарю толком за безопасность Windows/Linux, а основная моя специализация это веб-хакинг.
В данном посте хочу положить старт и рассказать о довольно интересной связке одного логического бага (интересная реализация open redirect) и ряда действий которые привели к захвату аккаунта на одном криптовалютном сайте (естественно всё делалось на своем тестовом аккаунте). Картинок и скриншотов так же не будет.
Для начала думаю стоит разъяснить ряд терминов:
Account takeover - поглощение/захват аккаунта
Open redirect - открытое перенаправление. Например если есть URL типа перенаправляющий на example.com, если вместо example.com подставить свой сайт, например evil.com и произойдет перенаправление на , значит это уязвимость open redirect.
Header - заголовки (в контексте статьи значит заголовки HTTP).
Фаззинг - подстановка/брутфорс пейлоадами.
НАЧНЕМ
Просматривая программы в h1 (hackerone) наткнулся на криптовалютный ресурс и решил проверить основной домен. Сайт показался мне довольно защищенным и даже спустя двое суток тестирования я ничего обнаружить так и не смог за, что мог бы зацепится глаз. И просто уже просто как завершающий этап тестирования решил пофаззить хедеры. Подставлял различные пейлоады и для SQL injection и для XXE injection и XSS и т.д. Фаззил почти все заголовки и User agent и host и origin и заметил интересный ответ когда фаззил заголовок Referer (это то откуда перешел на страницу), т.е. этот заголовок выглядит примерно так:
Referer: https://yandex.ruчто означает, что на данную страницу пользователь перешел с Яндекса.
А ответ сервера был примечателен вот чем: если удалить полностью URL из заголовка реферер и подставить эксплойт для инъекции, например
Referer: order by 1!=1-- jто ответ от сервера выглядел так
302 Redirect in https://yandex.ruorder by 1!=1-- jЗаметили? Сайт решал куда перенаправлять (то бишь редиректить по заголовку реферер и скоро объясню в чем логика) тогда я попробовал удалить яндекс из реферера и подставить другой URL адрес, например и в ответ пришло заветное:
302 Redirect in https://evil.com и меня естественно редиректнуло в evil.com. Bingo!!!Я сразу же побежал сдавать баг обозначив его как Open Redirect, но обломался от ответа стаффа (stаff - сотрудники h1 которые проводят предварительную проверку репортов, что бы не слали всякий мусор) где они спросили -"и какой импакт (влияние) от этого? ты редиректишь самого себя. Найди вариант того как это может заюзать злоумышленник, что бы мы подтвердили твой репорт и передали команде безопасности". Ступор!
Еще почти двое суток гуглежа ушло на нахождение вариантов. Перечитал все российские, немецкие, китайские и индийские статьи и нашел таки одну единственную статью на английском языке от исследователя в которой он нашел похожую уязвимость и сам придумал вектор атаки. И тут начинается самое интересное.
РАЗВЯЗКА И ЗАХВАТ АККАУНТА
Суть использования такой баги заключалась вот в чем: раз сервер решает куда перенаправлять по Рефереру (например вы заходите не авторизовавшись на страницу vk.com/im -т.е. сообщения, вас редиректнет на vk.com/login и сохранит в реферере vk.com/im, что бы после авторизации вернуть в раздел сообщений). Соответственно вот, что надо сделать хакеру:
он создает поддельный сайт в котором имеется ссылка на auth.site.com (т.е. на страницу авторизации). и человек перейдя по ссылке в хедере оставляет сайт злоумышленника и после авторизации его редиректит обратно на сайт хакера. На этом можно было бы остановится если использовать это для банального фишинга - кстати в статье именно это и рассматривалось. Создать очень похожий сайт фишинговый с ссылкой на основной сайт и после авторизации вас редиректит на фишинговый и жертва практически ничего не замечает. Но в моем случае всё было еще круче.
Уязвимость тут заключается вот в чем - авторизация происходит по технологии OAuth - она генерирует ключ в GET запросе, т.е. строке браузера, которая выглядит примерно таким страшным образом
и хакер посмотрев в логи запросы к сайту увидев этот ключ может тупо украсть OAuth токен жертвы и оказаться в аккаунте жертвы. т.е. тут не просто опен редирект, а аккаунт тейк овер, т.е. захват аккаунта.
ЗАКЛЮЧЕНИЕ
Доработанный и заскринованный репорт я сдал повторно, указав весь ход работы. Его приняли. Но дали Duplicate, т.е. кто-то до меня зарепортил эту уязвимость. Согласен ли я с таким решением? - конечно же нет. Доволен ли собой? - однозначно да. Одна эта бага дала значительный прирост мне как хакеру.
На этом у меня всё. Оставляйте отзывы есть ли смысл продолжать писать статьи на такие темы.
Последнее редактирование модератором:
