IDOR для захвата аккаунта

May 06 2023

Резюме Привет народ! После завершения моей сертификации OSCP и желания снова погрузиться в поиск ошибок, я решил, что, возможно, мне следует написать несколько блогов, основанных на моих предыдущих выводах, в надежде, что кто-то может найти их полезными или извлечь из них уроки. В этой статье говорится об обнаружении двух уязвимостей IDOR и их использовании для утечки PII, что приводит к захвату учетной записи.

Краткое содержание

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

В этой статье мы находим две уязвимости IDOR и используем их для утечки PII , что приводит к захвату учетной записи . Захват учетной записи стал возможен из-за того, как компания справилась с процессом восстановления учетной записи, и на самом деле это был один из моих первых выводов, когда я впервые начал вознаграждения за обнаружение ошибок. Острые ощущения от обнаружения этого заставили меня постоянно учиться сверхурочно.

Что это за IDOR, о котором я говорю?

Insecure Direct Object Referenceчаще всего сокращенно «IDOR» — это тип уязвимости, который можно отнести к категории access control. IDORsпроисходят в приложении, когда приложение использует введенные пользователем данные для прямого доступа к объекту без выполнения каких-либо проверок, чтобы убедиться, что у пользователя есть правильные разрешения авторизации. Чаще всего это связано с горизонтальным повышением привилегий, IDORsкоторое может иметь пагубные последствия для приложения и его пользовательской базы.

Ярким примером типичных параметров, обычно уязвимых для IDOR, являются: id= | userID= | messageId=. Понимание потока приложения может упростить выявление этих типов проблем.

Изображение выше иллюстрирует два сценария. Scenario Aслева показано более безопасное приложение, в котором users 2 and 3пытаются получить доступ к конфиденциальным записям, которые им не принадлежат, однако это приводит к тому, access denied errorчто должно.

Scenario Bоднако справа изображено уязвимое приложение, в котором субъект угрозы может отправлять запросы к веб-серверу и получать конфиденциальные записи для любого заданного пользователя без отказа в доступе.

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

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

Теперь, когда у нас есть представление о том, что это IDORsтакое, где их можно найти, а также о влиянии, давайте углубимся в одно из моих первых открытий! :)

Разведка

Хотя проблема была исправлена, мне не удалось получить разрешение на полное публичное раскрытие, поэтому цель будет называться: example.com. Как и в случае с любой другой целью, в зависимости от scope, перечисление поддоменов является ключом к расширению поверхности атаки. Однако перечисление поддоменов — не единственный способ расширить поверхность атаки, поскольку мы также можем анализировать JavaScriptфайлы на наличие конфиденциальной информации. В данном случае я решил начать с использования быстрого поиска, Google Dorkчтобы увидеть, смогу ли я найти какие-либо интересные поддомены, прежде чем использовать автоматизированные инструменты для получения дополнительных результатов.

Гугл Дорк:site:*.example.com

Example.comбыло около 36 поддоменов, так что довольно много поддоменов для работы!
Просматривая их один за другим, я отметил два поддомена, у которых было много функций. Мне потребовалось около дня или двух, чтобы перемещаться по этим субдоменам и тестировать различные функции, при этом обращая внимание на некоторые из наиболее интересных функций, характерных для этого приложения. Например, в приложении была функция, с помощью которой вы могли создавать тикеты для получения поддержки от сотрудников по разным категориям, таким как «Проблемы с оплатой».

Первоначальная ошибка

Я решил начать с анализа того, как работает процесс регистрации и входа в систему — основная функция, которая в настоящее время реализована почти на всех веб-сайтах. Поток регистрации веб-приложения можно резюмировать следующим образом:

Пользователь регистрируется по электронной почте
Перед завершением процесса создания учетной записи пользователя просят установить a PIN No.и a . security questionЭто может быть установлено только один раз и не может быть изменено
Пользователя просят подтвердить адрес электронной почты, прежде чем он сможет войти

Используя account A, я запустил Burpsuiteи начал тестировать функцию продажи билетов и создал две тестовые учетные записи, а затем создал несколько заявок в разных категориях поддержки для целей тестирования. Глядя на HTTP Historyвнутри Burpsuiteбыло несколько интересных звонков.

При ответе сотруднику в тикете, связанном с претензией на приз, было инициировано следующее :POST request

POST /account/prizes/view/{123456} HTTP/1.1
Host: subdomainX.example.com

grant=w&prizeClaim_id={123456}&action=add_comment&comment_body=Hello+admin+...

Итак, чтобы подвести итоги на данный момент:

При регистрации каждый пользователь должен создать PIN No.иsecurity question
Веб-сайт позволяет пользователям делать заявки в службу поддержки для получения помощи.
Чтобы получить поддержку, пользователь должен ответить по PIN No.деликатным security question answerвопросам, таким как восстановление учетной записи, получение приза и проблемы с оплатой.
IDORуязвимость, обнаруженная в системе тикетов, позволяет злоумышленнику оставлять комментарии в любом тикете поддержки, не будучи владельцем тикета или сотрудником

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

Я перехватил следующий запрос GET при попытке просмотреть билет, принадлежащий account Avia account B, однако это привело к недопустимой 403ошибке! Таким образом, я мог написать в любой запрос в службу поддержки, но не смог прочитать его содержимое. В этот момент я действительно хотел найти любой возможный способ продвинуть это дальше.

GET Endpoint для чтения билета в веб-приложении

GET /management/ticket?id=343433 HTTP/1.1
Host: subdomainX.example.com
Upgrade-Insecure-Requests: 1
Connection: close

Пытаясь использовать функцию продажи билетов, я наткнулся на следующий запрос;

GET /go.php?du=example.com/ HTTP/1.1
Host: subdomainX.example.com
Connection: close
Upgrade-Insecure-Requests: 1
Cookie:

Утечка содержимого тикетов через API в приложении IOS

Во время первоначальной разведки я заметил, что некоторые APIзапросы отправляются при получении информации о профиле, кроме того, цель также была mobile appв области видимости. Весьма вероятно, что хотя чтение других пользовательских билетов в самом веб-приложении было невозможно, это может быть достижимо через мобильное приложение, поскольку оно могло использовать другое, чем API version/endpointвеб-приложение.

Запустив Burpsuiteи перейдя к сеансу тикетов в приложении IOS, я достиг следующей конечной точки:

GET /api/v3/tickets/123456/posts HTTP/1.1
Host: x-api.example.com

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

Эскалация считывания заявки IDOR > Перехват учетной записи

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

Посетите /api/v1/support-tickets/234567/postsконечную точку и отправьте ее, intruderчтобы Burpsuiteперечислить как можно больше билетов.
Grepдля ключевых слов, таких как Pin Numberили Security Questionиз ответов
Создайте новый аккаунт на сайте и откройте тикет подaccount recovery
Назначенный сотрудник запросит имя пользователя учетной записи, которую вы хотите восстановить, а также и security question answer, PIN No.все из которых могут быть просочены через второй найденный IDOR; таким образом, что приводит к поглощению аккаунта.

Несмотря на то, что захват учетной записи уже был осуществлен, IDOR записи заявки также можно было использовать. Имена пользователей сотрудников имели префикс с названием компании, например example-John. Противник мог;