Секреты iDOR: нестандартные техники и реальные кейсы

Введение

Insecure Direct Object Reference (iDOR) - небезопасный доступ к объектам остается одной из самых опасных уязвимостей которая может привести не только к массовой утечке данных, но и применяться в необычных сценариях с использованием цепочки уязвимостей с целью модификации или удаления данных.

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

Как искать iDOR

В качестве самого простого примера рассмотрим веб-приложение которое позволяет просмотреть свой профиль при переходе по ссылке, например:

https://example.com/profile?user_id=123

<?php
    $user_id = $_GET['user_id'];
    $user_info = get_user_info($user_id);
    ...

В этом примере используется прямой доступ к объекту user_id и позволяет просмотреть информацию о пользователе, но если приложение не проверяет права доступа авторизованного пользователя к другому объекту, атакующий может просто изменить идентификатор на произвольный для доступа к чужому профилю:

https://example.com/profile?user_id=124

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

Техники обхода

Цифровые и текстовые идентификаторы объектов

С цифровыми значениями стоит проверить корректно ли приложение обрабатывает значения в альтернативных представлениях:

• Цифровые значения: 101500, 101501, 101502, ...
• Шестнадцатеричные: 0x4642d, 0x4642e, 0x4642f, ...
• Имена, email адреса: username, user, name, username@example.com, ...
• Закодированные значения (base64 и др.): MTA1NTAw, MTA1NTAx, MTA1NTAy, ...
• Отрицательные значения, с плавающей точкой, запятой: 0, -1, 0.1, 0,1, ...

Сложные идентификаторы - MongoDB Object ID

Если встречается сложный идентификатор, не всегда означает что его сложно предугадать. К примеру, структура идентификатора объектов MongoDB 5ae9b90a2c144b9def01ec37 выглядит следующим образом:

• 4-байтовое значение представляет Unix timestamp
• 3-байтовое значение машинный идентификатор
• 2-байтовое значение идентификатора процесса

• 3-байтовое значение счетчика начинающегося со случайного значения

  

Такие идентификаторы можно с легкостью предугадать и тоже использовать для неавторизованного доступа к сторонним объектам. Утилита для автоматической генерации идентификаторов MongoDB:

https://github.com/andresriancho/mongo-objectid-predict

UUID/GUID

UUID / GUID 1 версии можно предугадать просто на основе времени когда они были созданы:

https://github.com/intruder-io/guidtool

Более поздние версии UUID / GUID предотвращают подобные атаки с использованием сложных идентификаторов которые невозможно предугадать. Тем не менее, они не являются гарантией безопасности и даже для объектов с UUID необходимо выполнять проверки доступа к объекту.

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

https://example.com/orders/83466ad5-0bd2-41a2-a106-b4ca38872193

В результате анализа приложения мы обнаружили альтернативный метод который проверяет статус заказа по простому идентификатору и возвращает в ответе в качестве метаданных UUID этого заказа:

GET /v1/api/order/status?code=XX-RRTQT

Ответ:

{"uuid":"83466ad5-0bd2-41a2-a106-b4ca38872193","status":"delivered"}

В другом случае приложение попросту обрабатывало запросы и по UUID, и по простому идентификатору, в результате чего можно было выполнить действие с чужим объектом на основе обычного цифрового ID из-за отсутствия проверки прав доступа к объекту:

PUT /v1/api/company/8ddf6b6a-7354-41c3-bbf0-650a02345f2b

=>

PUT /v1/api/company/5551

Хэшированные значения

Если встретился подобный идентификатор, не стоит сдаваться, можно попробовать предположить на основе чего был создан хэш, например, sha1(username), md5(email), sha2(id) и т.п.:

• MD5: 098f6bcd4621d373cade4e832627b4f6
• SHA1: a94a8fe5ccb19ba61c4c0873d391e987982fbbd3
• SHA2: 9f86d081884c7d659a2feaa0c55ad015a3bf4f1b2b0b822cd15d6c15b0f00a08

Wildcard значения

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

• GET /api/users/*
• GET /api/users/%
• GET /api/users/_
• GET /api/users/.

Всегда стоит проверять нестандартные значения с целью понять логику приложения.

Другие нестандартные способы

• Вложенные объекты:

1. {"id":111} => {"id":[111]}
2. {"id":111} => {"id":{"id":111}}

• Подмена Content-Type:

1. application/x-www-form-urlencoded
2. application/json
3. application/x-www-form-urlencoded;/json
4. text/html - html
5. application/xhtml+xml - xml
6. application/xml - xml
7. text/xml - xml
8. image/svg+xml - xml
9. text/xsl - xml (Google, Safari)
10. application/vnd.wap.xhtml+xml - xml (Firefox, Safari)
11. multipart/x-mixed-replace - xml (Firefox, Safari)
12. text/rdf - xml (Firefox)
13. application/rdf+xml - xml (Firefox)
14. application/mathml+xml - xml (Firefox)
15. Несколько Content-Type заголовков

• Манипуляция заголовком Content-Length

• Передача идентификатора альтернативным способом:

  /api/users/1 => /api/users?id=1

• Подмена HTTP метода на тот же запрос:

1. GET
2. POST
3. DELETE
4. PUT
5. HEAD
6. ANYTHING

• Другие версии API: v1, v2, v3
• Засорение параметров и массивы:

1. /api/users?username=user => /api/users?username=user&username=admin
2. /api/users?id=1 => /api/users?id[]=1&id[]=2

Обнаружение и проверка

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

Сделать этот процесс максимально эффективным можно через интеграцию с нашим API и загрузкой OpenAPI спецификаций ваших приложений на периметре что позволит в автоматическом режиме проверить инъекции и провести дополнительный ручной анализ с целью выявления сложных логических уязвимостей, в том числе таких как iDOR.

Заключение

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