Што може да тргне наопаку со CI/CD pipelines?

Континуирана интеграција и континуирана испорака (CI/CD) pipelineсе основа на секоја софтверска организација што гради софтвер на „модерен“ начин. Автоматизацијата обезбедува голема моќ, но повеќето програмери ја пропуштаат одговорноста што ја носи тоа.

СоздавачДа, земаме CI/CD безбедност сериозно и имаат силна контрола врз одржувачите на кодот, преглед commits пред спојувања; работни места и pipelineсе одржуваат од страна на виш персонал, тие се грижат да не се откријат тајни во pipelineс. И алатката ја инсталирал персонал кој ја познава работата. Што може да тргне наопаку?

Почитуван развивач, CI/CD Системите се сложени. Неговата широка површина за напад привлекуваше малигни актери. Подобро е да се биде претпазлив и никогаш да не се биде премногу самоуверен.

Стандардната конфигурација понекогаш се задржува и станува најдобар пријател за хакерите. Може да се појават критични недостатоци во CI/CD pipeline извори, во конфигурацијата на системот или околу процесот и контекстот на pipeline и како се активира.

Во овој пост ќе се ставиме во кожата на лошите актери. Замислете дека ги читаме размислувањата на M3M3N70 (Мементо Мори?) и Мочуришен бес некаде во темната мрежа, веројатно на незападен јазик, но никогаш не пропуштајте дека злото е распространето низ целиот свет.

 

Во добрите стари времиња беше толку лесно…

M3M3N70Да се ​​вратиме во добрите стари времиња, нашиот бизнис беше толку лесен… Нултите денови беа лесно достапни, апликациите беа широко отворени со лесни за експлоатација ранливости, а можевме и странично да се движиме за миг.

Мочуришен бес: Ебате! Некои се луди таму, но работите се сменија. Големите луѓе вложија многу пари во тоа AppSec срање.

M3M3N70: Да. Но, новите будали се програмерите. За нас, полесно беше да се одлучиме за алатките што ги користат овие момци. CI, особено, е златен рудник! Токени за пристап до облак, SCM акредитиви, лозинки за базата на податоци за производство, SSH приватни клучеви, акредитиви на други CI корисници… Скокнувањето од здодевните работи за програмери кон вистинската суштина беше прилично тривијално.

Автоматизација за градење, тестирање и распоредување на софтвер со 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.

Можеби добрите стари времиња беа да се најде во историјата на Гит .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 копчиња работеа! Прво тестиравме промена на inocuos во апликацијата, а потоа го додадовме sting бидејќи тие момци изгледаа несвесни. Бинго! Каква кампања…

Лошиот актер едноставно ги користел AWS клучевите за да постави изменета апликација со малициозен софтвер, а потоа ја извршил командата deploy со такви акредитиви. Протечените тајни, заедно со информациите содржани во pipeline„Каква кампања!“ веројатно значи дека Мементо предизвикал хаос кај кутрата жртва.

Она што Мементо ни го кажува овде е дека откако ќе се случи протекување на тајна, како што се клучевите за пристап до AWS во примерот, мора да ја поништите тајната (ротирајте ги горенаведените клучеви) веднашСекогаш постои прозорец за експозиција помеѓу протекувањето commit и тајното поништување; Препишувањето на историјата на Git е тешко (дури и најстрогата авторитарна држава се обиде со такво препишување на историјата, но без успех) и веројатно неефикасно (нашите пријатели можеби клонирале пред складиштето со протекувањето на тајната commit). Веднаш ротирајте ги копчињата и молете се додека читате дневници на активности за целната сметка за време на прозорецот на изложеност!

Веројатно организациите треба забрана за користење на долгорочни тајни во CI/CD pipelinesи да ги замените со временски акредитиви. Во претходниот пример со AWS клучеви во GitHub дејства, побезбедно е да се користи ОпенИД Конектикат (OIDC) провајдер за да добиете краткотрајни акредитиви потребни за дејствија.

Мочуришен бесИмавте голема среќа! Протекувањето на скрипти со хардкодирани клучеви беше вообичаена практика во старите денови, дури и на јавно достапни S3 кофи. Сè што требаше да направите е да ги поминете објектите во кофата и да направите малку пребарување за да пронајдете интересни работи.

