Supply Chain Attack: як із цим боротися

Усім привіт. Мене звати Данило. Працюю вже два роки на посаді Security Support Engineer. Маю різні сертифікації з безпекових продуктів, а також у вільний час пишу конектори до SIEM-рішення. Сьогодні хотів би поговорити про Supply Chain Attack.

Кількість Supply Chain Attack виросла втричі за 2023 рік. В останніх найгучніших інцидентах цей тип вразливості був або складовою атаки, або взагалі виступав основним елементом інциденту. Для підтвердження своїх слів наведу декілька прикладів:

1. SolariGate: вразливість, яку допустив дуже іменитий розробник, чиєю системою користуються тисячі компаній у всьому світі, скомпрометувала безліч систем.
2. Log4shell: дуже поширена бібліотека Java виявилась вразливою, і підрядники повинні були швидко зреагувати, багато хто з цим зволікав, тому кількість скомпрометованих систем справді вражала.
3. attack13: багато державних порталів і систем були скомпрометовані через підрядника, що власне і писав та підтримував портали (принаймні це одна з версій подій).
4. Наймасовіша атака 2023 — вразливість MoveIT та нездатність підрядників, які використовували цю систему обміну даними, вчасно закрити вразливість.

Думаю, що прикладів достатньо для того, щоб зрозуміти — проблема реальна та серйозна.

Трохи бази. Що таке Supply Chain Attack

Це кібератака, спрямована на завдання шкоди організації шляхом націлювання на менш безпечні елементи в ланцюзі поставок. Тобто злам чи зараження постачальників, підрядників, інтеграторів, консультантів і таке інше.

Перш ніж здійснити атаку, зловмисники повинні отримати доступ до сторонньої системи, застосунку або інструменту, що використовує підрядник з метою зараження шкідливим ПЗ. Ця початкова стадія кібератаки також відома як upstream-атака.

Після того, як доступ до інфраструктури підрядника отримано, відбувається друга фаза, так звана downstream-атака, яка досягає кінцевої мети, використовуючи різні способи. Найчастіше зловмисники використовують браузер або ПЗ користувачів, запускаючи шкідливі програми під виглядом оновлень.

Якщо коротко, то upstream-атака відбувається, коли зловмисник додає шкідливий код до програмного забезпечення підрядника. Після цього здійснюється downstream-атака — шкідливе програмне забезпечення запускається на пристроях кінцевих користувачів через звичайне оновлення, відбувається компрометація організації.

Загалом до цього класу вразливостей придивляються мало. З двох причин:

• Треба аналізувати вразливості не власної, а сторонньої інфраструктури. Як це робити — не зрозуміло.
• Багато хто не бачить в цьому сенсу, бо однаково, що там в інших. Головне, щоб у нас було все безпечно. (див. абзац вище: так, на жаль, не працює).

На теорії, думаю, можна і зупинитись, бо інтернет і так повниться великою кількістю інформації. Я ж хочу поділитись власним досвідом.

У компанії, де я працюю, ми завжди в пошуку нових, сучасних рішень. Тому коли ми помітили, що проблема зростає, а рішення немає — ми знайшли систему, яка здатна допомогти з першою причиною відсутності перевірки підрядників на кібербезпеку (не зрозуміло, як це робити).

До речі, в Україні вона зараз доступна для безкоштовного тестування — ResilientX та її модуль Cyber Exposure Management. Поділюсь своїми знахідками, можливо, вони будуть корисні спільноті.

Наперед скажу, що система аналізує тільки публічні записи, водночас не порушуючи законних прав власника IT-ресурсів.

Розглянемо приклад

Без якого IT-підрядника неможливий сучасний офіс будь-якого типу? Звісно ж, інтернет-провайдер. Без інтернету немає навіть сенсу виходити в офіс (українці це розуміють, пам’ятаючи тогорічні відключення світла).

Як об’єкт аналізу обрав інтернет-провайдера, якого не шкода (тобто руснявий). Обраний провайдер з умовної «глибинки», щоб було більше шансів знайти щось цікавеньке.

Сканування зайняло п’ять хвилин, і стало зрозуміло, що я потрапив у яблучко. Як видно зі скриншоту нижче, піддослідні, якщо і чули щось про кібербезпеку, то це було давно і неправда.

Звіт був дуже повний, по одному домену сканер розібрав всі активи, які так чи інакше «дивились» в інтернет (28 піддоменів і 13 IP-адрес). А кількість вразливостей не може не шокувати (259) — скриншот нижче.

Як ви вже зрозуміли, знахідки вражали. І, звісно, я не зміг втриматись, щоб не перевірити вірогідність хоча б частини з них.

