Служба поддержки — один из самых доверенных почтовых ящиков организации. Клиенты вставляют туда данные аккаунтов, журналы ошибок, имена, а иногда и документы, полагая, что данные находятся в безопасности за платформой. Сообщаемая цепочка удалённого выполнения кода через zero-day в Zammad, использованная против Нидерландского института раскрытия уязвимостей (DIVD), — напоминание о том, что это доверие полностью зависит от программного обеспечения, в котором хранятся тикеты.

Согласно отчёту, две уязвимости нулевого дня в Zammad позволяют перехватывать сессии, удалённо выполнять команды и потенциально получать root-доступ на нижележащем сервере. Zammad — это платформа тикетов и службы поддержки с открытым исходным кодом. Детали в исходной статье ограничены, поэтому этот материал придерживается того, что было сообщено, и избегает догадок о технических подробностях.

Как связали zero-day в Zammad

Суть истории — в цепочке. Ни одна из уязвимостей сама по себе не обязана быть разрушительной, чтобы их комбинация оказалась серьёзной. Согласно отчёту, первая слабость позволяет атакующему перехватить сессию, то есть завладеть доступом аутентифицированного пользователя, не зная его пароля. Вторая позволяет удалённо выполнять команды, давая атакующему возможность запускать команды на сервере, где размещён Zammad. Оттуда root-доступ описывается как потенциальный результат, то есть атакующий мог получить полный контроль над машиной.

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

Полное описание атаки, включая то, как разворачивалось вторжение в DIVD, смотрите в наших предыдущих материалах: AI Agent Chains Two Zammad Zero-Days to Breach DIVD и DIVD: AI Agent Exploits Two Zammad Zero-Days in Breach.

Что раскрывает скомпрометированная служба поддержки

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

  • Тикеты поддержки и всю историю переписки, привязанную к ним
  • Имена клиентов, адреса электронной почты и другие контактные данные
  • Вложения, такие как скриншоты, журналы или документы, загруженные клиентами
  • Внутренние заметки, которые сотрудники писали о клиентах или инцидентах
  • Учётные данные, API-токены или настройки интеграций, хранящиеся на сервере

Root-доступ ещё больше повышает ставки. Атакующий, контролирующий хост, не ограничен данными приложения. Он может добраться до других сервисов на той же машине, прочитать конфигурационные файлы и использовать сервер как плацдарм в другом месте сети. Именно поэтому компрометация службы поддержки может превратиться в более широкий инцидент, а не в локальный.

Случай DIVD также примечателен тем, что DIVD сам является организацией по безопасности, которая помогает сообщать и исправлять уязвимости. Если группа, сосредоточенная на этой работе, может пострадать, любая организация, использующая самостоятельно размещённые инструменты, должна исходить из того, что она может быть возможной целью. Наш материал о цепочке zero-day в Zammad, которая позволила атаку на основе ИИ освещает этот контекст.

Что администраторам Zammad следует сделать сейчас

Если вы используете Zammad, отнеситесь к этому как к приоритетной проверке, а не рутинной задаче.

  1. Проверьте наличие официальных исправлений. Следите за бюллетенями безопасности проекта Zammad и применяйте патчи или обновления, как только они станут доступны. Не полагайтесь на сторонние сводки в вопросах версий.
  2. Ограничьте доступность. Если ваш экземпляр не должен быть доступен из открытого интернета, ограничьте доступ с помощью VPN, списка разрешённых IP-адресов или правил обратного прокси до установки патча.
  3. Аннулируйте сессии. Поскольку перехват сессий является частью сообщаемой цепочки, рассмотрите принудительный выход из системы и ротацию секретов сессий после обновления.
  4. Смените учётные данные. Измените пароли администраторов, API-токены и любые секреты, хранящиеся на сервере, особенно если вы подозреваете компрометацию.
  5. Проверьте журналы. Ищите необычные входы администраторов, неожиданные команды, новые учётные записи или странные исходящие соединения.
  6. Работайте с минимальными привилегиями. Убедитесь, что приложение не работает с большими системными правами, чем ему нужно, и храните резервные копии отдельно от сервера.

Что могут сделать клиенты, чтобы ограничить риски

Что это значит для вас

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

  • Делитесь меньшим в тикетах. Избегайте отправки паролей, полных идентификационных номеров, платёжных данных или конфиденциальных документов через тикет поддержки. Если запрос действительно требует их, спросите, существует ли более безопасный канал.
  • Редактируйте перед прикреплением. Размывайте или удаляйте личные данные со скриншотов и журналов.
  • Используйте уникальные пароли. Если платформа поддержки когда-либо хранит отправленные вами учётные данные, уникальный пароль ограничит ущерб.
  • Следите за уведомлениями об утечках. Читайте письма от сервисов, которыми пользуетесь, о инцидентах безопасности и будьте осторожны с последующими сообщениями, которые просят перейти по ссылкам или подтвердить данные.
  • Ожидайте фишинг. Контактные данные и контекст тикета могут сделать мошеннические сообщения убедительными. Проверяйте через официальный сайт организации.

Итог

Сообщаемая цепочка удалённого выполнения кода через zero-day в Zammad показывает, как одна платформа службы поддержки может превратиться в шлюз к данным клиентов и контролю над сервером. Администраторам следует устанавливать патчи, ограничивать доступ и менять секреты. Все остальные могут отправлять меньше конфиденциальной информации через тикеты и оставаться внимательными к уведомлениям об утечках. Полное описание того, как разворачивалась атака на DIVD, читайте в наших материалах по ссылкам выше.