Коли постачальник засобів безпеки відключає власну хостингову платформу, варто звернути на це увагу. Саме це сталося після розкриття 33 zero-day вразливостей N-able N-central, набору недоліків, які могли наразити керовані системи на захоплення. N-able перевела свої хостингові сервери N-central в офлайн-режим, і клієнтам було рекомендовано зробити те саме зі своїми розгортаннями.
Цей допис охоплює те, що відомо з повідомлень, чому такий інструмент, як N-central, несе такий великий ризик, і що малий бізнес та клієнти постачальників керованих послуг (MSP) можуть зробити вже зараз.
Що означають 33 недоліки N-central
N-central — це платформа віддаленого моніторингу та управління (RMM) від N-able. MSP використовують подібні інструменти для моніторингу, оновлення та адміністрування комп'ютерів і серверів бізнесів, які вони підтримують. Згідно з повідомленням, 33 нововиявлені вразливості могли дозволити захоплення керованих систем.
Термін «zero-day» тут має значення. Він означає, що недоліки були розкриті до того, як виправлення стали широко доступними, тому захисники мали мало часу або взагалі не мали його для підготовки. Ось чому реакцією N-able було перевести хостингові сервери в офлайн-режим, а не чекати циклу випуску патчів, і чому клієнтам, які запускають власні інстанси, було рекомендовано зробити те саме.
Джерельна стаття коротка, тому деякі деталі залишаються непідтвердженими в опрацьованих нами повідомленнях, зокрема те, як працює кожен недолік і чи були якісь з них використані в реальних атаках. Ми не будемо робити припущень з жодного з цих питань. Читачам слід вважати офіційні рекомендації постачальника авторитетним джерелом у міру розвитку ситуації.
Чому компрометація одного RMM каскадно поширюється на багатьох бізнесів
Платформа RMM розроблена так, щоб мати глибокий, довірений доступ до машин, якими вона керує. Вона може запускати скрипти, розповсюджувати програмне забезпечення та змінювати налаштування на багатьох пристроях одночасно. Саме це робить її корисною для MSP, і саме це робить її привабливою для зловмисника.
Ризик походить від концентрації:
- Одна консоль, багато клієнтів. MSP може керувати десятками або сотнями клієнтських організацій з єдиної платформи. Контроль над цією платформою може означати доступ до всіх них.
- Привілейованість за задумом. Агенти RMM зазвичай працюють з високими привілеями на кінцевих точках, тому зловмисник, який контролює сервер, успадковує цю довіру.
- Невидимість для кінцевого клієнта. Малий бізнес, який передає ІТ на аутсорсинг, часто не має безпосереднього уявлення про інструменти, які використовує його постачальник, або про те, чи ці інструменти пропатчені.
Це основний урок розкриття N-central. Слабке місце може бути зовсім не у вашій власній мережі. Це може бути інструмент управління, що знаходиться на один крок вище за потоком, яким керує хтось інший.
Що N-able та її клієнти зробили на цей момент
Виходячи з повідомлень, N-able перевела свої хостингові сервери N-central в офлайн-режим у відповідь на розкриття. Клієнтам було рекомендовано зробити те саме, що, ймовірно, означає переведення власних інстансів N-central в офлайн-режим до вирішення ситуації.
Відключення основної платформи управління — це руйнівний крок. Для MSP це може означати втрату можливості моніторингу та патчингу клієнтських систем протягом певного часу. Для їхніх клієнтів це може означати повільніші відповіді підтримки. Цей компроміс є сигналом того, наскільки серйозно постачальник ставиться до ризику: тимчасова втрата видимості була визнана кращою, ніж залишення вразливої платформи відкритою.
Конкретні деталі, як-от терміни виправлень чи відновлення, не були деталізовані в джерелі, з яким ми працювали, тому перевіряйте офіційні рекомендації N-able щодо поточного статусу.
Що це означає для вас
Те, як це вас стосується, залежить від вашої ролі.
Якщо ви самостійно керуєте N-central або працюєте в MSP: ставтеся до рекомендацій постачальника як до нагальних. Дотримуйтесь інструкцій N-able щодо переведення інстансів в офлайн-режим і не повертайте їх, доки не переконаєтесь, що рекомендовані виправлення застосовані.
Якщо ви бізнес, який користується послугами MSP: ви можете ніколи не входити в N-central, але інструменти вашого постачальника можуть торкатися кожного пристрою, який ви маєте. Запитайте свого постачальника, чи використовує він N-central, чи дотримався рекомендацій N-able і як він повідомить вас, якщо ваші системи були зачеплені.
Якщо ви приватна особа або домашній користувач: це навряд чи вплине на вас безпосередньо, але це корисне нагадування про те, що програмне забезпечення, яке використовує ваш роботодавець або ІТ-провайдер, також може бути частиною вашого ризику.
Контрольний список для постраждалих користувачів: патчинг, перевірка доступу, моніторинг адміністраторів
Якщо ваша організація використовує N-central, безпосередньо або через постачальника, виконайте ці кроки:
- Підтвердіть статус патчів. Перевірте офіційні рекомендації N-able щодо виправлень, які охоплюють розкриті недоліки, і переконайтеся, що вони застосовані, перш ніж відновлювати роботу.
- Дотримуйтесь інструкцій щодо офлайн-режиму. Якщо вам рекомендували перевести ваш інстанс в офлайн-режим, тримайте його офлайн, доки постачальник не повідомить, що можна безпечно продовжувати.
- Перегляньте адміністраторський доступ. Складіть список кожного облікового запису з правами адміністратора у вашій платформі RMM. Видаліть облікові записи, які не використовуються, є спільними або незнайомими.
- Змініть облікові дані. Змініть паролі адміністраторів і будь-які API-ключі чи секрети, що зберігаються в платформі або підключені до неї, та впровадьте багатофакторну автентифікацію.
- Моніторте активність адміністраторів. Перегляньте журнали на предмет неочікуваних входів, нових облікових записів, нових скриптів або запланованих завдань, а також програмного забезпечення, розповсюдженого на кінцеві точки без вашого дозволу.
- Задайте своєму MSP прямі запитання. Попросіть письмове оновлення щодо їхньої схильності до ризику, того, що вони зробили, і як вони повідомлять вас про будь-які виявлення.
- Обмежте exposure. Де можливо, обмежте доступ до консолей управління, щоб вони не були доступні з відкритого інтернету.
Ключові висновки
Zero-day вразливості N-able N-central є яскравим прикладом ризику ланцюга постачання: один дефектний інструмент управління може поставити багато організацій в однакове становище одночасно. Рішення постачальника перейти в офлайн-режим показує, наскільки серйозною може бути ця схильність до ризику.
Практичний наступний крок простий. Перевірте статус патчів, перегляньте, хто має адміністраторський доступ, і уважно стежте за активністю адміністраторів. Якщо ви покладаєтесь на MSP, запитайте їх про N-central сьогодні, а не чекайте, поки вам скажуть. Щодо найсвіжіших і найточніших деталей покладайтеся на офіційні рекомендації з безпеки N-able та комунікації вашого постачальника, оскільки рекомендації щодо подібних інцидентів можуть швидко змінюватися.
