Відкриті інстанси MongoDB знову опинилися в центрі автоматизованих атак-вимагань. Зловмисники масово сканують інтернет у пошуках неправильно налаштованих серверів, повністю видаляють дані та залишають у базі лише повідомлення з вимогою викупу за «відновлення» інформації.
Масштаб атак на MongoDB: скільки серверів під загрозою
За даними дослідників компанії Flare, в інтернеті виявлено понад 208 500 публічно доступних серверів MongoDB. Значна частина з них налаштована небезпечно: більше ніж 100 000 інстансів розкривають службову інформацію про кластери та конфігурацію, а близько 3100 серверів доступні взагалі без аутентифікації.
Особливо показовим є те, що майже половина (45,6%) відкритих MongoDB уже скомпрометована. На таких серверах легітимні колекції видалено, а натомість створено нові — з записками про викуп. Дослідники зафіксували близько 1400 активних жертв, у яких дані вже знищені або захоплені зловмисниками.
Сценарій атаки на відкриті бази MongoDB
Типова атака на MongoDB повністю автоматизована. Ботнети та скрипти сканують інтернет на предмет відкритих портів 27017/27018, які за замовчуванням використовує MongoDB. Якщо інстанс доступний з мережі й не вимагає авторизації, атакувальний скрипт підключається з привілеями за замовчуванням, видаляє всі бази та створює нову колекцію з інструкцією з оплати.
Flare зафіксувала, що у більшості таких «листів щастя» вимагається 0,005 BTC протягом 48 годин — це орієнтовно 500–600 доларів США на момент аналізу. Оплата має надходити на один з п’яти біткоїн-адрес, при цьому один і той самий гаманець зустрічається приблизно в 98% випадків. Це свідчить про єдиного оператора або добре координовану групу.
Старі проблеми MongoDB, які повернулися новою хвилею
Атаки на відкриті MongoDB не є новим явищем. Масові інциденти фіксувалися до 2021 року, коли тисячі відкритих баз даних стиралися або використовувалися для шантажу. У ряді випадків зловмисники навіть не намагалися заробити: дані просто знищувалися без будь-яких вимог.
Нинішня хвиля виглядає менш масштабною, але стійкою. Дослідники відзначають аномалію: частина незахищених і доступних з інтернету інстансів MongoDB не скомпрометована, хоча технічно вразлива. Одна з гіпотез полягає в тому, що адміністратори вже могли сплатити викуп, після чого атакувальники свідомо не чіпають ці сервери, щоб не привертати увагу повторними інцидентами.
Основні помилки конфігурації та застарілі версії MongoDB
Корінь проблеми — неправильна конфігурація MongoDB-серверів. Інстанси часто розгортаються для тестових середовищ або швидкого прототипування, але згодом опиняються у продакшні без перегляду налаштувань. У результаті сервер продовжує:
- слухати інтерфейс 0.0.0.0, тобто бути доступним напряму з інтернету;
- працювати без обов’язкової аутентифікації;
- використовувати слабкі, типові або спільні облікові записи.
Додатковим фактором ризику є застаріле ПЗ. Майже 95 000 публічно доступних MongoDB працюють на версіях, для яких документиовано відомі вразливості. Переважно це можливості для DoS-атак (відмова в обслуговуванні), але подібні баги нерідко комбінуються з помилками конфігурації для більш глибокої компрометації.
Чому оплата викупу не рятує дані MongoDB
Попри обіцянки зловмисників «повернути» чи «розшифрувати» бази після оплати, немає жодних технічних гарантій, що у них взагалі є копія даних. Багато кампаній проти MongoDB обмежуються простим видаленням вмісту без шифрування та без резервного копіювання. У такому разі навіть за бажання атакувальники фізично не можуть відновити інформацію.
Сценарій, коли організація платить, але не отримує нічого, залишається типовим. Тому провідні регулятори з кібербезпеки та галузеві стандарти не рекомендують вести переговори з шантажистами та сплачувати викуп, роблячи акцент на профілактиці, правильній конфігурації й резервному копіюванні критичних баз даних.
Практичний захист MongoDB: технічні кроки для адміністраторів
Щоб мінімізувати ризик атак на MongoDB, варто вибудувати багаторівневий захист. Ключові рекомендації включають:
1. Обмеження мережевого доступу.
Не відкривати MongoDB напряму в інтернет без крайньої необхідності: налаштувати bind_ip на локальні інтерфейси, фільтрувати доступ через файрволи, використовувати VPN або bastion-хости для адміністрування.
2. Увімкнена аутентифікація та сильні паролі.
Активувати механізми автентифікації MongoDB, створювати окремі облікові записи з мінімально необхідними привілеями, заборонити «гостьові» доступи та типові логін/пароль.
3. Безпечні налаштування в Kubernetes та хмарі.
За роботи MongoDB у Kubernetes або в публічних хмарах налаштовувати network policies, групи безпеки та ACL так, щоб до сервісу мали доступ лише потрібні підмережі та сервіси, не копіюючи приклади з інтернету без адаптації до власної моделі загроз.
4. Оновлення та управління вразливостями.
Регулярно оновлювати MongoDB та суміжні компоненти, використовувати сканери вразливостей, інвентаризувати відкриті порти й реагувати на результати перевірок.
5. Резервне копіювання та перевірка відновлення.
Надійні, ізольовані та регулярно протестовані бекапи — єдиний гарантований спосіб відновлення після атаки-вимагання або випадкового видалення даних. Копії мають зберігатися окремо від продакшн-серверів і не бути доступними за тими самими обліковими записами.
Автоматизовані атаки на відкриті MongoDB наочно демонструють, як одна помилка в конфігурації може коштувати повної втрати критичних даних. Організаціям варто провести інвентаризацію всіх серверів баз даних, перевірити доступність портів з інтернету, налаштувати аутентифікацію та шифрування трафіку, а також впровадити регулярне резервне копіювання. Чим раніше будуть усунуті відкриті порти та слабкі налаштування безпеки MongoDB, тим менша ймовірність, що наступна записка з вимогою викупу з’явиться саме у вашій базі даних.
