10 способов угнать аккаунт

Один из моих любимых багов - account takeover. Это логический баг, а значит кол-во различных вариантов его может быть бесконечно. Дайте 10 разработчикам задание написать один и тот же сайт - каждый напишет по разному. В этой статье описаны 10 самых распространенных способов угона аккаунта.

Логический баг OAuth (повторный эмайл)

Эксплуатация этого бага возможна в том случае, если на сайте присутствует вход через социальные сети и если хотя бы в одной из них нет подтверждения почты. Я репортил этот баг для одного из поддоменов QIWI - https://hackerone.com/reports/439207. Суть заключается в том, что в OAuth сервисе нужно было зарегистрировать аккаунт с почтой, которая существует на атакуемом сайте, а потом просто войти.

CSRF на смену пароля / CSRF на смену почты

Самый дефолтный вариант угнать аккаунт - это заюзать CSRF. Если на сайте нет поля где нужно вводить старый пароль перед установкой нового, то есть большие шансы проэксплуатировать эту дыру. В свою очередь, если со сменной пароля не получилось, то можно поменять почту, привязанную к аккаунту, и потом попробовать восстановить пароль. Максимально простые дыры и в то же время, как правило, хорошо оплачиваются. В багбаунти сейчас такое найти почти нереально, все такие дыры давно уже вынесли и поэтому шансов мало. 

Баги OAuth

При авторизации через социальные сети часто можно найти параметр return_url. Тогда можно попробовать угнать чужой токен от авторизации и потом в своем браузере авторизоваться с помощью него. Мы просто подменяем параметр, даем пользователю ссылку и после авторизации его редиректит на и на наш сайт прямо с токеном в GET параметре.

Ну и другой вариант, если на сайте в профиле существует привязка аккаунта, то можно попробовать проэксплуатировать CSRF и там. Производим процедуру привязки своего аккаунта и дропаем последний запрос, отвечающий за, собственно, саму привязку. Обычно это GET-запрос и он летит в самый последний момент. Посылаем пользователю ссылочку и наш аккаунт, например от ВКонтакте, привязывается к чужому профилю. Вот именно эта CSRF и встречается чаще всего, намного чаще чем CSRF описанные выше. Дело в том , что разработчики часто не особо углубляются в механизм авторизации через соцсети, потому-что думают что там итак все защищено нормально. Некоторые забывают параметр state и это приводит к вышеописанной проблеме.

Кража аккаунта при восстановлении

Тут тоже много логических сценариев, как правило. Первое что нужно сделать - запросить ссылку на восстановление. Запрашиваем ее на свою почту и уже идем копать дальше. Для каждого сайта остается строго индивидуально, какая ссылка прилетит на почту в конечном итоге - заранее не угадаешь. Так вот, мы получили ее для себя, однако в ссылке могут существовать параметры которые можно подменять. Очень часто мы можем наблюдать какой-то токен, который зашифрован например в base64. Если расшифровать его, то, как правило, там можно увидеть электронный почтовый адрес пользователя и еще какую-то информацию типо подписи. Подмена почты пользователя в таком токене имеет смысл, в этом случае мы просто поменяем пароль на на чужом аккаунте.

Конкретных советов тут дать действительно сложно, потому-что логические сценарии как правило индивидуальны. Фактом остается то, что такие места обязательно стоит проверять. Дыры как правило лежат на поверхности.

Брутфорс

Ну тут все максимально просто, но темнеменее это один из крутых репортов за которые можно получить большую награду. 1500$ за брут - легко. Можно брутить пароли, OTP, да все что угодно. В своем репорте https://hackerone.com/reports/691698 мне удалось сбрутить confirmation token id и таким образом попасть в чужой аккаунт. Дали всего $300 из-за того что эксплуатация брутфорс уязвимостей крайне затруднительна. Не игнорируйте брут, когда багхантите. Это может принести вам много денег)

Подмена номера

