Автор: Андрій Михалюк, CEO CoreWin
Лише нещодавно ми опублікували список гучних кейсів витоку даних в 2023. Але один з них є особливим і яскраво виділяється серед інших. Не тільки в 2023, але, певно, і загалом в історії інформаційної безпеки. Звісно, я маю на увазі вразливість MOVEit і пов’язані з нею витоки даних. В чому ж її унікальність? Щоб це зрозуміти, звернемось до історії витоків, спричинених цією вразливістю:
- 1 червня. Виявлення вразливості, витік даних клієнтів MOVEit, як-от: Zellis, British Airways і BBC.
- 20 липня. Витік даних PockerStars, що стосувався персональної інформації 110 000 клієнтів.
- 27 липня. Витік даних Maximus (держ. підрядник США), який зачепив до 11 мільйонів громадян США.
- 8 серпня. Викрадення даних пацієнтів Missouri Medicaid.
- 11 серпня. Викрадення даних 4.1 мільйона пацієнтів з систем IBM.
- 25 вересня. Витік даних 3.4 мільйона осіб з реєстру народжень Онтаріо.
І це тільки найгучніші кейси. Серед інших організацій, що стикнулися з витоком даних через цю вразливість, варто згадати IT-компанію Norton LifeLock, яка спеціалізується на безпеці особистих даних (дещо іронічно, як на мене).
Як бачимо, ця вразливість проявила себе не один раз, адже кількість і масштаб інцидентів зростали аж до жовтня, тобто майже півроку, і в сумі спричинили витік щонайменше 18.6 млн записів. Спробуємо розібратись, чому тривіальна, на перший погляд, вразливість виявилась настільки «живучою» і завдавала клопоту кібербезпеці стільки часу.
Спочатку база. Що таке MOVEit?
MOVEit – це програмний продукт для керованої передачі файлів, створений компанією Ipswitch, Inc. (зараз є частиною Progress Software). Він шифрує файли та використовує для передачі даних протоколи передачі файлів, такі як FTP(S) або SFTP, а також надає послуги автоматизації, аналітику та параметри відновлення після відмови. Простими словами – це корпоративна файлова шара, яка може бути розгорнута як і в хмарі, так і локально. Саме локальне розгортання дозволило системі завоювати сильні позиції у сфері медичного обслуговування, де діють жорсткі регулювання щодо безпеки даних пацієнтів.
Крок 2. Що за вразливість?
Якщо коротко – SQL-ін’єкція. Так-так, саме цей найвідоміший на наших теренах тип вразливостей. Відомий ще з далекого 1998, наче добре відомий всім, і все ж, хоча синтаксис SQL не змінюється десятиліттями, а такі вразливості все повертаються в наше життя. Коротко про те, що таке SQL Injection, ми розглядали раніше у відео.
Самі деталі атаки описані тут. Ми трохи пізніше пройдемось, як захиститись від вразливості, але наразі найголовніше, що треба зробити, якщо ви користуєтесь цим рішенням – встановити оновлення. Як кажуть – ЗЗП (завжди застосовуй патч).
Тепер коротко про те, що робити, якщо у вас вже стоїть MOVEit, і ви ним користуєтесь.
Можна поставити на сервер, де стоїть рішення Wazuh, або інший vulnerability management. Коротко модуль Wazuh описано тут. Це спрацює, оскільки вразливість вже відома, присутня у базах CVE, і відповідно агент знайде її (як і інші вразливості) автоматично. Їх залишиться тільки виправити.
Щодо виправлення конкретно цієї вразливості
Для початку, щоб захистити свою компанію від атаки MOVEit, ви повинні дотримуватися порад щодо безпеки від Progress Software, постачальника служби MOVEit Transfer. А саме:
- Якнайшвидше застосуйте оновлення.
- Додайте в білий список трафік на портах 80 і 443 до сервера MOVEit Transfer, щоб запобігти зовнішньому доступу до вебінтерфейсу користувача.
- Перевірте папку C:\MOVEit Transfer\wwwroot\ на наявність підозрілих файлів, таких як резервні копії або завантаження великих файлів.
- Увімкніть журналювання та аудит на сервері MOVEit Transfer і відстежуйте будь-яку незвичайну активність (тут допоможе підключення SIEM Wazuh, хоча для цього і треба буде додати декодер і правило).
- Використовуйте брандмауер або інші інструменти безпеки, щоб заблокувати доступ до відомих шкідливих доменів або IP-адрес, пов’язаних з атакою.
Перевірте наявність будь-яких індикаторів компрометації (IoC), які можуть свідчити про те, що ваша компанія постраждала від атаки. Деякі з IoC, пов’язані з атакою MOVEit, включають:
- Сценарії, завантажені в папку C:\MOVEit Transfer\wwwroot\, як-от backup.aspx, backup.aspx.cs, backup.aspx.designer.cs, backup.aspx.resx, download.aspx, download.aspx.cs, download.aspx.designer.cs, download.aspx.resx.
- IP-адреси команди та керування (C2), які взаємодіють із вебоболонками, наприклад 185.141.25[.]27, 185.141.25[.]58 та 185.141.26[.]98.
- Облікові записи користувачів, створені або видалені на сервері MOVEit Transfer, наприклад admin.
- Інструкції SQL або помилки в журналах передавання MOVEit.
- Незвичайна діяльність або трафік на портах 80 і 443 до сервера MOVEit Transfer.
На додаток до вищесказаного, варто регулярно створювати резервні копії даних, тримати бекапи на іншому сервері, ніж сам MOVEit, оновлювати все програмне забезпечення та операційні системи, запроваджувати політику надійних паролів і навчати співробітників про фішингові атаки.
Загалом варто відзначити, що Progerss дуже професійно відреагували на вразливість, швидко закривши її, але на цьому не зупинились та закрили ряд інших пов’язаних вразливостей, які не встигли виявити хакери.
Про організаторів кібератак
Тепер крок 3. За першою атакою стояли російські хакери CLOP group (далі по тексту: «ЙР»). На момент атаки ця вразливість була zero-day, тобто не відома загалу, а отже у спільноти кібербезпеки було 0 днів на її виправлення. Але, як пишуть багато спеціалістів, ЙР знала про цю вразливість достатньо довго, увійшовши на бекенд хмарної версії системи, отримавши до неї доступ, а далі вірусом-шифрувальником зашифрувавши дані і викачавши бази собі. Далі відбувся ряд торгів, де ЙР вимагала гроші від компаній за відновлення і непублікацію втрачених даних. Хтось домовився, хтось відправив ЙР за всім відомою адресою. В цілому схема типова для руснявих вірусів-шифрувальників.
Наче все. Так? Але залишилось одне питання. Чому на цьому все не закінчилось? А річ у тому, як я писав вище, багато організацій ставлять сервер MOVEit локально, для безпечного обміну даними зі своїми клієнтами. І ось тут стає цікаво. Виявляється, не всі підрядники вчасно оновили свої системи, залишили їх вразливими, і на момент, коли ця вразливість стала відома всьому світу (прикладом є PoC вразливості трохи вище) – вони виявились вразливими. Чим і скористались всі кому не лінь, сама ж ЙР не відставала і збільшила кількість цілей, розповсюджуючи бази даних через торенти. На цей момент стало відомо, що більше 100 організацій постраждали від цієї атаки. Або прямо, або опосередковано через підрядників. В тому числі держ. організацій США. У відповідь на що була оголошена винагорода у розмірі 10 млн USD за інформацію про ЙР.
Тобто тут особливістю стало те, що ця система використовувалась для активного обміну даними підрядників з клієнтами. Як бачимо, тренд Supply Chain Attack залишається мейнстрімним в тій чи іншій формі. Наразі питання як боротись з таким типом ризиків залишається відкритим, але перші напрацювання в цій сфері є. Приміром, наша команда в колаборації з ResilientX запустила відкритий безкоштовний ранній доступ до системи, яка якраз створена побороти Supply Chain Attacks методом перевірки вразливості публічних IT-активів підрядників компанії.
