Що може піти не так CI/CD pipelines?

Безперервна інтеграція та безперервна доставка (CI/CD) pipelineє основою будь-якої організації-розробника програмного забезпечення, яка створює програмне забезпечення «сучасним» способом. Автоматизація надає величезні можливості, але більшість розробників не усвідомлюють відповідальності, яку вона несе.

РозробникТак, ми беремо CI/CD безпеку серйозно та мати сильний контроль над розробниками коду, переглядати commitперед злиттями; завдання та pipelineпідтримуються старшим персоналом, вони дбають про те, щоб не розголошувати секрети pipelineс. А інструмент встановили фахівці, які знаються на цій справі. Що може піти не так?

Шановний розробнику, CI/CD Системи складні. Його широка зона атаки приваблювала зловмисників. Краще бути обережним і ніколи не бути надто самовпевненим.

Іноді зберігається конфігурація за замовчуванням, що стає найкращим другом для хакерів. Критичні недоліки можуть бути присутніми в CI/CD pipeline джерел, у конфігурації системи або навколо процесу та контексту pipeline і як це спрацьовує.

У цій публікації ми поставимо себе на місце лиходіїв. Уявіть, що ми читаємо роздуми М3М3Н70 (Memento Mori?) та Болотна лють десь у темній мережі, ймовірно, якоюсь не західною мовою, але ніколи не пропускайте, що зло поширюється по всьому світу.

 

У добрі старі часи це було так просто…

М3М3Н70Повертаючись до старих добрих часів, наш бізнес був таким простим… Нульові дні були легкодоступними, додатки були широко доступними з легкими для використання вразливостями, і ми могли миттєво змінити ситуацію.

Болотна лють: Фу#@Чорт! Десь тут є якісь тупі мозки, але все змінилося. Великі хлопці вклали купу грошей у це лайно з AppSec.

М3М3Н70Так. Але нові дурні — це розробники. Для нас було легше обрати інструменти, які використовують ці хлопці. Зокрема, неперервна інтеграція — це золота жила! Токени доступу до хмари, SCM облікові дані, паролі виробничої бази даних, закриті ключі SSH, облікові дані інших користувачів неперервної інтеграції… Перехід від нудних розробницьких речей до справжньої суті був досить тривіальним.

Автоматизація для створення, тестування та розгортання програмного забезпечення за допомогою CI/CD Інструмент часто потребує покрокової передачі секретів командам. І часто вони витікають, що має сумнозвісні наслідки.

Pipelineпотрібні секрети, які іноді витікають

M3M3N70: The code monkeys slipped their AWS keys in a pipeline on a GitHub commit, later they removed the thing but not changed git history. For our scripts it was trivial to scan the history, grab the key and wreak havoc.

Можливо, у добрі старі часи в історії Git можна було знайти .env файл (розробник забув додати його до .gitignore):

AWS_ACCESS_KEY_ID=AKIA...
AWS_SECRET_ACCESS_KEY=wJalrXUtn...
AWS_REGION=us-east-1
APP_FOLDER=...
S3BUCKET=...

який використовувався в робочому процесі GitHub .github/deploy.yaml що містив щось на кшталт цього:

jobs:
  build:
    name: Automated build and deployment into AWS
    runs-on: 	ubuntu-22.04
    steps:
      # Load environment from .env file
      - id: dotenv
        uses: falti/dotenv-action@v1.0.2
        
      - name: Configure AWS Credentials
        uses:
        with:
          args: --acl public-read --follow-symlinks --delete 
          aws-access-key-id: $
          aws-secret-access-key: $
          aws-region: $
      
      # ... build steps skipped ...
      
      -  name: Upload compiled code for deployment
         working-directory: $/packaged_app
         run: aws s3 cp my-app.zip s3://$ 
         
      - name: Deploy the app
        run: aws deploy create-deployment ...

M3M3N70: вау! Ці ключі AWS працювали! Спочатку ми протестували незначну зміну в додатку, а потім додали жало, оскільки ці хлопці, здавалося, не підозрювали. Бінго! Яка кампанія…

Зловмисник просто використав ключі AWS для завантаження модифікованого застосунку зі шкідливим програмним забезпеченням, а потім виконав команду розгортання з цими обліковими даними. Витік секретів разом з інформацією, що міститься в pipeline«Яка кампанія!», ймовірно, означає, що «Мементо» завдала шкоди бідній жертві.

