უწყვეტი ინტეგრაცია და უწყვეტი განლაგება (CI/CD) pipelines მნიშვნელოვან როლს თამაშობენ პროგრამული უზრუნველყოფის გამარტივებული შემუშავების ხელშეწყობაში. თუმცა, როგორც ეს pipelineრაც უფრო მნიშვნელოვანი ხდება ეს საკითხები, მით უფრო აშკარა ხდება მათი დაუცველობისგან დაცვის აუცილებლობა. ეს სიღრმისეული კვლევა ფოკუსირებულია OWASP-ის ტოპ-10-ში გამოვლენილი მნიშვნელოვანი რისკის მოგვარებაზე. CI/CD უსაფრთხოების რისკები: მოწამლული Pipeline შესრულება (PPE).
რა არის მოწამლული Pipeline შესრულება (PPE)
OWASP-ის ტოპ-10-ის მიხედვით CI/CD უსაფრთხოების რისკები“,მოწამლული Pipeline შესრულების (PPE) რისკი გულისხმობს თავდამსხმელის უნარს, რომელსაც აქვს წვდომა წყაროს კონტროლის სისტემებზე - და არ აქვს წვდომა შექმნის გარემოზე - აწყობის პროცესის მანიპულირება აწყობაში მავნე კოდის/ბრძანებების ინექციით pipeline კონფიგურაციაარსებითად „მოწამვლა“ pipeline და მავნე კოდის გაშვება შექმნის პროცესის ნაწილად“
რამდენიმე სიტყვით, მოწამლული Pipeline შესრულება (PPE) ხორციელდება, როდესაც თავდამსხმელს შეუძლია შეცვალოს pipeline ლოგიკა.
არსებობს ორი ვარიანტები:
- პირდაპირი ინდივიდუალური დაცვის საშუალებები (D-PPE): D-PPE სცენარში, თავდამსხმელი ცვლის CI კონფიგურაციის ფაილს საცავში მათ აქვთ წვდომა ცვლილების პირდაპირ რეპოში დაუცველ დისტანციურ ფილიალში გადაგზავნით, ან ტოტიდან ან ფორკიდან ცვლილებასთან ერთად PR-ის გაგზავნით. CI-დან მოყოლებული pipeline შესრულება განისაზღვრება შეცვლილი CI კონფიგურაციის ფაილში არსებული ბრძანებებით, თავდამსხმელის მავნე ბრძანებები საბოლოოდ ამოქმედდება build კვანძში, როგორც კი build pipeline გააქტიურებულია.
- არაპირდაპირი ინდივიდუალური დაცვის საშუალებები (I-PPE): გარკვეულ შემთხვევებში, D-PPE-ს შესაძლებლობა არ არის ხელმისაწვდომი მოწინააღმდეგისთვის, რომელსაც აქვს წვდომა SCM საცავი (მაგ., თუ pipeline კონფიგურირებულია ისე, რომ CI კონფიგურაციის ფაილი იმავე საცავში არსებული ცალკეული, დაცული ფილიალიდან მიიღოს). ასეთ სცენარში, მოწამვლის ნაცვლად pipeline თავად თავდამსხმელი მავნე კოდს შეჰყავს ფაილებში, რომლებზეც მიუთითებს pipeline (მაგალითად: სკრიპტები, რომლებზეც მითითებულია შიგნიდან pipeline კონფიგურაციის ფაილი)
Ორივე შემთხვევაში, GitHub შეასრულებს შეცვლილ ვერსიას. pipeline წინასწარი განხილვის ან დამტკიცების გარეშე.
ინდივიდუალური დამცავი აღჭურვილობის ადრეული გამოვლენა
როგორ შეგვიძლია ამ ტიპის დაუცველობის აღმოჩენა?
ვნახოთ ეს მაგალითი pipeline :
და ფიქტიური shell სკრიპტის (runtests.sh) შინაარსი:
ის pipeline საკმაოდ მარტივია: მისი მიზანია რეცენზენტს მიაწოდოს რამდენიმე წინასწარი რჩევა Pull Request (PR) მიღების პროცესი:
- ის გააქტიურდება pull_request (ანუ, როდესაც PR იქმნება)
- ის ამოწმებს PR კოდს (ანუ შეტანილ კოდს)
- ეს აშენებას გააკეთებს
- ის გაუშვებს ტესტებს შეტანილ კოდზე (მაგ., shell სკრიპტის შესრულებით)
ნაბიჯები #3 (აწყობის შექმნა) და #4 (ტესტის გაშვება) ვერ შესრულდება, თუ კოდი არ კომპილირდება ან ვერ გაივლის ტესტებს. ამრიგად, ეს ნაბიჯები წარმოადგენს აუცილებელ, მაგრამ არასაკმარის პირობას PR-ის მისაღებად. წარმატების შემთხვევაში, რეპოს ადმინისტრატორი გადახედავს შეტანილ კოდს და ამის საფუძველზე მიიღებს/უარყოფს/კომენტარს გაუკეთებს PR-ს.
Xygeni სკანერი
ქსიგენი უზრუნველყოფს CLI-ს („Xygeni სკანერი"), რომლის ჩასმაც შესაძლებელია pipeline ან გაუშვით ბრძანების ხაზში. Xygeni სკანერი დაამუშავებს pipelines დაუცველობების შესამოწმებლად და, თუ GitHub PAT მოწოდებულია, ის დაუკავშირდება GitHub-ს org/repo დონეზე დაუცველობების აღმოსაჩენად.
Xygeni-ის ინვენტარი
როდესაც ამ საცავზე Xygeni Scanner-ს ვასრულებთ, ის აღმოაჩენს სასარგებლო აქტივების ერთობლიობას ( Xygeni-ის ინვენტარი). ინვენტარი შეივსება სხვადასხვა ტიპის CI/CD აქტივები, როგორიცაა:
- ის SCM სისტემის სად ინახება რეპო
- ის SCM plugins დამონტაჟებული/გამოყენებული
- ის კოდების საცავი თავად
- ის SCM ორგანიზაცია სადაც რეპოზიტორია
- ის CI/CD Pipelineდა სამუშაოები
- ის CI/CD სისტემის გაშვებული pipelines
- IaC რესურსები რეპოზიტორში განსაზღვრული
- გარე დამოკიდებულება
- და ა.შ ..
ჩვენს მაგალითში, ჩვენ შეგვიძლია ინვენტარის ფილტრაცია კონკრეტული აქტივის ტიპის მიხედვით (SCM- და CICD-თან დაკავშირებული აქტივები), ამიტომ ვხედავთ, რომ:
- SCM სისტემა არის GitHub Cloud
- რეპო ინახება GitHub Cloud-ში და ეკუთვნის კონკრეტულ GitHub ორგანიზაციას.
- არსებობს ორი pipelineGitHub-ის მხარდაჭერით (CI/CD სისტემა)
- ყოველ pipeline შეიცავს ერთ კონკრეტულ ნაბიჯს
ზემოთ ჩამოთვლილის არჩევით pipeline ჩვენ შეგვიძლია დავინახოთ რამდენიმე დაუცველობა:
- At pipeline დონეზე, ის დაუცველია ორივეს მიმართ პირდაპირი მდე არაპირდაპირი ინდივიდუალური დაცვის საშუალებები.
ჩვენ შეგვიძლია ვნახოთ იმ მოწამლულთა დეტალები Pipeline შესრულების დაუცველობა
Xygeni აღმოაჩენს, რომ ეს დაუცველი D-PPE-ს მიმართ რადგან ის გააქტიურებულია Pull Request ღონისძიება და არ არსებობს დამატებითი უსაფრთხოების კონტროლი, ამიტომ ნებისმიერ რეპო მომხმარებელს შეუძლია შეცვალოს იგი. pipeline და ეს ცვლილებები განხორციელდება ყოველგვარი განხილვისა და დამტკიცების გარეშე.
იმავე გაგებით, Xygeni ასევე აღმოაჩენს, რომ ეს დაუცველი I-PPE-ს მიმართ shell სკრიპტის გამოძახების გამო -დან pipelineნებისმიერ რეპო მომხმარებელს შეუძლია შელის სკრიპტის შეცვლა და ეს ცვლილებები შესრულდება ყოველგვარი განხილვის ან დამტკიცების გარეშე.
გსურთ მეტი იცოდეთ?
პირადი დამცავი აღჭურვილობის ექსპლუატაცია
ინდივიდუალური დაცვის საშუალებების გამოსაყენებლად განვიხილოთ სცენარი, სადაც არსებობს რეპო მომხმარებლების ორი ტიპი:
- An შიდა მომხმარებელი (შიდა დეველოპერი, რომელიც მუშაობს ამ საცავზე), საცავში ჩაწერის ნებართვით
- An გარე მომხმარებელი (აუთსორსირებული დეველოპერი, რომელიც მუშაობს ამ საცავზე, მაგრამ აქვს საცავზე წაკითხვის ნებართვა), ანუ არ აქვს საცავი განშტოების უფლება და იძულებულია იმუშაოს ფორკზე.
წარმოვიდგინოთ, რომ ორივე ბოროტი თავდამსხმელია (ან ბოროტი აქტორის მიერ არის გაყალბებული). საცავი შეიცავს გარკვეულ საიდუმლოს და ორივეს სურს საცავის საიდუმლოს მოსაპარად და ჰაკერების მიერ კონტროლირებად სერვერზე გააგზავნიან. ამისათვის ისინი მოწამლული Pipeline შესრულების დაუცველობა pipeline.
ორივე შემთხვევაში (გარე და შიდა მომხმარებელი), ისინი ხსნიან Pull Request იგივე ცვლილებებით:
- ის pipeline და shell სკრიპტი შეცვლილია to წაიკითხეთ საიდუმლო გარემოდან და გაგზავნეთ ის ჰაკერების მიერ კონტროლირებად სერვერზე
ცვლილებები შეიძლება იყოს შემდეგი:
ორივე მომხმარებელი შექმნის Pull Request მოდიფიკაციებთან ერთადPR-ის შექმნისთანავე, GitHub შეასრულებს ორივე მოდიფიკაციას (წინასწარი განხილვის ან დამტკიცების გარეშე), რის შედეგადაც შემდეგი:
იგივეა წერისა და წაკითხვის მომხმარებლებისთვის, ორივე შემთხვევაში, D-PPE და I-PPE ხორციელდება., იმ განსხვავებით, რომ წაკითხულ მომხმარებელს არ შეუძლია საიდუმლოებებზე წვდომა. (!!!!)
ეს მიზეზი იმიტომ არის, რომ, ფორკიდან მოსული PR-ის შემთხვევაში, GitHub არ იძლევა საცავის საიდუმლოებებზე წვდომის საშუალებას. მიუხედავად იმისა, რომ წაკითხულ მომხმარებელს არ შეუძლია საიდუმლოებების წაკითხვა, მას მაინც შეუძლია ნებისმიერი სხვა პროგრამის გაშვება. შეტევის ტიპიური მაგალითია PR-ების შექმნა, რომლებიც კრიპტო მაინერს ჩამოტვირთავენ, ამიტომ GitHub-ის შემსრულებელი გაუშვებს კრიპტო მაინერს მოწამლული პროგრამის შესრულებისას. pipeline.
ეს, რა თქმა უნდა, უსაფრთხო გარემო არ არის!! რა შეიძლება გააკეთოს რეპოს ადმინისტრატორმა ამის თავიდან ასაცილებლად?
Google-ში რამდენიმე ძებნის შემდეგ, რეპოს ადმინისტრატორმა გადაწყვიტა შეცვალოს pipeline გააქტიურდეს pull_request_target მოვლენა. რატომ? იმიტომ, რომ pipelinepull_request_target-ზე გააქტიურებული s არ იძლევა შესრულების საშუალებას. pipeline მოდიფიკაციების, ანუ მომხმარებლის ნებისმიერი ცვლილების მიუხედავად, „ორიგინალი“ pipeline აღსრულდება.
ჩვენი მაგალითის შემდეგ, შეტევა იგივე იქნება, რაც ადრე. რა მოხდება ამის შემდეგ? pipeline მოდიფიკაცია?
როგორც მოსალოდნელი იყო, D-PPE არ არის შესრულებული მაგრამ, რადგან I-PPE ჯერ კიდევ არსებობს, წაკითხულ მომხმარებელს ახლა შეუძლია წვდომა საცავის საიდუმლოებაზე!!!
რა არის მიზეზი, რის გამოც წაკითხულ მომხმარებელს ახლა აქვს წვდომა საიდუმლოებებზე? მიუხედავად იმისა, რომ pipeline მისი შეცვლა შეუძლებელია, shell სკრიპტის შეცვლა მაინც შესაძლებელია. როდესაც pipeline გააქტიურდება pull_request_target-ზე, ის შესრულდება პრივილეგირებულ რეჟიმში. so ეს ასევე იქნება shell სკრიპტი, რის შედეგადაც shell სკრიპტს აქვს წვდომა საცავის საიდუმლოებებზე!!
პრევენციული ზომები
GitHub გთავაზობთ გარკვეულ ზომებს მავნე PR-ებისგან დასაცავად.
ფილიალის დაცვის წესები
GitHub-ის საშუალებით შეგიძლიათ განსაზღვროთ ფილიალების დაცვის წესები არჩეულ ფილიალებზე.
თქვენი დაცული ფილიალებისთვის შეგიძლიათ მიუთითოთ პოლიტიკა, რომელიც მოითხოვს ა pull request შერწყმამდე (ასევე დამატებითი პირობები, როგორიცაა დამტკიცებების საჭირო რაოდენობა, კოდის მფლობელების მიმოხილვები და ა.შ.)
განსაკუთრებული ყურადღების ღირსია რამდენიმე პირობა:
- "მითითებულ მსახიობებს მიეცით უფლება, გვერდი აუარონ საჭირო მოქმედებებს pull requests".
- "არ დაუშვათ ზემოთ მოცემული პარამეტრების გვერდის ავლა"
მიუხედავად იმისა, რომ პირობების უმეტესობა პოლიტიკას ამკაცრებს, ეს პირობები მას ამსუბუქებს და შესაძლოა, მავნე საქმიანობისთვის ღია კარი გაუხსნას, მაგალითად, იმ შემთხვევაში, თუ „პრივილეგირებული“ აქტორები პირადობის დამადასტურებელ მონაცემებს მოიპარავენ.
GITHUB_TOKEN-ის ნებართვების შეზღუდვა (ყველაზე მცირე პრივილეგია)
შეზღუდეთ GitHub-ის ტოკენის ნებართვები მხოლოდ საჭირო ნებართვებით; ამ გზით, მაშინაც კი, თუ თავდამსხმელები შეძლებენ თქვენი უფლებების კომპრომეტირებას. pipeline, ისინი ბევრს ვერაფერს შეძლებენ.
სტრიქონის ინტერპოლაციის თავიდან აცილება შესაძლებელია შემდეგი მეთოდის გამოყენებით: pipeline env ცვლადები
როდესაც თქვენს სისტემაში იყენებთ შეყვანის ცვლადებს pipelineგაითვალისწინეთ, რომ ისინი ნაგულისხმევად უნდა ჩაითვალოს „არასანდო“ მონაცემებად (მათ შინაარსს საბოლოო მომხმარებელი აკონტროლებს). იხილეთ არასანდო მოქმედებები და სამუშაო პროცესები უსაფრთხოა მდე ისწავლეთ Github-ის მოქმედებები.
სკრიპტებში შეყვანის ცვლადების ჩასასმელად ყოველთვის უნდა გამოიყენოთ გარემოს ცვლადები, სტრიქონების ინტერპოლაციის ნაცვლად.
სამუშაო პროცესის გაშვება და დამტკიცების მოთხოვნები
იყიდება საჯარო რეპოები, GitHub საშუალებას იძლევა მიუთითოთ როგორ ვიმუშაოთ „გარე“ PR-ებთან.
GitHub-ის ორგანიზაციის პარამეტრები („Org >> პარამეტრები >> მოქმედებები >> ზოგადი“) საშუალებას გაძლევთ მიუთითოთ, თუ როგორ უნდა მართოთ გარე PR-ები:
ნაგულისხმევად, GitHub პირველად შემომტანი პირებისთვის PR დამტკიცებას მოითხოვს, რაც მავნე მოთხოვნის შეტევებს უფრო ართულებს. მიუხედავად ამისა, თავდამსხმელმა შეიძლება პროექტის შემნახველების ნდობა მოიპოვოს, მაგალითად, რაიმე უდანაშაულო წვლილის შეტანით. pull request ნამდვილ შეტევამდე.
ამ თვალსაზრისით, მესამე ვარიანტი (ყველა გარე კოლაბორატორისთვის თანხმობის მოთხოვნა) კონტროლის უფრო მაღალ დონეს ამატებს.
იყიდება კერძო რეპოებთან დაკავშირებით, GitHub ასევე უზრუნველყოფს სასარგებლო კონტროლს როგორც ორგანიზაციის, ასევე რეპოს დონეზე.
"სამუშაო პროცესების გაშვება Pull Requests” (ნაგულისხმევად არ არის მონიშნული) საშუალებას აძლევს მომხმარებლებს გაუშვან სამუშაო პროცესები ჩანგლის PR-ებიდან (GITHUB_TOKEN-ის გამოყენებით მხოლოდ წაკითხვის ნებართვით და საიდუმლოებებზე წვდომის გარეშე). ამ პარამეტრის ბოლო ვარიანტთან ერთად არჩევით (“დამტკიცების მოთხოვნა ჩანგლის PR-ების სამუშაო პროცესებისთვის"), შეგიძლიათ მიაღწიოთ კერძო საცავების მსგავს პოლიტიკას (როგორც ზემოთ არის ნაჩვენები).
როგორც ვნახეთ წაკითხული მომხმარებლისგან PPE ექსპლოიტში, სამუშაო პროცესების ჩანგლიდან გაშვების დაშვება pull requests უსაფრთხო არ არის!!
დარჩენილი ვარიანტები („ჩაწერის ტოკენების გაგზავნა სამუშაო პროცესებზე ჩანგლიდან pull requests"და"საიდუმლოებებისა და ცვლადების გაგზავნა სამუშაო პროცესებისთვის for-დან pull requests") შეამცირეთ უსაფრთხოების დონე გამოყენებულია ფორკის PR-ებზე.
ამ განშტოების პოლიტიკის განსაზღვრა შეგიძლიათ როგორც ორგანიზაციის დონეზე, ასევე საცავის დონეზე. თუ პოლიტიკა გამორთულია ორგანიზაციის დონეზე, მისი ჩართვა საცავის დონეზე შეუძლებელია. თუმცა, თუ პოლიტიკა ჩართულია ორგანიზაციის დონეზე, მისი გამორთვა შესაძლებელია საცავის დონეზე.
Recap
ვიმედოვნებთ, რომ ნახეთ ზოგიერთის ქონის შედეგები pipeline მოწამვლის მიმართ დაუცველი Pipeline შესრულება. ეს ძალიან ადვილია commit დაუცველი pipelineდა უსაფრთხოს დაწერა რთულია.
ამიტომ, ასეთი დაუცველობების შესახებ ინფორმირებისთვის, Xygeni სკანერის გამოყენება ძალიან ღირებულია.
დაუცველობის პრობლემის მოგვარება შეუძლებელია, თუ მისი არსებობის შესახებ არ იცით!!
მაგრამ... კვლავ რჩება ერთი გადაუჭრელი კითხვა... როგორ ავიცილოთ თავიდან I-PPE?
ეს ჩვენი შემდეგი პოსტის თემა იქნება 🙂 … არაპირდაპირი მოწამვლა Pipeline შესრულება (I-PPE) !!
