Обычно такие статьи начинаются со слов: «Я открыл Burp Suite…».

Но не в этот раз.

Это история о том, как я получил доступ к реальным аккаунтам пользователей на живой продакшн-системе без единого взаимодействия с пользователем, без каких-либо фиксаций сессии, и мне даже не понадобился Burp Suite.

Этап разведки

Я начал со стандартных методов разведки и заметил, что целевое приложение имело несколько поддоменов, например:

• profile.example.com

• onboarding.app.example.com

• example.com

Сначала я не придавал большого значения поддоменам. Но во время более глубокого тестирования наткнулся на кое-что интересное — функцию под названием “Edit Entry”.

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

Углубляемся

Я решил разобраться. Анализируя поток запросов, я наткнулся на очень интересный эндпоинт на поддомене onboarding.app.example.com:

onboarding.app.example.com/claiming/{{entry_id}}/verified_claims/{{uuid}}

Это сразу привлекло мое внимание. Наличие uuid в URL выглядело странным и потенциально небезопасным.

Идея, которая изменила ход событий

Я связался со своим другом. Вместе мы устроили мозговой штурм и придумали смелую идею:

• Зарегистрировать новую учетную запись.

• Получить собственный uuid (который мы контролируем).

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

• А что если мы подставим вместо нашего uuid uuid целевого аккаунта, который хотим получить? И это сработало!

Итак, если мы продолжим использовать свой собственный uuid, но подставим entry_id жертвы — угадайте, что произойдет?

Бууууум! Полный захват аккаунта без какого-либо взаимодействия со стороны пользователя!Полный доступ, полный контроль.

Кому нужен Burp, когда есть любопытство, браузер, немного креатива и хорошие друзья?

Persistent Token Abuse

Одна из самых критичных особенностей этой уязвимости — токен, используемый для “привязки” entry, не истекает. Более того, один и тот же токен можно многократно использовать раз без каких-либо ограничений по количеству попыток, инвалидирования или других ограничений.

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

Выводы

— Не стоит недооценивать простые на вид эндпоинты. URL вроде /claiming/{{entry_id}}/verified_claims/{{uuid}} может быть дверью к критической уязвимости.

— Ручное тестирование иногда лучше инструментов. Порой твой мозг и любопытство дадут больше, чем автоматические сканеры вроде Burp.

— Многократно используемые и не истекающие токены — это катастрофа для безопасности. Токены должны быть короткоживущими, одноразовыми и проверяться на стороне сервера.

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

— Понимание и удачные догадки относительно логики работы приложения помогают находить изъяны. Следите как используются параметры вроде uuid и entry_id.

— Думайте как атакующий, а не пользователь. Подставляйте значения, проверяйте все предположения.

Ещё больше познавательного контента в Telegram-канале — Life-Hack - Хакер