Связанные с API уязвимости подвергают опасности переписку, адреса электронной почты, тикеты и многое другое через сервис отчетности Zendesk Explore.
Множественные уязвимости в CRM-платформе компании Zendesk могли позволить злоумышленникам получить доступ к конфиденциальной информации из потенциально любой учетной записи клиента - открытие, демонстрирующее слабости API приложений в корпоративных приложениях типа SaaS.
Исследователи из Varonis Threat Labs обнаружили проблемы - в частности, уязвимость SQL-инъекции и баг логического доступа - в Zendesk Explore, компоненте платформы Zendesk, говорится в сообщении в блоге, опубликованном 15 ноября.
По данным сайта компании, более 100 000 клиентов в настоящее время используют Zendesk в качестве решения для работы с клиентами. Zendesk Explore - это часть пакета, призванная помочь этим клиентам анализировать, понимать и обмениваться данными об их бизнесе.
Исследователи обнаружили, что они могут использовать дефекты для извлечения данных из Zendesk Explore, включая список таблиц из экземпляра службы реляционной базы данных (RDS) Zendesk, а также всю информацию, хранящуюся в базе данных. Эта информация включала адреса электронной почты пользователей, лиды продаж, сделки из CRM, разговоры агентов в реальном времени, тикеты, статьи центра помощи и многое другое.
Для успешной эксплуатации потенциальная жертва должна была иметь включенный Zendesk Explore, а злоумышленник должен был сначала зарегистрироваться в службе тикетов учетной записи Zendesk жертвы как новый внешний пользователь, пояснили исследователи.
Однако «регистрация включена по умолчанию, поскольку многие клиенты Zendesk полагаются на конечных пользователей, отправляющих заявки на поддержку непосредственно через Интернет» - пишут они. Zendesk Explore, с другой стороны, не включен по умолчанию, но он «активно рекламируется как требование для страницы аналитических данных», отметили исследователи.
Varonis сотрудничала с Zendesk для устранения недостатков, что компании удалось сделать быстро, выпустив исправление, не требующее действий со стороны клиента, "менее чем за одну рабочую неделю", сообщили исследователи. Нет никаких доказательств того, что уязвимости использовались до выпуска исправления, добавили они.
Однако взгляд на технические детали показывает, насколько легко внедрить недостатки безопасности в облачные корпоративные приложения.
Обычный баг, уникальный код.
Хотя уязвимости SQL-инъекций (SQLi) являются одним из наиболее распространенных типов уязвимостей, встречающихся в веб-приложениях, проблема Zendesk была уникальной по нескольким причинам, рассказал Dark Reading Майкл Бакби, инженер по безопасности из Varonis.
«Новизна этой атаки заключалась в том, как приложение Zendesk строит свои SQL-запросы - в виде вложенных объектов внутри более крупного сообщения GraphQL - и в использовании функции строковой константы Postgres DB с кавычками в долларах для обхода существующего в приложении фильтра SQL-инъекций» - сообщает Бакби.
Zendesk использует множество API GraphQL в своих продуктах, особенно в консоли администрирования, объясняют исследователи в своем сообщении. GraphQL - относительно новый формат API, и при изучении его реализации в Zendesk они обнаружили особенно интересный тип объекта в Zendesk Explore под названием QueryTemplate, который указывал на потенциальную проблему.
«Поле querySchema выделялось тем, что оно содержит XML-документ с кодировкой Base64 под названием Query внутри JSON-объекта, а многие атрибуты в XML были самими JSON-объектами с кодировкой Base64» - пишут исследователи.
Это представляло собой многовложенное кодирование - сценарий кода, который всегда привлекает внимание исследователей угроз, «поскольку большое количество оберток вокруг данных обычно означает, что для обработки этих данных используется множество различных сервисов (которые, скорее всего, были созданы отдельными разработчиками или даже командами)».
Одним словом, чем больше кода в приложении, тем больше потенциальных мест, где могут скрываться уязвимости, считают исследователи.
Исследователи воспользовались правами администратора собственного аккаунта Zendesk в лаборатории для дальнейшего изучения приложения, визуализировав отчет в Zendesk Explore, где они обнаружили API под названием execute-query, который в конечном итоге привел их к обнаружению недостатков.
Углубление в проблему.
По словам исследователей, дальнейшие поиски привели их к XML-документу, в котором все атрибуты имен оказались уязвимы для атаки SQL-инъекции. Атрибуты имен определяют таблицы и столбцы для запроса в XML-документе.
Дальнейшее изучение API execute-query показало, что он не выполняет несколько логических проверок по запросу, что представляет собой еще одну уязвимость в приложении.
«Целостность документов не проверялась, что позволило нашей команде изменять их таким образом, чтобы раскрыть внутреннюю работу системы» - заявили исследователи.
Более того, идентификаторы «query», «datasources» и «cubeModels» не были проверены на принадлежность текущему пользователю. И, наконец, что наиболее важно, конечная точка API не проверяла, имеет ли вызывающая сторона разрешение на доступ к базе данных и выполнение запросов, отметили исследователи.
«Это означало, что вновь созданный конечный пользователь мог вызвать этот API, изменить запрос и украсть данные из любой таблицы в RDS целевой учетной записи Zendesk, без необходимости использования SQL-инъекции».
Снижение рисков.
По словам Бакби, поскольку компания Zendesk быстро исправила дефект, прежде чем он затронул клиентов, предприятиям, использующим CRM-решение, не нужно предпринимать дальнейших действий по снижению рисков. Однако, поскольку проблемы с SQLi являются столь распространенной проблемой, Zendesk и другим компаниям, предлагающим пакеты приложений на веб-хостинге, следует проявлять больше инициативы, предпринимая превентивные меры по мониторингу своих сред, чтобы избежать подобных сценариев в будущем.
Ситуация реальна: Согласно недавнему анализу данных о взломах, американским компаниям грозят убытки в размере от 12 до 23 миллиардов долларов в 2022 году от взломов, связанных с веб-интерфейсами API, которые распространились с ростом внедрения SaaS и облачных сервисов, а также методологии разработки в стиле DevOps.
«Поставщики корпоративных SaaS должны тщательно проверять свои конечные точки API на наличие новых атак SQL-инъекций» - заявляет Бакби, «например, атак с использованием разработанных внутри компании методов генерации динамических SQL-запросов, чтобы не подвергать клиентов подобному риску».
Источник: https://www.darkreading.com