Понекогаш областа што се користеше за распоредување (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, како што се Додаток за GitHub OAuthЧовекот што го конфигурираше ги избра и „Доделување дозволи за читање на сите автентични корисници“ и „Користење дозволи за складиштето на GitHub“, давајќи ни пристап до сите нивни проекти.

(Извини, Џенкинс, што те ставив како пример 😉)

Бидете вешти (дури и зависни) од безбедносните принципи. Еден е Безбедно по стандард принцип: контролите треба да бидат поставени на најбезбедните можни поставки. Безбедноста треба да биде вградена во CI/CD алатки и pipelineод самиот почеток, наместо да биде дополнителна мисла. Но, леснотијата на користење и практичноста честопати се судираат со безбедноста.

Во случајот на Џенкинс, вградената автентикација е премногу кревка: никогаш не ги користете вградените механизми за автентикација во JenkinsПодобро е да се одлучите за механизам од трета страна (SAML, LDAP, Google…), со додаток за стратегија за авторизација базирана на улоги („RBAC“). И бидете исклучително внимателни со admin сметка.

Грижете се за тоа како работите и pipeline датотеките во Jenkins се обработуваат. Истото важи и за Додаток за конфигурација-како-код и неговите конфигурациски датотеки, кои се однесуваат на конфигурацијата на Jenkins.

Преминување од самостојно хостирање CI/CD системи базирани на облак до SaaS системи елиминира некои потенцијални ризици што овозможуваат странично движење во рамките на мрежата на организацијата, но додадени се други, како што е потребата да се отворат надворешни врски помеѓу постојните внатрешни системи и екстернализираните CI/CD алатка.

Организациите треба да вршатcisдолжно внимание при стврднување на CI/CD систем, почнувајќи со најрестриктивните поставки и постепено отворајќи се со минималните потребни дозволи за pipeline чекори

Конфигурирање на безбедноста во CI/CD Алатките можат да бидат сложени. Многу од нив имаат додатоци или екстензии кои имаат најголем дел од ранливостите и треба да се ажурираат.

Скенерите за погрешна конфигурација на безбедноста за такви сложени алатки или бенчмарките може да помогнат.

Вметнување код во pipeline команди за забава и профит

M3M3N70Дали некогаш сте користеле Недоверливи проверки на код, кои се ранливи на инјектирање на команди?

Овој дел покажува дека 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 Активирањето на работниот тек со експлицитна проверка на недоверлив PR е опасна практика што може да доведе до компромитирање на складиштето. Во примерот, несреќната комбинација од:

• pull_request_target настан, кој по дифолт има дозвола за запишување во целното складиште и тајни на целното складиште, дури и од надворешни вилушки, и се извршува во контекст на целното складиште на PR,
• проверете го PR кодот од изворот, недоверливо складиште,
• активирајте која било скрипта што може да работи на содржини контролирани од јавноста, како во случај на npm install, и
• некористење на услов за активирање pull_request_target настанот ќе се изврши само ако на PR-от е доделена некаква етикета „овој PR беше проверен“ (надворешните корисници не можат да доделат етикети на PR-от).

Втор пример зема недоверлив влез (од проблем, коментар или pull request) како извор за аргументи предадени на pipeline команда преку изрази. Ова е pipeline верзија на ранливоста при инјектирање на командата на оперативниот систем.

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

Операцијата run генерира привремена скрипта за командната линија базирана на шаблонот, со $ заменет, што го прави ранлив на инјектирање на команди во командната линија. Напаѓач со лажна сметка на GitHub може да создаде проблем со наслов a"; bad_code_goes_here;#, и бум! 

Мочуришен бесО, тие момци ја отвораа вратата за инјектирање команди едноставно со отворање на проблем…

Имаше ранливости при извршување на код во дејствата на GitHub, како на пример коментар-на-гаџира, сега е поправено. Ве молиме прочитајте „Недоверлив влез во работните процеси на GitHub“ за сите детали.

Моралот на приказната: Никогаш не проверувајте и не градете односи со јавноста од недоверливи извори без претходно да го прегледате односите со јавноста. „Недоверливо“ овде, освен ако не е под драконска автентикација на потеклото, може да значи која било потенцијално киднапирана сметка на развивач.

 

Ненамерно распоредување на малициозен софтвер овде!

Континуирано распоредување е кулминацијата на автоматизацијата, но таа кулминација може да биде попречена од недостатокот на соодветни контроли за одобрување на pipeline проток.

Ризиците од целосно автоматизирано распоредување од изворот commit до производствените системи вклучуваат можност за распоредување на малициозен код во производствените средини без да биде откриен, како и можност грешки во процесот на распоредување да предизвикаат прекини или прекини.

За да се ублажат овие ризици, често се препорачува организациите да спроведат „силна пауза“ во нивниот процес на распоредување, што бара човечко одобрување пред изданијата да се распоредат во крајни средини.

Тие ги затвораат вратите

Мочуришен бесОние радосни стандардни лозинки во CI/CD алатките се бришат. Пристап до /var/lib/jenkins/secrets/initialAdminPassword сега е мртва патека. Многу алатки сега обезбедуваат 2FA, што Ковид го направи популарно, па дури и најмрзливиот мајмун за кодирање го користи!

M3M3N70Се бориме против 2FA, но не е толку лесно. Тешко е да се измамат тие момци, бидејќи „Scatter Swine“ направено со TwilioСо WebAuthn клучевите е многу потешко. Барем можеме да се обидеме да крадете колачиња за да го заобиколите MFA, но треба да се пробие во кутијата на развивачот.

Мултифакторската автентикација е добар чекор во вистинската насока за ограничување на ризикот од протекување на тајни за автентикација. Повеќето модерни DevOps алатки поддржуваат MFA. И клучеви за автентикација под WebAuthn / U2F (видете Проект FIDO2) се можеби најдобрата опција за MFA во DevOps, доколку се управуваат правилно.

Мочуришен бесДевОпс момците се будат. Тие го имаат проклето „најмалку привилегии“ во крвта. И веќе не се мајмуни за кодирање. Сега нè фаќаат на дело рецензентите.

Всушност, pipelineсега се малку посилни отколку пред неколку години, со отстранети слаби акции и скрипти, и со дополнителни чекори за безбедносно тестирање кои дури и ги детектираа нашите dropper-и скриени во прикрадување. commitи пакети што ги киднапиравме.

Прашање за читателот: дали процесот на градење на софтверот од извори и негово распоредување во продукција е ризичен бизнис? Можете ли да ги видите вашите DevOps во фаза на стари добри времиња за лошите момци?

Конечни препораки

Од каде да се започне CI/CD pipelines?

Првата препорака е едноставна: Внимателно преглед pipelines (тие се критична ресурси) за безбедносни прашања. Прегледите се скапи, но неопходни и треба да се направат правилно. Прегледувачите треба да бидат свесни што да разгледаат. Секој чекор мора да се провери за недостатоци.

Можеби комбинација од стручни рецензенти вооружени со автоматизирани скенери за малициозен код би можела да помогне.

Втората препорака е да се обучете програмери кои пишуваат pipelineи одржувајте ги на безбедноРаботи што треба да се земат предвид:

• Како правилно да се ракува со автентикација со внатрешни и cloud услуги, избегнувајќи ја досадата од ракување со долгорочни акредитиви.
• Како да се ограничи pipelines до точниот сет на ресурси до кои му е потребен пристап. Принципот на најмали привилегии повторно сјае.
• Како да ги напишете чекорите за правење pipelineрепродуцибилни како прикачување на верзии и избегнување на ранливости при инјектирање на команди.
• Како да се одобрат распоредувања од безбедносна перспектива (тие се други!): која безбедност standardтреба да се совпаднат и како да се додадат соодветни проверки/порти во pipelines.

Трета препорака е да се конфигурирајте го CI/CD систем со должно вниманиеСилна автентикација, без стандардни лозинки или небезбедни поставки, минимални привилегии… Внимавајте на ранливостите кај инсталираните додатоци и екстензии. Ова може да биде фокусот на следните објави, ве молиме следете нè.

Четвртата препорака е да потпора на CI/CD pipelines за безбедносна автоматизација. Анализа на изворниот код (SAST), анализа на составот на изворот (SCA), скенирањето на протекување на тајни, алатките против малициозен софтвер, скенери за безбедност на контејнери или автоматски детектори за време на извршување (DAST и малициозен софтвер) можат рутински да се извршуваат на pipeline. И вашата организација може да спроведе standardза покриеност на безбедносното скенирање во CI/CD.

Потсетете се дека овие алатки сепак не ја отстрануваат експертската рецензија од равенката, во спротивно би можеле да имате лажно чувство на сигурност.

Ако сте вешти во OWASP топ-десетките, добар неодамнешен проект е OWASP Топ 10 CI/CD Ризик за безбедност.

Забелешка за одрекување

(1) Примерите во овој пост го користат GitHub како SCM, AWS како давател на услуги во облак и GitHub Actions или Jenkins како CI/CD алатка. Тие не се послаби / побезбедни од нивните алтернативи. Нема лоша намера на медиумите! Овие алатки се моќни и треба да се користат соодветно.

(2) M3M3N70   Мочуришен бес се измислени ликови. Секоја сличност со лица или групи, живи или мртви, е само случајна… или не?

За да прочитате повеќе

• Хејмор, А. и др. „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 година.
• OWASP. „OWASP Топ 10“ CI/CD Безбедносни ризици“Јули 2022.
• Салцер Ј. и Шредер М. „Заштита на информациите во компјутерските системи“Април 1975 година. Безбедносните принципи еволуираа со технологијата, но 47 години подоцна, повеќето S&S идеи остануваат на сила.
• NCSC на Велика Британија. „Обезбедете ја изградбата и распоредувањето“ pipeline". Национален центар за сајбер безбедност на Велика Британија, февруари 2019 година.