Недавно участвуя в программе багбаунти на HackerOne, нашел интересную уязвимость, за которую мне выплатили 325 зеленых американских рублей. Это была увлекательная история, которая началась с тестирования всех функций программы и закончилась обнаружением уязвимости в двухфакторной аутентификации (2FA). Сейчас я расскажу, как это произошло.
Еще по теме: Вот как нашел свою первую RCE уязвимость
Обход двухфакторной авторизации 2FA
Я решил тщательно изучить все функции программы, стараясь найти что-то значимое. Первоначально мне удалось обнаружить несколько незначительных уязвимостей низкого уровня (P4), но я понимал, что они, скорее всего, будут отмечены как дубликаты или просто информационные. Я не собирался сдаваться и решил углубиться в изучение программы, надеясь найти что-то более серьезное.
Статья в образовательных целях и ориентирована на обучение багхантеров (этичных хакеров, которые специализируются на поиске багов — уязвимостей). При участии в программе багбаунти необходимо действовать этично и придерживаться установленных правил. Ни редакция spy-soft.net, ни автор не несут ответственности за ваши действия.
Программа использовала двухфакторную аутентификацию через приложение-аутентификатор, которое генерировало одноразовые коды каждые 30 секунд. В таких условиях атака методом брутфорс (подбора кодов) становилась неэффективной из-за частой смены кодов. Обычно подобные атаки проще проводить с использованием одноразовых паролей, отправляемых через SMS, но в данном случае это было невозможно.
И тут я заметил еще один метод 2FA: резервные коды. После активации двухфакторной аутентификации программа предоставляла пользователю восемь резервных кодов, которые можно было загрузить и использовать в случае необходимости. Каждый резервный код представлял собой простой 6-значный номер. Именно здесь я увидел возможность.
Я понял, что в отличие от кодов аутентификатора, резервные коды не имели защиты частых попыток ввода (rate-limiting). Это означало, что я мог попробовать подобрать правильный резервный код с помощью брута. Я ввел стандартный резервный код 111111 и перехватил запрос с помощью Burp Suite. Затем настроил полезную нагрузку на значение $111111$ и запустил атаку с различными вариантами резервного кода.
Ответы сервера дали понять, что защита от частых попыток ввода отсутствует:
- 400 Bad Request — неверный резервный код.
- 204 No Content — верный резервный код.
Благодаря этим статус-кодам я смог легко определить правильный резервный код и обойти 2FA полностью.
Эта уязвимость позволяла обойти весь процесс двухфакторной аутентификации из-за отсутствия защиты от частых попыток ввода резервных кодов. Злоумышленник мог бы воспользоваться этим для получения несанкционированного доступа, что представляло собой значительную угрозу безопасности.
Таймлайн событий
- 20 января 2024. Я отправил отчет о найденной уязвимости в рамках программы багбаунти на HackerOne.
- 20 января 2024. Степень серьезности уязвимости была обновлена до среднего уровня (6.7).
- 20 января 2024.Отчет был принят в работу.
- 23 января 2024. Я запросил обновления по отчету.
- 27 января 2024. Отчет был отмечен как решенный после того, как платформа ввела ограничения на частоту ввода резервных кодов.
Это был мой первый багбаунти на площадке HackerOne, и я был невероятно рад, что мои усилия были оценены. Уязвимость была устранена, а я получил вознаграждение за свою работу. Этот опыт стал для меня ценным уроком, показавшим, насколько важно проявлять настойчивость и внимание к деталям при поиске уязвимостей.
Понял, что даже такие надежные меры безопасности, как двухфакторная аутентификация, могут иметь слабые места, если не внедрены должным образом. Важно мыслить творчески и исследовать все возможные пути при охоте на баги.
ПОЛЕЗНЫЕ ССЫЛКИ:
- Вот как взломал сайт Tesla и получил 10.000$
- Взлом правительственного сайта Нидерландов
- Вот как нашел уязвимость Reflected XSS на сайте NASA
