Insecure Direct Object Reference (IDOR) — очень распространённый вид недостатков авторизационной логики приложения. Потенциальный ущерб от эксплуатации IDOR может быть как минимальным, так и критическим. Рассмотрим некоторые случаи, когда наличие IDOR позволило реализовать угрозу с высоким уровнем риска — захват аккаунта или захват проекта.
Захват аккаунта даёт атакующему полный или почти полный доступ к аккаунту жертвы.
Захват проекта даёт атакующему доступ к отдельному проекту, созданному внутри аккаунта пользователя. Зачастую атака не даёт полностью захватить аккаунт, но можно захватить какие-то ресурсы, принадлежащие другому пользователю (например, проект или внутреннего пользователя, которого создает администратор). Неоднократно сталкивался с подобными уязвимостями в программах Bug Bounty.
Что такое этот IDOR?
IDOR — это небезопасная прямая ссылка на объект. Этот недостаток часто объясняют на примере интерфейса службы поддержки, где, меняя ID тикета, можно читать тикеты других пользователей. Но на самом деле IDOR не ограничивается изменением числового идентификатора для чтения данных, результатом атаки может быть и изменение данных.
Встречаются также случаи, где узнать ID сложно, если это, например, хеш или uuid, в этом случае риск сильно снижается. Но на моей практике почти всегда получалось найти способы, как узнать ID жертвы.
Думаю, IDOR можно разделить на подтипы. По характеру действия:
- Чтение данных
- Изменение данных
- Повышение привилегий (частный случай изменения данных)
- Захват аккаунта (частный случай повышения привилегий)
Разберём пример использования IDOR для захвата аккаунта или проекта.
IDOR leads to Account TakeOver
Как же всё-таки с помощью IDOR получается захватить аккаунт или любую другую сущность которая создается внутри самого аккаунта (чаще всего это внутренний проект)? Например, пользователь создает в своем аккаунте менеджера или какой-то проект, и контроль над этими сущностями/объектами может захватить атакующий.
В случае с захватом главного аккаунта не так просто, потому что к главному аккаунту атакующий обычно не может никак напрямую обращаться со своего аккаунта. Захват главного аккаунта происходит через сущности аккаунта, например, через какой-то проект или того же менеджера. Ниже рассмотрим конкретные случаи из Bug Bounty.
IDOR при добавлении и удалении проекта в группе
Бывают проекты, где есть разные тарифные планы, которые можно подключать за определенную стоимость. Также бывает специальный тариф Enterprise, который подстраивается под клиента в зависимости от его потребностей. В одном из проектов при подключении тарифа Enterprise обычные проекты можно было добавлять к нему в группу, и тогда они тоже получали статус Enterprise.
IDOR был обнаружен сразу в двух местах. При добавлении проекта в Enterprise-группу, а также при его удалении. При добавлении всё было банально: передавался POST запрос с JSON-телом, в котором передавалось имя проекта, которое открыто для всех, таким образом, можно было добавить чужой проект в свою группу и получить над ним контроль:
|
1 2 3 4 |
POST /api/projects/victim/children HTTP/1.1 Host: victim.com {"subdomain":"victim1"} |
Сложнее было с IDOR при удалении проекта. Сам процесс удаления проекта из группы был реализован логически неправильно. При удалении проекта передавался POST-запрос, в котором передавалось полное описание группы в сериализованном виде, но при этом из него предварительно удалялся идентификатор того проекта, удаление которого запрошено.
При этом можно было просто добавить или изменить ID проекта, который еще оставался в группе, на ID чужого проекта.
Осложнялась эксплуатация тем, что ID представлял из себя случайное значение, подобрать или угадать которое не удалось. Но получилось найти способ узнать ID проекта через фронтенд: можно было зайти на страницу проекта (страницы публичны) и найти ID JSON-формате в коде страницы:
Итоговый запрос:
|
1 2 3 4 5 |
PUT /api/projects/victim HTTP/1.1 Host: victim.com Cookie: ... {"childrenProjects":["id_project1","id_project2","id_project_victim"]} |
IDOR при переносе менеджера
Данная атака использовала сразу 2 уязвимости, благодаря цепочке получился очень высокий уровень риска. Это неправильная настройка доступов (Improper Access Control) и IDOR.
Из-за неправильной настройки доступов можно было просматривать чужие проекты и менеджеров, которые были привязаны к этим проектам. Эта уязвимость уже позволяла похитить какие-то конфиденциальные данные.
Но в ходе дальнейшего изучения приложения, был обнаружен другой недостаток, который позволял при сохранении профиля своего аккаунта подключить к аккаунту также чужого менеджера по его идентификатору (так что это IDOR).
Узнать ID можно было через предыдущую уязвимость. Подключив чужого менеджера к своему аккаунту, атакующий получал привилегии этого менеджера и получал контроль над его проектом, Полученный доступ позволял просматривать и редактировать данные.
Речь идёт об уязвимости, описанной в репорте https://hackerone.com/reports/863983. Уязвимость позволяла получить доступ к данным более чем 1 млн водителей: паспорта, лицензии водителей. Также с помощью захвата аккаунта партнёра атакующий мог изменять данные водителей, которые регистрировались с помощью этого партнера (таксопарка).
Итого
За уязвимости, описанные выше, было выплачено более $25,000, а потенциальный ущерб от действий злоумышленников мог многократно превысить эту сумму.
Во избежание таких потерь, своевременно проводите анализ защищённости своих проектов. Обращайтесь к нам для получения услуг по анализу защищённости и тестированию на проникновение.