Если авторизация идет по номеру телефона, то, как правило, она идет в два этапа и в два запроса. Первый этап - ввод номера и отправка смс, а второй этап - ввод полученного OTP кода. Тут часто встречаются логические баги, позволяющие красть аккаунт на втором этапе такой авторизации. В моем репорте https://hackerone.com/reports/685304 сессионная кука генерировалась на первом этапе, а после ввода кода подтверждалась. Я мог принять смс на свой номер и подтвердить чужую куку, тем самым украсть аккаунт. Похожая ситуация была и в этом репорте https://hackerone.com/reports/484160, здесь просто можно было поменять номер на втором этапе и войти в чужой аккаунт.

Повторная регистрация аккаунта

История из жизни: однажды мне удалось угнать аккаунт, просто зарегистрировав его повторно. Я нашел одну из старых форм регистрации на сайте (уже не используемую) и после того как я указывал там существующий в базе данных адрес электронной почты и пароль, то меня просто закидывало в чужой аккаунт. Вывод заключается в том, что поиск старых форм / старого функционала актуален для эксплуатации account takeover уязвимостей.

Однако, если такие манипуляции все-таки невозможны, то имеет смысл пробовать регистрировать аккаунты типа example()@hackmail.com и ()example@hackmail.com при условии что аккаунт example@hackmail.com существует на сайте, ну то есть использовать комментарии в адресе электронной почты. Неизвестно как поведет себя сайт в этом моменте, но иногда такие аккаунты можно регистрировать.

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

Сам я сталкивался лишь с возможностью регистрации аккаунтов на почты такого типа, но докрутить это до account takeover у меня не удавалось. Но при этом я слышал от других хакеров, что это возможно.

Уязвимости типа IDOR

Я люблю искать IDOR'ы. Найденный с помощью такой уязвимости account takeover 100% будет оценен по достоинству. Сценариев тут тоже очень много. Предположим, что вы меняете пароль и в запросе видите id пользователя - попробуйте подменить id и поменяйте пароль у чужого аккаунта. Один из сценариев с которым я сталкивался в багбаунти заключался в том, что в функционале смены пароля присутствовал IDOR, однако нужно было знать старый пароль пользователя чтобы установить ему новый. Не смотря на это уязвимость оценили в $300, потому-что в этом функционале не было никакой защиты от брута. Помимо пароля можно менять также и почту (вспоминаем CSRF)

Фиксация сессии

Сценарий заключается в том, что наша сессионная кука должна быть подставлена в браузер жертвы. Как это сделать - другой вопрос. CRLF, XSS или еще что-то - на ваше усмотрение. Потом, когда мы уже имеем с жертвой одинаковую куку, то нам нужно дождаться того момента, когда она авторизуется на сайте с нашей кукой. Так как куки одинаковые, то нас закинет в аккаунт жертвы. Обычно факта фиксации сессии достаточно для получения баунти, но некоторые программы требуют полный сценарий эксплуатации. От этого зависит размер баунти.

Часто эта штука работает с кукой PHPSESSID, но не исключено что будет работать и с другими куками. Проверяйте)

Уязвимости серверного кеша

Для уменьшения нагрузки на сервера сайты часто прибегают к использованию кеша. Достать оттуда страницу намного проще, чем генерировать ее заново. Если вся эта система сконфигурирована неправильно, то можно попробовать передать пользователю ссылку типа https://hack.ер/cabinet/1.css. Есть шанс что она попадет в серверный кеш и вы сможете перейдя по этой ссылке получить страницу, которая была загружена от имени определенного пользователя. Как докручивать это до account takeover - другой вопрос, но пару векторов я вам дам. Первый вектор - извлечение CSRF токена из кода страницы и эксплуатация CSRF уязвимостей против пользователей. Вроде токены и есть, но проэксплуатировать уязвимость возможно. Другой вариант - переменные в коде страницы, например данные от чата с техподдержкой.

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

Информация представлена в строго образовательных целях. Помните, что любое использование описанных здесь векторов в нехороших целях может спровоцировать проблемы с законом. Удачного багхантинга!