Бесперапынная інтэграцыя і бесперапынная дастаўка (CI/CD) pipelineз'яўляюцца асновай любой праграмнай арганізацыі, якая стварае праграмнае забеспячэнне «сучасным» спосабам. Аўтаматызацыя дае вялікія магчымасці, але большасць распрацоўшчыкаў не ўсведамляюць адказнасці, якую яна нясе.
распрацоўшчыкТак, мы бярэм CI/CD бяспеку сур'ёзна і мець моцны кантроль над тымі, хто падтрымлівае код, праглядаць commitперад зліццямі; працоўныя месцы і pipelineпадтрымліваюцца старэйшымі супрацоўнікамі, яны клапоцяцца пра тое, каб сакрэты не раскрываліся. pipelineс. І інструмент быў усталяваны персаналам, які разбіраецца ў гэтай рэчы. Што можа пайсці не так?
Паважаны распрацоўшчык, CI/CD Сістэмы складаныя. Яго шырокая паверхня для нападаў прыцягвала зламыснікаў. Лепш быць асцярожным і ніколі не быць занадта самаўпэўненым.
Часам захоўваецца канфігурацыя па змаўчанні, што становіцца найлепшым сябрам для хакераў. Крытычныя недахопы могуць прысутнічаць у CI/CD pipeline крыніцы, у канфігурацыі сістэмы або вакол працэсу і кантэксту pipeline і як гэта запускаецца.
У гэтай публікацыі мы паставім сябе на месца дрэнных акцёраў. Уявіце, што мы чытаем разважанні М3М3Н70 (Памяць пра смерць?) і Балотная лютасць недзе ў цёмным сеціве, верагодна, на не заходняй мове, але ніколі не забывайце, што зло распаўсюджваецца па ўсім свеце.
У добрыя старыя часы гэта было так проста…
М3М3Н70Калі вярнуцца ў добрыя старыя часы, наш бізнес быў настолькі простым... Zero-day былі лёгкадаступнымі, праграмы былі шырока адкрытымі з лёгкімі для выкарыстання ўразлівасцямі, і мы маглі імгненна пераключыцца на іншы бок.
Балотная лютасць: Ого! Некаторыя тут яшчэ дурныя, але ўсё змянілася. Вялікія хлопцы ўклалі шмат грошай у гэтую хрень з 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-1APP_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 у дадатку, а потым дадалі джала, бо гэтыя хлопцы, здавалася, не заўважалі. Бінга! Якая кампанія...
Злачынец проста выкарыстаў ключы 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, такія як Убудова GitHub OAuthХлопец, які яго наладжваў, выбраў абодва варыянты: «Даць правы на чытанне ўсім аўтэнтыфікаваным карыстальнікам» і «Выкарыстоўваць правы рэпазітара GitHub», што дало нам доступ да ўсіх іх праектаў.
(Прабач, Джэнкінс, што прывожу цябе ў прыклад 😉
Будзьце ўважлівымі (нават залежнымі) ад прынцыпаў бяспекі. Адзін з іх — Бяспечна па змаўчанні прынцып: элементы кіравання павінны мець максімальна бяспечныя налады па змаўчанні. Бяспека павінна быць убудавана ў CI/CD інструменты і pipelineз нуля, а не як другарадная думка. Але зручнасць і зручнасць часта супярэчаць бяспецы.
У выпадку з Джэнкінсам убудаваная аўтэнтыфікацыя занадта далікатная: ніколі не выкарыстоўвайце ўбудаваныя механізмы аўтэнтыфікацыі ў JenkinsЛепш выбраць механізм ад іншага вытворцы (SAML, LDAP, Google...) з убудовай Role-based Authorization Strategy («RBAC»). І будзьце вельмі асцярожныя з... admin кошт.
Паклапаціцеся пра тое, як працуеце і pipeline файлы ў Jenkins апрацоўваюцца. Тое ж самае з Убудова Configuration-as-Code і яго канфігурацыйныя файлы, якія прымяняюцца да канфігурацыі Jenkins.
Пераход з самастойнага хостынгу CI/CD Пераход ад воблачных SaaS-сістэм да 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 Трыгер працоўнага працэсу з відавочнай рэгістрацыяй ненадзейнага PR — небяспечная практыка, якая можа прывесці да кампраметацыі рэпазітара. У прыкладзе няўдалае спалучэнне:
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Мы змагаемся з 2FA, але гэта не так проста. Цяжка падмануць гэтых хлопцаў, бо «Scatter Swine» зрабіў з TwilioЗ ключамі WebAuthn усё значна складаней. Прынамсі, мы можам паспрабаваць красці файлы cookie, каб абыйсці шматфактарную аўтэнтыфікацыю, але трэба ўзламаць скрыню распрацоўшчыка.
Шматфактарная аўтэнтыфікацыя — гэта добры крок у правільным кірунку для абмежавання рызыкі ўцечкі сакрэтаў аўтэнтыфікацыі. Большасць сучасных інструментаў DevOps падтрымліваюць MFA. А ключы аўтэнтыфікацыі пад WebAuthn / U2F (гл. Праект FIDO2) пры правільным кіраванні, магчыма, з'яўляюцца найлепшым варыянтам для шматфактарнай аўтэнтыфікацыі ў DevOps.
Балотная лютасцьХлопцы з DevOps прачынаюцца. У іх крыві ёсць гэтая праклятая рыса «мінімальных прывілеяў». І яны больш не кодавыя малпы. Цяпер рэцэнзенты ловяць нас на гарачым.
На самай справе, pipelineЦяпер крыху больш надзейныя, чым пару гадоў таму, з выдаленымі слабымі дзеяннямі і скрыптамі, а таксама з дадатковымі этапамі тэсціравання бяспекі, якія нават выяўляюць нашы схаваныя дропперы. commitі пакеты, якія мы выкралі.
Пытанне да чытача: ці з'яўляецца працэс зборкі праграмнага забеспячэння з зыходных кодаў і разгортвання ў прадукцыйнай сферы рызыкоўным бізнесам? Ці можаце вы ўявіць сабе свой DevOps на стадыі... старыя добрыя часы для дрэнных хлопцаў?
заключныя рэкамендацыі
З чаго пачаць CI/CD pipelineз?
Першая рэкамендацыя тут простая: асцярожна агляд pipelines (яны ёсць крытычны рэсурсы) для пытанняў бяспекі. Агляды дарагія, але неабходныя, і іх трэба рабіць належным чынам. Рэцэнзенты павінны ведаць, на што звяртаць увагу. Кожны крок павінен быць правераны на наяўнасць недахопаў.
Магчыма, дапаможа камбінацыя экспертаў-аглядальнікаў, узброеных аўтаматызаванымі сканерамі шкоднаснага кода.
Другая рэкамендацыя заключаецца ў тым, каб навучаць распрацоўшчыкаў, якія пішуць pipelineі захоўваць іх у бяспецыШто варта ўлічваць:
- Як правільна апрацоўваць аўтэнтыфікацыю з дапамогай унутраных і воблачных сэрвісаў, пазбягаючы нязручнасцей, звязаных з апрацоўкай доўгатэрміновых уліковых дадзеных.
- Як абмежаваць pipelineда дакладнага набору рэсурсаў, да якіх яму патрэбны доступ. Прынцып найменшых прывілеяў зноў ззяе.
- Як напісаць крокі для стварэння pipelineузнаўляльнасць, напрыклад, замацаванне версій, і пазбяганне ўразлівасцей, звязаных з увядзеннем каманд.
- Як ухваліць разгортванне з пункту гледжання бяспекі (яны іншыя!): якая бяспека standardпавінны супадаць і як дадаць адпаведныя праверкі/вароты ў pipelines.
Трэцяя рэкамендацыя заключаецца ў тым, наладзіць CI/CD сістэма з належнай асцярожнасцюНадзейная аўтэнтыфікацыя, адсутнасць пароляў па змаўчанні або небяспечных налад, мінімальныя прывілеі… Паклапаціцеся пра ўразлівасці ў ўсталяваных плагінах і пашырэннях. Гэта можа быць тэмай наступных пастоў, калі ласка, сачыце за навінамі.
Чацвёртая рэкамендацыя заключаецца ў тым, каб выкарыстоўваць CI/CD pipelineдля аўтаматызацыі бяспекіАналіз зыходнага кода (SAST), аналіз складу крыніцы (SCA), сканаванне ўцечак сакрэтаў, антывірусныя інструменты, сканеры бяспекі кантэйнераў або аўтаматызаваныя дэтэктары часу выканання (DAST і шкоднасных праграм) могуць рэгулярна запускацца на pipelineІ ваша арганізацыя можа прымусіць standardпра асвятленне сканавання бяспекі ў CI/CD.
Нагадваем, што гэтыя інструменты не выключаюць экспертную ацэнку з ураўнення, інакш у вас можа ўзнікнуць ілжывае пачуццё бяспекі.
Калі вы добра знаёмыя з дзесяткай лепшых у OWASP, то добрым нядаўнім праектам з'яўляецца Топ-10 OWASP 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 г.
- АВАСП. «TOP 10 OWASP» CI/CD Рызыкі бяспекі"Ліпень 2022 г.
- Зальцэр Дж. і Шродэр М. «Абарона інфармацыі ў камп'ютэрных сістэмах»Красавік 1975 г. Прынцыпы бяспекі развіваліся разам з тэхналогіямі, але праз 47 гадоў большасць ідэй бяспекі і бяспекі застаюцца ў сіле.
- NCSC Вялікабрытаніі. «Забяспечце бяспеку зборкі і разгортвання» pipeline"Нацыянальны цэнтр кібербяспекі Вялікабрытаніі, люты 2019 г.