Що Memento нам тут каже, так це те, що після витоку секретної інформації, як-от ключі доступу AWS у прикладі, вам потрібно скасувати секретну інформацію (ротувати вищевказані ключі). негайноЗавжди є вікно експозиції між протіканням commit та таємне визнання недійсним; Переписування історії Git – складне завдання (навіть найжорсткіша авторитарна держава намагалася переписати історію, але безуспішно) і, ймовірно, неефективно (наші друзі могли б клонувати до сховища з секретним витоком commit). Негайно поверніть ключі та моліться, читаючи журнали активності цільового облікового запису протягом періоду експозиції!

Ймовірно, організаціям слід заборона використання довгострокових секретів у CI/CD pipelines, та замініть їх тимчасовими обліковими даними. У попередньому прикладі з ключами AWS у діях GitHub безпечніше використовувати Постачальник OpenID Connect (OIDC) отримати короткочасні облікові дані, необхідні для дій.

Болотна лютьВам так пощастило! Витік скриптів із жорстко закодованими ключами був поширеною практикою в минулому, навіть у публічно доступних S3-баках. Все, що вам потрібно було зробити, це пройтися по об'єктах у баку та виконати grepping, щоб знайти цікаві речі.

Іноді область, яка використовувалася для розгортання (у цьому прикладі корзина AWS S3), була відкрита для читання сторонніми особами через недолік конфігурації (який залишився непоміченим). Що Болотна лють використовувалося щось на кшталт цього:

aws s3 ls --recursive s3://<bucket_name>/<path>/ | \
awk '{print $4}' | \
xargs -I FNAME sh -c "echo FNAME; \
  aws s3 cp s3://<bucket_name>/FNAME - | \
  grep '<regex_pattern>'"

Відро, ймовірно, було створено в шаблоні підготовки, який можна було автоматично сканувати на наявність недоліків безпеки.

Конфігурація інструменту за замовчуванням була для нас іграшкою

Щоб навести конкретні приклади, давайте поговоримо про Дженкінс, один з найпопулярніших інструментів неперервної інтеграції (CI).

Болотна лютьВи пам’ятаєте той прапорець «Увімкнути безпеку» в Jenkins, і скільки організацій вирішили не активувати його заради зручності? А ті «Будь-хто може зробити що завгодно«комбінації дозволів за замовчуванням»? А ці надокучливі плагіни Jenkins, як-от Плагін OAuth для GitHubХлопець, який це налаштовував, вибрав обидва варіанти: «Надати права на ЧИТАННЯ всім автентифікованим користувачам» та «Використовувати дозволи репозиторію GitHub», що дало нам доступ до всіх їхніх проектів.

