Исследователи из Varonis Threat Labs обнаружили возможность SQL-инъекции и уязвимость логического доступа в Zendesk Explore, компоненте платформы Zendesk.
Если верить информации на сайте вендора, Zendesk используют в качестве решения для обслуживания клиентов более 100 000 компаний. Zendesk Explore — это часть пакета, призванная помочь этим клиентам анализировать, делать выводы и обмениваться данными об их бизнесе.
Исследователи обнаружили, что они могут использовать уязвимость для извлечения данных из Zendesk Explore, включая список таблиц из экземпляра службы реляционной базы данных Zendesk (RDS), а также всю информацию, хранящуюся в базе данных. По их словам, эта информация включала адреса электронной почты пользователей, потенциальных клиентов, сделки из CRM, живые разговоры с агентами, билеты, статьи справочного центра и многое другое.
Одно из полей, передаваемых в API, — это extra_param3_value, которое включает простой текстовый XML-документ DesignSchema, не закодированный в Base64. Этот документ определяет связь между AWS RDS (управляемой реляционной базой данных).
Все атрибуты имён в этом XML-документе, определяющие запрашиваемые таблицы и столбцы, оказались уязвимыми для атаки путём SQL-инъекции.
Хотя SQL-инъекции (SQLi) являются одним распространённым типом уязвимостей, проблема Zendesk была уникальной по ряду причин:
Необычным в этой конкретной атаке было то, как приложение Zendesk создавало свои SQL-запросы — как вложенные объекты в более крупное сообщение GraphQL, — так и использование функции строковых констант PostgresDB в долларовых кавычках для обхода существующего в приложении фильтра SQL-инъекций.
Zendesk использует несколько API-интерфейсов GraphQL в своих продуктах, в т. ч. в консоли администрирования. GraphQL — это относительно новый формат API, и после изучения его реализации в Zendesk исследователи обнаружили в Zendesk Explore интересный тип объекта с именем
QueryTemplate, который указывает на потенциальную проблему.«Поле
querySchemaвыделяется тем, что оно содержит XML-документ с именем Query в кодировке Base64 внутри объекта JSON, и многие атрибуты в XML сами были объектами JSON в кодировке Base64», — пишут исследователи.
Это выглядело как многовложенное кодирование — сценарий кода, который всегда привлекает внимание кибербезопасников, так как большое количество «обёрток» вокруг данных обычно означает, что используется много разных сервисов (которые, скорее всего, были созданы отдельными разработчиками или даже командами), для обработки этих данных.
Исследователи задействовали администратора собственной учетной записи Zendesk своей лаборатории для дальнейшего изучения приложения, визуализировав отчет в Zendesk Explore, где они обнаружили API-интерфейс под названием execute-query, который в конечном итоге привел их к обнаружению уязвимости.
Дальнейшее изучение проблемы привело исследователей к XML-документу, в котором все атрибуты имени оказались уязвимыми для атаки путем внедрения SQL-кода (атрибуты имени определяют таблицы и столбцы, которые будут запрашиваться в XML-документе).
Дальнейшее изучение API-интерфейса выполнения запроса показало, что он не выполняет несколько логических проверок по запросу, что представляет собой ещё одну уязвимость в приложении:
Целостность документов не проверялась, что позволило команде изменить их таким образом, чтобы раскрыть внутреннюю работу системы.
Идентификаторы «
query», «datasources» и «cubeModels» не предусматривали возможность определить, принадлежат ли они текущему пользователю.Конечная точка API не проверяла наличие у вызывающего объекта разрешения на доступ к базе данных и выполнение запросов. Это означало, что только что созданный конечный пользователь мог вызвать этот API, изменить запрос и украсть данные из любой таблицы в RDS целевой учетной записи Zendesk без необходимости использования SQLi.
Команда Varonis Threat Labs сообщила Zendesk о найденной уязвимости и помогла устранить брешь в управлении доступом в Zendesk Explore.
Так как Zendesk исправила ошибку до того, как она затронула кого-либо из клиентов, предприятиям, использующим эти решения, не нужно предпринимать никаких дополнительных действий. Однако компаниям стоит быть более внимательным, чтобы избежать подобных сценариев в будущем.
Что ещё интересного есть в блоге Cloud4Y
→ Информационная безопасность и глупость: необычные примеры
→ It's Alive! Аккордеон из двух Commodore 64 и дискет
→ Как распечатать цветной механический телевизор на 3D-принтере
→ Создание e-ink дисплея с прогнозом погоды
→ Аналоговый компьютер Telefunken RA 770
Подписывайтесь на наш Telegram-канал, чтобы не пропустить очередную статью. Пишем только по делу. А ещё напоминаем про второй сезон нашего сериала ITить-колотить. Его можно посмотреть на YouTube и ВКонтакте.
