Як зловмисники будуть атакувати та використовувати контейнери? Це питання, над яким я постійно думаю. Я працюю в цій сфері вже більше двох десятиліть, і мені здається, що я повинен мати відповідь. Але я ні.
Натомість у мене є багато різних ідей, жодну з яких я не можу назвати правильною. Частково ця нерішучість пов’язана з тим, що я весь час вивчав безпеку в «застарілому» світі. Контейнери насправді не мають аналога. Звичайно, віртуальні машини (ВМ) часто пов’язують з контейнерами, але вони ніколи не могли масштабуватися, як контейнери. Вони також використовуються для зовсім інших цілей, ніж контейнери. Потрібен деякий час, щоб скорегувати своє мислення та зрозуміти, де контейнери насправді вписуються в поверхню атаки.
Публічні приклади атак на контейнерні середовища дуже обмежені. Зломи майже завжди пов’язані з криптомайнінгом, і це серйозні атаки, але особа, яка займається реагуванням на інциденти, вважає їх невтішними. Ще одна спільність полягає в тому, що вони здебільшого є результатом неправильної конфігурації, будь то в Kubernetes або хмарному обліковому записі. Поєднання мотивів і тактики поки що не дуже надихає.
Старий шлях
Уразливості віддаленого виконання коду (RCE) протягом тривалого часу були основною проблемою в системі комп’ютерної безпеки. Вони все ще є, але як цей спосіб мислення застосовується до контейнерів? Легко відразу перейти до RCE як до основної загрози, але це, здається, не правильний спосіб підходу до контейнерів. З одного боку, контейнери часто дуже недовговічні – 44% контейнерів живуть менше п'яти хвилин – тож зловмисник повинен бути швидким.
Цей підхід також передбачає, що контейнер відкритий для Інтернету. Звичайно, деякі контейнери налаштовані таким чином, але часто вони дуже прості та використовують добре перевірені технології, такі як NGINX. Можливо, для цих заявок є нульові дні, але вони будуть надзвичайно цінними та важкодоступними. Мій досвід показав мені, що багато контейнерів використовуються внутрішньо і не підключаються безпосередньо до Інтернету. У цьому випадку сценарій RCE стає набагато складнішим. Я повинен згадати log4j, хоча такі види вразливостей можуть бути використані дистанційно, навіть якщо вразлива система не на межі.
Новий шлях
Якщо RCE не є найбільшою загрозою для контейнерів, то що? Чи є контейнери навіть на радарі загрозливих акторів? Так, контейнери та їх допоміжна інфраструктура надто важливі, щоб їх ігнорувати. Програмне забезпечення для оркестровки контейнерів дозволило масштабувати робочі навантаження в контейнерах до неймовірної кількості. Тенденція використання також зростає, тому ви можете бути впевнені, що вони стануть ціллю. Їх просто не можна розглядати як сервери, на які ви потрапляєте через уразливості RCE.
Натомість насправді вірно навпаки. Замість того, щоб атакувати контейнери ззовні, їх потрібно атакувати зсередини. Це, по суті, те, що роблять атаки на ланцюги поставок. Ланцюг поставок є надзвичайно ефективним вектором атаки на контейнери, коли ви починаєте розуміти, як вони побудовані. Контейнер починається з файлу визначення, наприклад Dockerfile, який визначає все, що буде в контейнері під час його запуску. Після створення він перетворюється на образ, і цей образ може перетворюватися на робоче навантаження незліченну кількість разів. Якщо щось у цьому файлі визначення скомпрометовано, кожне окреме робоче навантаження, яке виконується, буде скомпрометовано.
Контейнери часто, але не завжди, спеціально створені з програмою, яка щось робить і завершує роботу. Ці програми можуть бути майже будь-якими — важливо розуміти, наскільки багато створено з використанням бібліотек із закритим чи відкритим кодом, написаних іншими людьми. На GitHub є мільйони проектів, і це не єдине сховище коду. Як ми бачили на прикладі SolarWinds, закрите джерело також вразливе до атак на ланцюг поставок.
Атака на ланцюжок поставок є чудовим способом для загроз потрапити в контейнерне середовище цілі. Вони навіть можуть дозволити інфраструктурі клієнта масштабувати атаку за них, якщо компроміс залишиться непоміченим. Цей тип сценарію вже розігрується, як ми бачили з Порушення Codecov. Але це важко виявити через те, наскільки все це нове і через те, що наше мислення все ще коріниться в проблемах минулого.
шлях вперед
Як і для вирішення більшості проблем, видимість зазвичай є чудовим місцем для початку. Важко виправити те, чого ти не бачиш. Щоб убезпечити ваші контейнери, вам потрібно мати видимість самих контейнерів, а також усього трубопроводу, який їх створює. Керування вразливістю — це один із типів видимості, який необхідно інтегрувати в конвеєр збірки. Я б також включив інші інструменти статичного аналізу, такі як ті, які також шукають витік секретів. Оскільки насправді неможливо передбачити, як виглядає атака на ланцюжок поставок, моніторинг часу виконання стає критичним, щоб ви точно знали, що роблять ваші контейнери.