(Вибач, Дженкінс, що навів тебе як приклад 😉

Будьте уважними (навіть залежними) до принципів безпеки. Один з них — Безпечно за замовчуванням принцип: елементи керування повинні за замовчуванням використовувати максимально безпечні налаштування. Безпека має бути вбудована CI/CD інструменти та pipelineз нуля, а не як другорядна думка. Але зручність використання та зручність часто суперечать безпеці.

У випадку з Jenkins вбудована автентифікація є занадто крихкою: ніколи не використовуйте вбудовані механізми автентифікації в JenkinsКраще обрати сторонній механізм (SAML, LDAP, Google…) із плагіном Role-based Authorization Strategy («RBAC»). І будьте вкрай обережні з admin рахунок.

Подбайте про те, як працюєте та pipeline обробляються файли в Jenkins. Те саме стосується Плагін Configuration-as-Code та його конфігураційні файли, які застосовуються до конфігурації Jenkins.

Перехід з власного хостингу CI/CD Перехід систем до хмарних SaaS-систем усуває деякі потенційні ризики, дозволяючи горизонтальне переміщення в мережі організації, але додає інші, як-от необхідність відкривати зовнішні з'єднання між існуючими внутрішніми системами та екстерналізованими. CI/CD інструмент.

Організації повинні докласти зусильcisналежної обережності при загартуванні CI/CD систему, починаючи з найбільш обмежувальних налаштувань і поступово відкриваючи мінімально необхідні дозволи для pipeline кроки.

Налаштування безпеки в CI/CD інструменти можуть бути складним завданням. Багато з них мають плагіни або розширення, які мають більшість вразливостей і потребують оновлення.

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

Впровадження коду в pipeline команди для розваги та прибутку

М3М3Н70Ви коли-небудь використовували перевірку ненадійного коду, що вразливі дії та скрипти, вразливі до введення команд?

У цьому розділі показано, що pipeline сам по собі може містити помилки кодування, які дозволяють зловмисникам впроваджувати довільне виконання коду в pipeline без зміни pipeline саме джерелоНаприклад, використовуючи PR

Перший приклад невдалий робочий процес GitHub:

# INSECURE. Provided as an example only.
on:
  pull_request_target #1

jobs:
  build:
    name: Build and test
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
        with:
          ref: $ #2

      - uses: actions/setup-node@v1
      - run: |
          npm install #3
          npm build
      # ... more steps ...

Об'єднання pull_request_target Тригер робочого процесу з явним отриманням ненадійного запиту на перевірку є небезпечною практикою, яка може призвести до компрометації репозиторію. У цьому прикладі невдала комбінація:

• pull_request_target подія, яка за замовчуванням має дозвіл на запис до цільового репозиторію та секретів цільового репозиторію, навіть із зовнішніх форків, та виконується в контексті цільового репозиторію PR,
• перевірте PR-код з вихідного коду, ненадійний репозиторій,
• запускати будь-який скрипт, який може працювати з контентом, контрольованим PR, як у випадку npm install та
• невикористання умови для запуску pull_request_target подію запускати, лише якщо запиту на заповнення призначено певну мітку типу «цей запит на заповнення було перевірено» (зовнішні користувачі не можуть призначати запиту на заповнення мітки).

Другий приклад використовує ненадійні дані (з проблеми, коментаря чи pull request) як джерело аргументів, що передаються до pipeline команда за допомогою виразів. Це pipeline версія вразливості впровадження команд ОС.

- name: Check title
  run: |
    title="$"
    if [[ ! $title =~ ^.*:\ .*$ ]]; then
      echo "Bad issue title"
      exit 1
    fi

Операція запуску генерує тимчасовий скрипт оболонки на основі шаблону з $ замінено, що робить його вразливим до ін'єкцій команд оболонки. Зловмисник із підробленим обліковим записом GitHub може створити проблему із заголовком a"; bad_code_goes_here;#, і бум! 

Болотна лютьО, ці хлопці відкривали двері для введення команд, просто відкриваючи проблему…

У діях GitHub були вразливості виконання коду, такі як gajira-comment, тепер виправлено. Будь ласка, прочитайте «Ненадійний вхід у робочих процесах GitHub» для отримання повної інформації.

Мораль цієї історії: Ніколи не перевіряйте та не створюйте PR-запит на ненадійних джерелах, не переглянувши його попередньо. «Ненадійний» тут, окрім випадків драконівської автентифікації походження, може означати будь-який потенційно викрадений обліковий запис розробника.

 

Ненавмисне розгортання шкідливого програмного забезпечення тут!

Безперервне розгортання є кульмінацією автоматизації, але ця кульмінація може бути зірвана відсутністю належного контролю затвердження на pipeline потік.

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

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

Вони зачиняють двері

Болотна лютьЦі радісні паролі за замовчуванням у CI/CD інструменти стираються. Доступ до /var/lib/jenkins/secrets/initialAdminPassword зараз глухий кут. Багато інструментів зараз пропонують 2FA, яку Covid зробив популярною, і навіть найлінивіші кодери використовують її!

М3М3Н70Ми боремося з двофакторною автентифікацією, але це не так просто. Важко підібрати цих хлопців за допомогою фішингу, оскільки «Scatter Swine» зробив з TwilioЗ ключами WebAuthn це набагато складніше. Принаймні, ми можемо спробувати крадіжка файлів cookie для обходу багатофакторної автентифікації, але потрібно зазирнути у скриньку розробника.

Багатофакторна автентифікація – це хороший крок у правильному напрямку для обмеження ризику витоку секретів автентифікації. Більшість сучасних інструментів DevOps підтримують MFA. А ключі автентифікації під WebAuthn / U2F (див. Проєкт FIDO2) є, мабуть, найкращим варіантом для MFA в DevOps, за умови належного управління.

Болотна лютьХлопці з DevOps прокидаються. У них у крові ця клята річ «найменших привілеїв». І вони більше не програмні мавпи. Тепер нас ловлять на гарячому рецензенти.

Насправді, pipelineзараз трохи надійніші, ніж пару років тому, з видаленими слабкими діями та скриптами, а також з додатковими кроками тестування безпеки, які навіть виявили наші дроппери, приховані в прихованому режимі. commitта пакети, які ми викрали.

Запитання до читача: чи є процес створення програмного забезпечення з вихідних кодів та розгортання у продакшені ризикованою справою? Чи можете ви уявити свій DevOps на стадії... старі добрі часи для поганих хлопців?

Заключні рекомендації

З чого почати CI/CD pipelines?

Перша рекомендація тут проста: обережно огляд pipelines (вони є критичний ресурси) для вирішення питань безпеки. Перевірки є дорогими, але необхідними, і їх слід проводити належним чином. Рецензенти повинні знати, на що звертати увагу. Кожен крок необхідно перевірити на наявність недоліків.

Можливо, допоможе поєднання експертів-рецензентів, озброєних автоматизованими сканерами шкідливого коду.

Друга рекомендація полягає в тому, щоб навчати розробників, які пишуть pipelineта зберігати їх у безпеціЩо слід врахувати:

• Як правильно обробляти автентифікацію за допомогою внутрішніх та хмарних сервісів, уникаючи незручностей, пов'язаних з обробкою довгострокових облікових даних.
• Як обмежити pipelineдо точного набору ресурсів, до яких йому потрібен доступ. Принцип найменших привілеїв знову сяє.
• Як написати кроки для створення pipelineвідтворюваність, як-от закріплення версій, та уникнення вразливостей, пов'язаних з впровадженням команд.
• Як схвалити розгортання з точки зору безпеки (вони ж інші!): які засоби безпеки standards повинні бути зіставлені та як додати відповідні перевірки/гейти в pipelines.

Третя рекомендація полягає в тому, налаштувати CI/CD систему з належною обережністюНадійна автентифікація, відсутність паролів за замовчуванням або незахищених налаштувань, мінімальні привілеї… Подбайте про вразливості у встановлених плагінах та розширеннях. Це може бути темою наступних публікацій, будь ласка, слідкуйте за оновленнями.

Четверта рекомендація полягає в тому, щоб використовувати CI/CD pipelineдля автоматизації безпекиАналіз вихідного коду (SAST), аналіз складу джерела (SCA), сканування витоків секретів, інструменти захисту від шкідливого програмного забезпечення, сканери безпеки контейнерів або автоматизовані детектори часу виконання (DAST та шкідливе програмне забезпечення) можуть бути регулярно запущені на pipelineІ ваша організація може забезпечити дотримання standardпро висвітлення сканування безпеки в CI/CD.

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

Якщо ви добре знайомі з десяткою найкращих OWASP, то гарним нещодавнім проектом є OWASP Топ 10 CI/CD Ризик безпеки.

Застереження

(1) У прикладах у цій публікації використовується GitHub як SCM, AWS як хмарний постачальник, а також GitHub Actions або Jenkins як CI/CD інструмент. Вони не слабші/безпечніші за свої альтернативи. Без жодних намірів поганої репутації! Ці інструменти потужні та потребують належного використання.

(2) М3М3Н70 та  Болотна лють є вигаданими персонажами. Будь-яка схожість з особами чи групами, живими чи мертвими, є випадковою… чи не так?

Щоб читати більше

• Хеймор, А. та ін. «10 реальних історій про те, як ми пішли на компроміс» CI/CD pipelines ”Група NCC, січень 2022 р.
• configure-aws-credentials Дія GitHub та  Налаштування OpenID Connect в Amazon Web Services для отримання детальної інформації про те, як запускати команди AWS для розгортання в робочих процесах GitHub.
• Лобачевський Й. «Забезпечення безпеки ваших дій та робочих процесів GitHub. Частина 1: Запобігання pwn-запитам»Лабораторія безпеки GitLab, грудень 2020 р.
• Лобачевський Й. «Забезпечення безпеки ваших дій та робочих процесів GitHub. Частина 2: Ненадійний вхід»Лабораторія безпеки GitLab, січень 2021 р.
• ОВАСП. «Топ-10 OWASP» CI/CD Ризики безпеки"Липень 2022 року.
• Сальцер Дж. та Шредер М. «Захист інформації в комп’ютерних системах»Квітень 1975 року. Принципи безпеки розвивалися разом із розвитком технологій, але 47 років потому більшість ідей безпеки та безпеки залишаються чинними.
• NCSC Великої Британії. «Забезпечити безпеку збірки та розгортання» pipeline"Національний центр кібербезпеки Великої Британії, лютий 2019 р.