Здравствуйте, Меня зовут Ахмад Халаби.
Я работаю в Resecurity - аналитической компании в области кибербезопасности, защищающей компании от всех типов угроз из списка Fortune 500.
Часть нашей работы, которую мы выполняем через наше подразделение Hunter Unit Operations, заключается в исследовании и выявлении новых "нулевых дней", атак и методов, которые позволяют угрожающим субъектам вызывать массовые заражения и утечки данных.
В этой статье я расскажу о том, как мне удалось найти ошибку, которая позволила раскрыть всю электронную почту пользователей крупной телекоммуникационной компании и завладеть всеми их учетными записями.
Эксплуатация функции "Забыли пароль"
Обычно, если вы забыли свой пароль, вы можете восстановить его, отправив код восстановления на свою электронную почту или номер телефона.
Во-первых, приложение заставляет вас добавить свой номер телефона в разделе "Забыли данные для входа". Я добавил номер телефона жертвы.
Затем приложение предлагает на выбор два варианта отправки PIN-кода: на электронную почту или на номер телефона.
Мы заметили, что номер телефона скрыт так же, как и адрес электронной почты.
В нашем случае у нас уже есть номер телефона жертвы, и мы хотим раскрыть его электронную почту.
Нам неважно, куда будет отправлен код, поскольку мы обойдем его позже, поэтому мы можем отправить его как на номер, так и на электронную почту.
После нажатия на кнопку Send PIN мы заметим, что код будет отправлен. Использовать этот код мы не будем.
Эксплуатация процесса верификации PIN-кода:
С помощью техники Response Manipulation - манипулировать неправильным ответом на запрос кода и заменять его правильным ответом.
Я добавил произвольный PIN-код 1111 и перехватил запрос через burp.
В приведенном выше запросе мы видим, что они разбивают 4-значный код на 4 пин-входа (pin1, pin2, pin3, pin4) и на 3 обычных пин-входа. Такое разделение сделано для защиты от перебора PIN-кода.
Когда я увидел приведенный выше запрос, я не стал проводить перебор. Вместо этого я перехватил ответ, как показано на рисунке ниже.
После отправки запроса я проследил за его ответом и обнаружил следующий ответ с кодом состояния "700" и операцией "verify OTP", означающей, что запрос на верификацию не прошел, так как OTP был неверным.
Я просто подправил ответ, заменив {"code": "700", "operation": "VERIFYOTP"} на {"code": "200"} и переслал запрос.
После отправки запроса я был перенаправлен на страницу изменения пароля с указанием адреса электронной почты и подтверждением проверки PIN-кода.
После того, как я попытался добавить новый пароль, я получил захват учетной записи.
Влияние:
1. Мне удалось раскрыть электронную почту пользователей, найденную в базе данных телекоммуникационной компании. Угрожающие лица могут легко:
Собрать все телефонные номера, связанные с этой телекоммуникационной компанией.
Автоматизировать эту уязвимость, чтобы использовать ее на всех собранных телефонных номерах.
Продать все раскрытые частные электронные адреса в Dark Web.
Использовать их в массовых фишинговых кампаниях.
2. Мне удалось изменить пароль учетных записей в телекоммуникационной компании. Это означает получение полного захвата учетной записи, что могло легко привести к:
Финансовым потерям (пользователей).
Заключение:
В данном случае техника манипулирования ответами позволила не только раскрыть электронную почту, но и перенаправить меня на страницу изменения пароля, что позволило мне завладеть любой учетной записью, на которую я нацелился.
Исправление:
Исправление ошибки манипулирования ответами было недостаточно, необходимо было также исправить проблему авторизации при смене пароля, чтобы не допустить ее обхода.
Надеюсь, вам понравилась моя статья.
Вы можете подписаться на меня в: LinkedIn / Twitter / Instagram / My Website
Оригинал статьи - здесь.
Поддержите автора хлопками на Medium.
Перевод статьи был выполнен проектом перевод энтузиаста:
???? @Ent_TranslateIB - Телеграмм канал с тематикой информационной безопасности
???? @Ent_Translate - Инстаграм проекта
olegtsss
Каким образом backend схавал свой же ответ с исправленным содержанием?
anzay911
Похоже, тут фронтенд заставили поверить и отправить на форму сброса, а бэкенд ответил "ну надо так надо".
olegtsss
Я думал такое только в CTF бывает )
michael_v89
Как я понял, всё сводится к тому, что сервер при сбросе пароля не проверял, что PIN проверен. Подменили ответ от сервера фронтенду, чтобы фронтенд перешел на экран сброса пароля и отправил запрос. Но если есть возможность регистрации или свой аккаунт, узнать эндпойнт и формат запроса для сброса пароля можно и сделав нормальный сброс для своего аккаунта. В общем-то уязвимость и защита от нее очевидны на этапе разработки, если исходить из того, что пользователь может отправить любой запрос вручную.