Вразливі базові образи

Що таке Вразливі базові образи?

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

Що ви дізнаєтесь у Вразливі базові образи

• Шар під вашим застосунком змінюється без чийогось свідомого рішення, тому ви не можете сказати, які пакети ОС перебувають у продакшні або коли вони востаннє змінювалися.
• Те, що кожна збірка отримує абсолютно однакові байти, тому зміна базового образу — це свідомий, доступний для рев'ю коміт, а не непомітна подія.
• Свідома періодичність перезбирання, оскільки закріплений базовий образ перестає отримувати патчі, доки хтось не змінить закріплення.
• Вада міститься в шарі ОС під застосунком, тому жоден файл залежностей її не згадує, а виправлення — це зміна базового образу, а не оновлення пакета.

Вразливі базові образи — Кроки навчання

1. Образ планувальника в реєстрі

   Bob має доступ на читання до контейнерного реєстру Bremhollow через витік robot-токена. Він дивиться не на код — а на те, наскільки свіжі образи, адже сервіс, який давно не перезбирали, — це сервіс, чий базовий образ тихо застарів. Планувальник обробляє завантажені зображення, тому те, на чому він побудований, дуже його цікавить. Відкрийте його сторінку та подивіться, що каже реєстр.

2. Образ, що перестав оновлюватися

   Реєстру не потрібно помилятися, щоб допомогти Bob. Один рядок повідомляє йому, що розгорнутий образ старий і побудований на «плаваючій» базі.

3. Просканувати базу в пошуках шляху проникнення

   Bob підтягує образ і запускає над ним сканер вразливостей — той самий інструмент, яким скористався б захисник. Його не цікавить код застосунку. Йому потрібна відома, опублікована вразливість у пакетах операційної системи, які притягнув базовий образ, адже до таких зазвичай є робочі експлойти.

4. Перетворити CVE на шелл

   Знахідка сканера не є експлойтом, доки хтось її не запустить. Для CVE-2023-4863 існує публічний proof-of-concept: спеціально сформований WebP-файл, що переповнює libwebp у момент декодування. Планувальник декодує кожне завантажене зображення, тому Bob монтує PoC-файл у одноразовий запуск вразливого образу й декодує його — доводячи, що знахідка є робочим шляхом віддаленого виконання коду, ще до того, як торкнутися продакшну.

5. Де живе вразливість

   Один момент на механізм, перш ніж почнеться реагування.

6. Сканер позначає весь флот

   Bremhollow додала сканування образів у свій пайплайн, і перше повне сканування того, що вже працює в продакшн, повернуло дещо, що не може чекати.

7. Переконайтеся самі

   Перш ніж щось змінювати, Alice запускає те саме сканування на розгорнутому образі. Вона хоче побачити знахідку, зрозуміти, де вона перебуває, і яка насправді ця база.

8. Відкриття Dockerfile

   Базовий образ обирається одним рядком у Dockerfile. Усе, що знайшов сканер, приїхало саме на цьому рядку.

9. Знайти «плаваючу» базу

   Тут немає жодної одруківки чи хиби формату. Проблема — в одному рядку, який каже менше, ніж мав би.

10. Закріпити базу за digest

    Тег — це мітка, яку хтось може перемістити; digest — це відбиток вмісту образу, і він ніколи не може вказувати на щось інше. Alice закріплює базу на точному, актуальному, «худому» node:18 за його digest, тож відтепер кожна збірка підтягує ті самі перевірені байти, а переміщення цього закріплення стає свідомою, підконтрольною зміною.