У нашай папярэдняй публікацыі, мы ўбачылі, як выявіць і абараніцца ад прамога атручвання Pipeline Выкананне (D-PPE). Мы таксама ўбачылі, як выявіць гэтую ўразлівасць з дапамогай Сканер Xygeni, а таксама некаторыя механізмы абароны.
Атручаны Pipeline Выкананне (Сіз) ствараецца, калі зламыснік можа змяніць pipeline логіку адным з двух спосабаў:
- Змяніўшы файл канфігурацыі CI ( pipeline) -> Прамыя СІЗ (D-СІЗ)
- Змяняючы файлы, на якія спасылаецца pipeline (напрыклад: скрыпты, на якія спасылаюцца ўнутры pipeline файл канфігурацыі) -> Ускосныя СІЗ (У-СІЗ)
У гэтай публікацыі мы падрабязна разгледзім непрамы PPE. Але перад гэтым, і ў якасці дапаўнення да маёй папярэдняй публікацыі, давайце спачатку паглядзім, як GitHub кіруе выкананнем pipelineі якія механізмы абароны ад D-PEE.
Як GitHub абараняе выкананне pipelineпаходзіць ад піяраў?
Як GitHub працуе з выкананнем мадыфікаваных pipelines?
Зменены pipelineможа паходзіць ад Pushes або Pull Requests (П.С.). У якасці асноўнай перадавой практыкі настойліва рэкамендуецца пазбягаць любой прамой «адпраўкі» ў абароненую галіну і выкарыстоўваць Pull Requests як механізм для прымусовага праверкі перад прыняццем любога ўнесенага кода.
Pull Requests можа паступаць з дзвюх розных крыніц:
- PR-паведамленні паступаюць ад відэльцы
- PR-паведамленні паступаюць ад галіны
PR ад відэльцы можа паходзіць альбо з грамадскасці or прыватны сховішчы.
Паколькі мы маем справу са сродкамі індывідуальнай абароны (атручанымі Pipeline выкананне), наша галоўная думка — не «прыняцце» патрабавання да выканання запыту, а выкананне змененага pipeline падчас працэсу прыняцця/зацвярджэння адказным запытчыкам. У аснове атакі на СІЗ ляжыць ненаўмыснае выкананне «шкоднаснага» мадыфікаванага pipeline.
У некалькіх словах, атручаны Pipeline Выкананне (СІЗ) вырабляецца, калі зламыснік можа змяніць pipeline логіка.
ёсць два варыянты:
- Прамыя сродкі індывідуальнай абароны (Д-СІЗ): У сцэнарыі D-PEE, зламыснік змяняе канфігурацыйны файл CI у рэпазітарыі, да якога яны маюць доступ, альбо шляхам адпраўкі змяненняў непасрэдна ў неабароненую аддаленую галіну ў рэпазітарыі, альбо шляхам адпраўкі PR са змяненнямі з галіны або форка. З моманту стварэння CI pipeline выкананне вызначаецца камандамі ў змененым файле канфігурацыі CI, шкоднасныя каманды зламысніка ў канчатковым выніку выконваюцца ў вузле зборкі пасля завяршэння зборкі pipeline спрацоўвае.
- Ускосныя СІЗ (І-СІЗ): У некаторых выпадках магчымасць выкарыстання Д-СІЗ недаступная для праціўніка, які мае доступ да SCM сховішча (напрыклад, калі pipeline настроены на атрыманне файла канфігурацыі CI з асобнай абароненай галіны ў тым жа рэпазітарыі). У такім выпадку, замест таго, каб атруціць pipeline сам па сабе, зламыснік уводзіць шкоднасны код у файлы, на якія спасылаецца pipeline (напрыклад: скрыпты, на якія спасылаюцца ўнутры pipeline файл канфігурацыі)
У абодвух выпадках GitHub выканае зменены pipeline без неабходнасці папярэдняга агляду або адабрэння.
PR ад відэльцаў далей грамадскасці РЭПО
GitHub дазваляе наладзіць паводзіны пры апрацоўцы PR-запыты, якія паступаюць з форкаў у публічных рэпазітарах.
Калі PR-запыт паступае з форка, GitHub заўсёды патрабуе пэўнага ўзроўню «ўхвалення» перад выкананнем. pipeline звязаны з PRГэты ўзровень адабрэння змяняецца ад слабага да строгага адабрэння.
At Узровень арганізацыі (Арганізацыя >> Налады >> Дзеянні >> Агульныя), вы можаце выбраць адзін з некалькіх варыянтаў «зацвярджэння»:
Найстрогі — апошні («Патрабаваць адабрэнне ад усіх знешніх супрацоўнікаў«), таму што GitHub заўсёды будзе патрабаваць адабрэння, калі PR паступае з форкаў ад знешніх супрацоўнікаў.
Але нават у гэтым строгім выпадку ёсць адрозненні паміж суаўтарамі з правамі на чытанне і запіс.
- Калі піяр зыходзіць ад счытванне карыстальнік, той/тая/гэты выкананне ст pipeline СПЫНЕНА пакуль не будзе зацверджання змяненняў. Калі зацверджанне ў парадку, то зменены pipeline выконваецца.
- Калі піяр зыходзіць ад запіс карыстальнік, той/тая/гэты зацвярджэнне не патрабуецца, і змены pipeline заўсёды выконваецца!!
У выніку, PR-запыты, якія паступаюць з форкаў на публічных рэпазіторыях, маюць слабую абарону ад PPE. Ёсць некаторая абарона ад знешніх карыстальнікаў (чытаюць), але нічога не звязанага з унутранымі карыстальнікамі (запісваюць).
як наконт PR-запыты, якія паступаюць з форкаў прыватных рэпазітараў?
PR ад відэльцаў далей прыватны РЭПО
У гэтым выпадку GitHub прапануе некаторыя карысныя параметры канфігурацыі.
Вышэйзгаданыя параметры можна наладзіць альбо на Org або Рэпо узроўні.
Калі ніводная опцыя не адзначана, GitHub будзе прасіць адабрэння і ён не выканае зменены pipelineГэта самая бяспечная канфігурацыя!!
,en самая небяспечная канфігурацыя калі "Запускаць працоўныя працэсы з fork pull request«Праверана»У гэтым выпадку, як для карыстальнікаў з правамі чытання, так і для карыстальнікаў з правамі запісу, Github аўтаматычна выканае зменены код. pipeline!! І гэтая сітуацыя можа быць нават горш калі «Адпраўляць токены запісу ў працоўныя працэсы з fork pull requests"І"Адпраўляйце сакрэты і зменныя ў працоўныя працэсы з fork pull requests«» адзначаны. Не рабіце гэтага, калі няма выразных падстаў для гэтага!!
Калі «Патрабуецца адабрэнне для вілкі pull request рабочыя працэсы«, вышэйапісаная сітуацыя некалькі паляпшаецца: GitHub запытае адабрэнне і не выканае зменены файл pipeline для карыстальніка з правам чытання, але ён усё роўна выканае яго для карыстальніка з правам запісу.
Відэльцы бачныя, а што наконт Паведамленні аб сувязях з грамадскасцю з філіялаў?
PR ад галіны
Каб абараніць сябе ў гэтым сцэнарыі, вы павінны спадзявацца на Правілы абароны філіялаў.
На ўзроўні рэпазітара вы можаце ствараць правілы абароны галін для любой галіны. Гэтыя правілы дадаюць некаторыя абмежаванні на мадыфікацыю абароненых галін.
Нягледзячы на тое, што вы наладжваеце правіла на «Патрабаваць а pull request перад аб'яднаннем"І"Патрабаваць узгадненні», мадыфікаваны pipeline будзе аўтаматычна выканана пасля стварэння PR«Ухваленне» будзе распаўсюджвацца толькі на дзеянне аб'яднання.
А як наконт ускоснага атручвання Pipeline Execution
Як мы бачылі вышэй, D-PEE можна паменшыць, выкарыстоўваючы мэта_запыту_на_пульс, Але гэта не распаўсюджваецца на I-PEE.
Калі вы выкарыстоўваеце pull_request_target, па змаўчанні будзе праверка базавага кода. Але калі вы хочаце праверыць некаторыя праверкі ўнесенага кода (PR-кода), вам трэба відавочна праверыць PR-код. Такім чынам, калі PR-код змяніў які-небудзь скрыпт абалонкі, выкліканы pipeline, «база» (бяспечная) pipeline выкліча «мадыфікаваны» сцэнар абалонкі → Ускосны PPE!!
Рашэнне гэтай праблемы крыху больш складанае (няма чароўнай таблеткі, як pull_request_target).
Наш pipeline цяпер бяспечны для D-PPE, бо мы выкарыстоўваем pull_request_target. Але ён усё яшчэ ўразлівы для I-PPE.
У нашым тэставым прыкладзе нам трэба праверыць PR-код, каб зрабіць зборку, але тэсты выконваюцца на артэфакце, згенераваным зборкай.
Так што.. чаму б не праверыць абедзве базы кода?
- Аформіць заказ PR-кодам, бо менавіта гэты ўнёсак мы хочам стварыць і пратэставаць.
- Базавы код Checkout для запуску арыгінальнай версіі pipeline і скрыпты зборкі/тэставання
Гэта можа быць зроблена шляхам праверка гэтых кодавых баз у розных тэчкахБазавы код можна атрымаць у каранёвую тэчку, а рэкамендаваны запіс — у іншую тэчку. У гэтым выпадку мы выканаем зборку і тэставы скрыпт з каранёвай тэчкі для кода, размешчанага ў новай тэчцы.
Вядома, гэта простае рашэнне!! Але, для азнаямлення, я хацеў бы прадставіць даволі цікавы варыянт (…)
GitHub працоўны_працэс трыгерная падзея
Акрамя мэта_запыту_на_пульс, GitHub прапануе яшчэ адну трыгерную падзею: працоўны_працэсГэта мерапрыемства дазваляе выкананне pipeline прывык да іншага pipelineвыкананне.
працоўны_працэс і мэта_запыту_на_пульс Трыгеры падобныя ў адным аспекце: абодва будуць выконвацца ў прывілеяваным рэжыме і, нягледзячы на змены ў PR, база pipeline будзе выкананы!!
Давайце паглядзім на нашу цяперашнюю pipeline:
Секцыя зборкі бяспечная для D-PEE, але секцыя выпрабаванняў усё яшчэ ўразлівая для I-PEE.
,en pipeline сам па сабе бяспечны для D-PEE з-за мэта_запыту_на_пульс трыгер. Але этап тэставання ўсё яшчэ ўразлівы для I-PPE з-за выкліку знешняга сцэнарыя абалонкі.
Як пазбегнуць I-PEE
Мэта вышэйзгаданага pipeline заключаецца ў тым, каб сабраць і праверыць прадстаўлены код, бяспечны для СІЗ.
Так што.. Чаму б не падзяліць pipeline на два? Адзін для зборкі, а другі для тэставання..
- 1st pipeline (Зборка непераўзыдзенай інтэграцыі) бы праверыць PR-код (каб яго сабраць), зрабіць зборку і стварыць артэфакт.
- 2nd pipeline (Тэставы ДІ) бы праверыць базавы код (каб пазбегнуць мадыфікацыі shell-скрыптоў) і выканаць арыгінальныя скрыпты супраць артэфакта.
- Каб сінхранізаваць тэставы CI pipeline запускацца ПАСЛЯ зборкі CI pipeline, мы будзем выкарыстоўваць працоўны_працэс спускавы кручок.
Такім чынам:
- pipeline Зборка непераўзыдзенай інтэграцыі is бяспечны для абодвух Д-СІЗ (З-за мэта_запыту_на_пульс) І І-СІЗ (таму што ён больш не выконвае шэл-скрыпт).
- pipeline Тэставы ДІ Таксама бяспечны для абодвух Д-СІЗ (З-за працоўны_працэс) І І-СІЗ (таму што ён атрымлівае базавы код, каб атрымаць арыгінальны сцэнар абалонкі)
Давайце паглядзім код абодвух pipelineзгодна з гэтымі мадыфікацыямі …
1st pipeline (Зборка непераўзыдзенай інтэграцыі):
2nd pipeline (Тэставы ДІ):
Ого... выдатнае рашэнне!! Але... Ці ў бяспецы мы? Баюся, што не 😭
Сапраўды, мы дадалі новую ўразлівасць!! Якую менавіта? Гэта будзе тэмай нашай наступнай публікацыі 🙂 … Сачыце за навінамі!!
PS: Прабачце, не магу маўчаць 🤐 ..Вы чулі пра Атручванне артэфактамі ? 😂