Дуже зацікавили домени типу: ip-213.59.129.92.ufa.zelenaya.net та cctv2.ufa.zelenaya.net.128.59.213.in-addr.arpa. На перший погляд, вони видаються технічними доменами, які мають бути всередині мережі, та керуватися локальним NS, але може горе-провайдер щось наплутав та опублікував їх у світ?

ip-213.59.129.92.ufa.zelenaya.net — на цю адресу неочікувано відповідав IP 213.59.129.92 з відкритим портом 8080. І що ви думаєте? Таки справді хтось опублікував вебінтерфейс роутера у світ. Причому найпростішого — TP-Link.

А за доменом cctv2.ufa.zelenaya.net.128.59.213.in-addr.arpa відповідав IP 213.59.128.39 (так-так, в домені «перевернули» айпішник, для чого — не зрозуміло). Підозрюю, що це сервіс відеоспостереження, судячи з cctv на початку домену. Але знаєте ще що? БД цього очевидно внутрішнього сервісу — відкрита для доступу за портом 3306.

Також кидається в очі одна повторювана проблема для цього провайдера. Він користується застарілими, неоновленими інструментами. Перш за все напружив старий і дірявий вебсервер Apache, а саме 2.4.12 на IP 213.59.128.34. A це IP домену bill.ufa.zelenaya.net. І щось мені підказує (назва), що це вкрай важливий сервіс для компанії.

Приміром (і це тільки один приклад з багатьох) цей вебсервер вразливий до HTTP Request Smuggling атаки, яка призводить до обходу систем авторизації — CVE-2023-43622

Приміром:

RewriteEngine on
RewriteRule "^/here/(.*)" "http://example.com:8080/elsewhere?$1"; [P]
ProxyPassReverse /here/ http://example.com:8080/

Це може призвести до обходу елементів керування доступом на проксі-сервері, пересилання URL-адрес на наявні вихідні сервери.

На цьому я припиню цей жах, хоча там ще достатньо знахідок... Але гадаю, що головне питання, яке варто собі задати це: а чи у мого інтернет-провайдера точно краща ситуація? І з нього випливає наступне питання, як взагалі можна уберегтись від supply chain attack як таких. Я міг би виділити такі рекомендації:

Як описав вище — важливою складовою є аудит підрядників.

1. Аудит технічний. Перевірка публічних IT активів підрядника на наявність вразливостей.
2. Аудит організаційний. Проведення незалежних опитувань колективу підрядників на знання норм і стандартів кіберграмотності та проведення аудиту наявності впроваджених норм і стандартів кібербезпеки в організації.

Примітка: очевидно, що технічний аудит провести простіше, оскільки він не вимагає прямої взаємодії з підрядником.

Управління стороннім доступом. Інструменти керування доступом Zero Trust дозволяють легко налаштовувати рівні доступу для користувачів, пристроїв або робочих навантажень. Організації можуть встановлювати суворі стандарти для того, як сторонні користувачі підключаються, і можуть застосовувати мінімальний доступ. Перше, що мені спадає на думку, — це PAM (Privileged Access Management) система, але колеги досягають Zero Trust і з такими системами, як-от IAM, VPN й іншими.

Запобігання руху всередині мережі (lateral movement). Якщо зловмисники порушують мережу, варто обмежити здатність пересуватись нею. Наприклад методом мікросегментації, що означає, що зловмисники повинні пройти повторну автентифікацію, щоб отримати доступ до різних зон у мережі.

Сегментація програм і застосунків. Тобто бажано, щоб архітектура була хоча б мультисерверною, а то і комбінованою, на базі різних провайдерів. Суть в надані користувачам зстосунків для використання як SaaS, згрупувавши їх у логічні сегменти та захищати їх окремо.

Захист чутливих даних до витоку, надаючи більш строгі правила роботи з чутливими даними для облікових записів підрядників. Здається, принаймні ця проблема давно технічно вирішена різноманітними DLP (Data Loss Prevention) системами, варто їх коректно налаштовувати для підрядників.

Ну і звісно, база. А саме: антивірус, DNS та Firewall-фільтрації мають бути в будь-якому разі.

Переконаний, що ми як спільнота маємо поставити собі питання безпеки підрядників і протистояти Supply Chain Attack. Почати працювати із цим пластом загроз, який ми часто ігноруємо. Тому сподіваюсь, що мій досвід був для вас корисний.

І також запрошую всіх поділитись своїми думками чи напрацюваннями у коментарях. У дискусії народжується істина, можливо, ми зможемо її знайти разом.