В данной статье мы на реальных примерах рассмотрим поиск уязвимостей в функции сброса паролей на различных сайтах. Итогом такой атаки будет полный контроль над нужной нам учеткой.
Всем салют, дорогие друзья!
В данной статье мы на реальных примерах рассмотрим поиск уязвимостей в функции сброса паролей на различных сайтах.
✅ Успешным итогом такой атаки будет полный контроль над нужной нам учеткой.
Как устроена функция сброса пароля?
Для каждого разработчика, реализация функции сброса пароля является интересной частью. Здесь он разрабатывает логику, а затем реализует ее в коде. Не существует четко определенного отраслевого стандарта о том, как реализовать функцию безопасного сброса пароля в вашем приложении. Таким образом, у каждого приложения есть свой способ сделать это, например, с помощью электронной почты, уникальных URL-адресов, временных паролей, контрольных вопросов, одноразовых паролей и т. д.
Вот список наиболее часто используемых способов:
Электронное письмо с уникальным URL-адресом для сброса пароля
Электронное письмо, отправленное с временным паролем или текущим паролем
Использование секретные вопросов, а затем предоставление возможности сброса пароля
Использование OTP (одноразовых паролей) или многофакторной аутентификации
Эксплуатация функции сброса пароля
Использование OTP (одноразовых паролей) или многофакторной аутентификации.жет привести к ошибкам с высокой степенью серьезности, таким как захват учетной записи, а также к менее серьезным, таким как слабая реализация токена. Давайте посмотрим на некоторые из них:.
1. Утечка токена из-за отравления заголовка хоста.
Злоумышленник изменяет заголовок хоста в запросе, чтобы сбросить пароль цели на свой собственный домен.
GET https://redacted.com/reset.php?email=foo@bar.com HTTP/1.1
Host: evil.com Доверяя компании, жертва естественно нажимает на ссылку сброса. Поскольку ссылка формируется с помощью заголовка хоста, то вместо легального сайта, она ведет на веб-сайт злоумышленника. Когда цель посещает этот сайт, ее токен сброса пароля отправляется злоумышленнику. Теперь злоумышленник сбрасывает пароль цели, используя её токен.
🌐 Приводим реальные примеры подобных уязвимостей:
2. Отправка массива адресов электронной почты вместо одного адреса электронной почты.
В этой атаке злоумышленник может отправить ссылку для сброса пароля на произвольный электронный адрес, указав несколько адресов электронной почты, вместо одного адреса, что может привести к полному захвату учетной записи.
POST https://example.com/api/v1/password_reset HTTP/1.1Таким образом, оригинальный запрос:
{"email_address":"xyz@gmail.com"}изменяется на:
{"email_address":["admin@breadcrumb.com","attacker@evil.com"]}После этого ссылка для сброса пароля будет отправлена как жертве, так и злоумышленнику. Злоумышленник, в свою очередь, может использовать её для полного захвата аккаунта.
🌐 Приводим реальный пример подобной уязвимости:
3. Подбор одноразового пароля для сброса.
Теперь, для случая, когда функция сброса пароля приложения основана на проверке OTP. Многие программы считают отсутствие ограничения скорости ввода пароля приемлемым. Таким образом, мы можем попробовать брутфорс OTP.
Мы можем сбросить пароль учетной записи, перехватив запрос на проверку OTP и перебрав 6-значный номер. Используя это, можно изменить и сбросить пароль любой учетной записи, изменив пользовательские данные и перебрав пароль для сброса.
🌐 Приводим реальные примеры подобных уязвимостей:
4. Утечка токена сброса пароля через заголовок Referrer.
HTTP Referrer является необязательным HTTP заголовком, который содержит адрес предыдущей веб-страницы, с которой была сделана ссылка на текущую запрашиваемую страницу.
Эксплуатация:
• Запросить сброс пароля на свой адрес электронной почты
• Нажмите на ссылку для сброса пароля
• Не меняйте пароль
• Перейдите на любой сторонний веб-сайт (например: Facebook, Twitter)
• Перехватите запрос в прокси-сервере Burp Suite
• Проверьте, не утекает ли токен сброса пароля в заголовке Referrer.
🌐 Приводим реальные примеры подобных уязвимостей:
5. Манипуляция ответами: замените плохой ответ хорошим.
Манипуляции с ответами могут привести к легким уязвимостям. Сначала вы можете использовать обычный пароль и записать ответ сервера, когда вы ввели правильный OTP/токен. Затем попробуйте еще раз с неправильным OTP/токеном и замените неуспешный ответ на успешный.
Ищем ответ на запрос, вроде этого:
HTTP/1.1 401 Unauthorized("message":"unsuccessful","statusCode":"403","errorDescription":"Unsuccessful")И изменяем его на правильный:
HTTP/1.1 200 OK
("message":"success","statusCode":"200","errorDescription":"Success")тем самым обходим функцию сброса:
Comments