Захват аккаунта в Yahoo! с помощью CSRF

В поисках ошибок я изучал множество статей, чтобы понять различные методы и подходы. Большинство из них были написаны исследователями, которые смогли взломать Yahoo!. Это стало моей мотивацией и я не остановился, пока не смог сделать то же самое. К счастью, мне удалось взломать Yahoo! всего за 30 минут.

Перебрав все доступные домены и определив, где работает веб-сервер, я начал искать те, которые не содержали в наименовании слово Yahoo!. Я полагал, что возможность обнаружить уязвимости в безопасности на таких поддоменах будет выше. Из всего отсортированного списка я выбрал vulnerable.com и остановился на нем.

Лично я не люблю тратить свое время на ошибки с низким уровнем серьезности. Мне нравятся серьезные вызовы. Поэтому после продолжительного анализа рассматриваемого приложения я задумался о анализе функциональности для обновления данных учетной записи пользователя. Я хотел посмотреть, смогу ли я случайно найти CSRF (хотя в то время я не очень верил, что найду CSRF в таком очевидном месте, не говоря уже о такой компании, как Yahoo!).

Поэтому я использовал функционал сайта, чтобы изменить данные учетной записи пользователя, и изменил адрес электронной почты с victim@gmail.com на netstat2332@gmail.com.

Поскольку мы пытаемся добиться CSRF, удобно проверить, принимает ли сервер запросы с произвольным происхождением. Некоторые серверы не позволяют инициировать запросы из произвольных источников. Однако сервер был дружелюбным и разрешал любому домену отправлять к нему HTTP-запросы

В этот момент я собирался создать вредоносную HTTP-форму для использования CSRF. Однако я заметил, что запросы были сделаны с использованием метода HTTP PATCH.

Это проблема, поскольку HTTP формы принимают только ограниченный набор HTTP методов. Итак, первое, что пришло мне в голову, это изменить метод HTTP напрямую на POST.

После этого я задумался о том, что еще я могу попробовать или как еще я могу вызвать неожиданное поведение на сервере. Поэтому мне пришла в голову идея изменить значение заголовка Content-type с application/json на application/x-www-form-urlencoded:

Увидев это, я решил преобразовать тело запроса из JSON в urlencoded, чтобы увидеть, присутствует ли ошибка в ответах сервера.

Я уже переписал тело запроса из JSON в urlencoded. Однако нам все еще нужно отправить этот запрос методом POST. Поскольку формы HTTP, как мы видели ранее, работают только с методами GET/POST.

Проблема здесь в том, что бэкэнд ожидает, что этот запрос прибудет с методом PATCH. После некоторых размышлений я придумал способ изменить HTTP метод до того, как он достигнет сервера. Для этого существует несколько способов, и каждый из них сильно зависит от языка программирования, используемого в серверной части.

Поэтому я использовал wappalyzer, чтобы посмотреть, какие технологии использует приложение. Благодаря нему я смог понять, что бэкенд приложения написан на Ruby On Rails. К счастью, этот фреймворк предлагает способ добиться переопределения метода HTTP, которого мы так хотим.

Наконец, со всеми этими ингредиентами вместе нам удалось обойти все ограничения, присутствующие в приложении, чтобы иметь возможность использовать CSRF, что позволит нам украсть произвольные учетные записи пользователей одним щелчком мыши

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

Поскольку мы можем изменить пароль и адрес электронной почты (способ восстановления пароля), нам удалось полностью получить учетную запись любого пользователя приложения всего одним щелчком мыши.

Я хотел оставить лучшее напоследок, я уверен, что многие из вас не знают об этом (хотя я не знаю, работает ли этот метод в Chrome сегодня).

Оказывается, Yahoo! не определил конкретный SameSite для сессионной cookie, используемой в запросах. Это не является серьезным риском для firefox, так как по умолчанию он использует LAX. Это предотвращает использование этой уязвимости в этом браузере. Судя по всему, разработчики Yahoo! думали, что все браузеры будут устанавливать эти файлы cookie в LAX и, следовательно, не должны будут использовать Anti-CSRF токен (поэтому необходимо иметь несколько уровней безопасности, лучше быть осторожным, чем слепо уверенным в чем-то).

Однако в Chrome все по-другому. Бывает, что Chrome из соображений совместимости временно разрешает файлам куки, которые явно не устанавливают атрибут SameSite, обрабатываться как None в течение двух минут. После этого браузер установит для них значение LAX . Chrome назвал эту функцию LAX+POST, и вы можете найти более подробную информацию о ней здесь. Есть несколько способов сделать эти две минуты, указанные Chrome, длиннее. Эти техники можно найти здесь.

Я не уверен, что этот трюк все еще работает в Chrome. Если это работает у вас в последней версии Chrome, дайте мне знать в поле для комментариев ;)

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

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