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

Згідно з повідомленням, дві zero-day вразливості 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, читайте наші наявні матеріали за посиланнями вище.