შესავალი
Orca Security-მ ცოტა ხნის წინ Google Cloud Build სერვისში აღმოაჩინა დიზაინის ხარვეზი, სახელწოდებით „Bad.Build“. ეს ხარვეზი სერიოზულ საფრთხეს უქმნის თავდამსხმელებს, რადგან ის საშუალებას აძლევს მათ განახორციელონ Privilege Escalation, რაც მათ არაავტორიზებული შეღწევის საშუალებას აძლევს Google-ის Artifact Registry-ის კოდის საცავებში.
ამ დაუცველობის შედეგები ვრცელდება პროგრამული უზრუნველყოფის მიწოდების ჯაჭვზე, რადგან თავდამსხმელებს შეუძლიათ მისი გამოყენება აპლიკაციის სურათების მავნე განზრახვით მანიპულირებისთვის. შესაბამისად, არაფრისმომცდარი მომხმარებლები და მომხმარებლები, რომლებიც აინსტალირებენ გაფუჭებულ აპლიკაციებს, შეიძლება ინფექციების მსხვერპლი გახდნენ.
ეს სიტუაცია გვახსენებს წარსულში მიწოდების ჯაჭვზე, მაგალითად SolarWinds-ზე, განხორციელებული შეტევების მნიშვნელოვან გავლენას. 3CXდა MOVEit, ხაზს უსვამს უსაფრთხოების ასეთი ხარვეზების შორსმიმავალ შედეგებს.
როგორ მუშაობს?
Google Cloud Build წარმოადგენს უწყვეტ ინტეგრაციას/უწყვეტ მიწოდებას (CI/CD) სერვისი, რომელიც შემოთავაზებულია Google Cloud ეკოსისტემის ფარგლებში. ის სასიცოცხლო როლს ასრულებს ღრუბელზე დაფუძნებულ აპლიკაციებში, რადგან შეუფერხებლად ურთიერთქმედებს სხვა აუცილებელ სერვისებთან, როგორიცაა Artifact Registry და App Engine.
არსებული ხარვეზი გამოწვეულია გადაჭარბებული პრივილეგიებით. კერძოდ, „logging.privateLogEntries.list„მოქმედება უნებლიედ იძლევა აუდიტის ჟურნალების ჩამონათვალს გაუთვალისწინებელ როლში, კერძოდ, „როლები/cloudbuild.builds.builder".
სამწუხაროდ, ეს ნაგულისხმევი როლი მინიჭებულია ღრუბლოვანი შექმნის სერვისის ანგარიშს. ეს სიტუაცია სერიოზულ რისკს წარმოადგენს, რადგან აუდიტის ჟურნალები შეიცავს მგრძნობიარე ინფორმაციას, რომელიც ავლენს პროექტთან დაკავშირებულ ყველა ნებართვას. ეს გაუთვალისწინებელი წვდომა თავდამსხმელებს აძლევს შესაძლებლობას, გააყალბონ ღრუბლოვანი შექმნის ანგარიში, რითაც მიიღებენ ინფორმაციას იმის შესახებ, თუ რომელი მოქმედებების შესრულება შეუძლია სხვადასხვა Google ანგარიშს. შესაბამისად, ეს ხსნის კარს გვერდითი გადაადგილებისა და პრივილეგიების ესკალაციისთვის, რაც წარმოადგენს უკიდურესად საშიშ უსაფრთხოების დაუცველობას.
build სერვისის ანგარიშის იმიტაცია მხოლოდ შემდეგს მოითხოვს: cloudbuild.builds.create ნებართვა, რომელიც ბევრ წინასწარ განსაზღვრულ როლს აქვს და რომელიც დეველოპერებს ენიჭებათ ნებისმიერი გონივრული ფორმით CI/CD გარემო Cloud Build-ის გამოყენებით. ასე რომ, თუ თქვენ გაქვთ წვდომა ერთ-ერთი ასეთი დეველოპერის ანგარიშზე, მორგებული კონფიგურაციის ფაილის შექმნა რეალურად გაუშვებს gcloud-ის ჟურნალირების წაკითხვის ბრძანება, რომელიც ჩამოთვლის ნებართვებს.
მაგრამ პრობლემა აქ არ მთავრდება: Google Cloud Build სერვისის ანგარიში მაღალი პრივილეგიებით სარგებლობს, Goggle-ის არტეფაქტების რეესტრთან ურთიერთქმედების მრავალი მოქმედებით.
ნაგულისხმევი Cloud Build სერვისის ანგარიშის გაყალბების საშუალებას მისცემს დაუცველობის გამოყენებით, მავნე აქტორები იძენენ Google-ის არტეფაქტების რეესტრში შენახული სურათების გაყალბების შესაძლებლობას მავნე კოდის ინექციით. შესაბამისად, ამ კომპრომეტირებული სურათებიდან შექმნილი ნებისმიერი აპლიკაცია პოტენციური შედეგებისადმი მგრძნობიარე ხდება, მათ შორის მომსახურების უარყოფის (DoS) შეტევების, მონაცემთა ქურდობისა და მავნე პროგრამების გავრცელების.
სიტუაციის სიმძიმე იზრდება, როდესაც ეს მანიპულირებული აპლიკაციები განკუთვნილია მომხმარებლის გარემოში განსათავსებლად, იქნება ეს on-premise ან ნახევრად SaaS. ეს რისკს მიმწოდებელი ორგანიზაციის ინფრასტრუქტურის მიღმა აფართოებს, რაც იწვევს მიწოდების ჯაჭვის შეტევას, რომელიც აღწევს და საფრთხეს უქმნის მომხმარებლის გარემოს. ასეთი შეტევები მსგავსია პროგრამული უზრუნველყოფის მიწოდების ჯაჭვის დარღვევების ადრე დაფიქსირებული ინციდენტებისა, როგორიცაა SolarWinds-ის დარღვევა. ასეთი შეტევის შედეგები შეიძლება იყოს მძიმე, გამოიწვიოს ფართომასშტაბიანი ზიანი და გავლენა მოახდინოს მიწოდების ჯაჭვის ფარგლებში არსებულ მრავალ ორგანიზაციაზე.
მსგავსი პრივილეგიის ესკალაციის PoC მოხდა Rhino Security Labs, რომელიც სხვაგვარად იყენებდა ნაგულისხმევი Cloud Build ანგარიშის ზედმეტ პრივილეგიებს.
რატომ არის საშიში?
ამ დაუცველობის სიმძიმე მდგომარეობს თავდამსხმელების მიერ არტეფაქტების რეესტრის გამოყენებისა და არტეფაქტებში მავნე კოდის შეყვანის პოტენციალში. შედეგად, ამ კომპრომეტირებული სურათებიდან შექმნილი ნებისმიერი აპლიკაცია მგრძნობიარე ხდება სხვადასხვა უარყოფითი ეფექტის მიმართ.
ეს ეფექტები მოიცავს მომსახურების უარყოფის შეტევების, მონაცემთა ქურდობის და მავნე პროგრამების გავრცელების შესაძლებლობას. უფრო მეტიც, თუ ეს კომპრომეტირებული აპლიკაციები შემდგომში განთავსდება on-premise ან ნახევრად SaaS გარემოში, რისკი ვრცელდება მსხვერპლი ორგანიზაციის ფარგლებს გარეთ და გავლენას ახდენს მათ მომხმარებლებზეც. ეს სცენარი ჰგავს SolarWinds-ის ინციდენტის დროს დაფიქსირებულ მიწოდების ჯაჭვის შეტევას, რაც ხაზს უსვამს როგორც ორგანიზაციისთვის, ასევე მისი მომხმარებლებისთვის პოტენციურ შედეგებს.
-
Xygeni-ის რეკომენდაცია
გამოიყენეთ მინიმალური პრივილეგიის პრინციპი
- ქსიგენის სენსორი აკონტროლებს მომხმარებლის ქმედებებს იმ სისტემებში, სადაც ის არის განთავსებული და უზიარებს მათ ჩვენს ძირითად პლატფორმას, რომელიც ადგენს უჩვეულო ქცევას ან ნორმალური ნიმუშებიდან გადახრებს, როგორიცაა უჩვეულო login დრო ან ადგილმდებარეობა, დიდი რაოდენობით მონაცემთა გადაცემა ან მომხმარებლის წვდომის უფლებების ცვლილებები, რომლებიც მოდელირებული „ნორმალური“ მომხმარებლის ქცევის დიაპაზონს სცილდება.
Xygeni-ის პოლიტიკა და აუდიტი ითვალისწინებს წვდომის კონტროლის, მრავალფაქტორიანი ავტორიზაციის მოთხოვნების და როლებზე დაფუძნებული ნებართვების აპლიკაციების საუკეთესო პრაქტიკას, რათა შეზღუდოს მომხმარებლის წვდომა კრიტიკულ სისტემებსა და მონაცემებზე.
ეს ინსტრუმენტები აკონტროლებენ მომხმარებლის ქმედებებს, როგორიცაა კოდის ცვლილებები, სისტემაზე წვდომა ან მონაცემთა გადაცემა და ადარებენ მათ წინასწარ განსაზღვრულ პოლიტიკასა და ქცევით ნიმუშებს. ისინი ასევე აღნიშნავენ საეჭვო აქტივობებს, როგორიცაა არაავტორიზებული წვდომა, გადაჭარბებული პრივილეგიები ან მონაცემთა გადაცემის უჩვეულო ნიმუშები..
როგორ მოგვარდა დაუცველობა
დაუცველობის შესახებ Google-ის უსაფრთხოების გუნდისთვის შეტყობინების შემდეგ, მათ მიიღეს ზომები და გააუქმეს logging.privateLogEntries.list ნებართვა ნაგულისხმევი Cloud Build სერვისის ანგარიშიდან. მათ აღიარეს, რომ მიუხედავად იმისა, რომ setIamPolicy აუდიტის ჟურნალები მნიშვნელოვანია აუდიტის მიზნებისთვის, ამ ჟურნალებზე წვდომის მინიჭება ღრუბლოვანი build სერვისის ანგარიშის პერსპექტივიდან არ იყო საჭირო.
თუმცა, უმნიშვნელოვანესია გვესმოდეს, რომ ეს პასუხი პირდაპირ არ ეხებოდა არტეფაქტების რეესტრის root დაუცველობას. შედეგად, პრივილეგიების ესკალაციის ვექტორი და მიწოდების ჯაჭვის შეტევის პოტენციური რისკი უცვლელი დარჩა. არსებითად, Google-ის მიერ შემუშავებულმა გამოსწორებამ შეზღუდა პრობლემა, მაგრამ მთლიანად არ აღმოფხვრა იგი, რის გამოც ორგანიზაციები კვლავ დაუცველები რჩებოდნენ პროგრამული უზრუნველყოფის მიწოდების ჯაჭვის მნიშვნელოვანი რისკების წინაშე.
სიტუაციის საპასუხოდ, Google-მა თავის მომხმარებლებს ურჩია, შეეცვალათ ნაგულისხმევი Cloud Build Service ანგარიშის ნებართვები ნებისმიერი უფლებამოსილების დამადასტურებელი დოკუმენტის ამოღებით, რომელიც გადახრილი იყო მინიმალური პრივილეგიის პრინციპიდან (PoLP). ეს ღონისძიება მიზნად ისახავს უსაფრთხოების გაძლიერებას იმის უზრუნველყოფით, რომ ანგარიშებს ჰქონდეთ მხოლოდ მინიმალური საჭირო პრივილეგიები მათი დავალებების შესასრულებლად.
ამ პრივილეგიების ესკალაციის შეტევისგან თავის დასაცავად, აუცილებელია Cloud Build Service ანგარიშზე მინიჭებული ნებართვების შეზღუდვა და სიფრთხილის გამოჩენა. cloudbuild.builds.create ნებართვა თქვენი ორგანიზაციის ნებისმიერი მომხმარებლისთვის. რაც მთავარია, თქვენ უნდა იცოდეთ, რომ ნებისმიერ მომხმარებელს, რომელსაც მინიჭებული აქვს cloudbuild.builds.create, ასევე ირიბად მინიჭებული აქვს Cloud Build Service Account-ისთვის მინიჭებული ყველა ნებართვა. თუ ეს თქვენთვის მისაღებია, მაშინ შეიძლება არ დაგჭირდეთ ამ შეტევის ვექტორზე ფიქრი, მაგრამ მაინც მკაცრად რეკომენდებულია Cloud Build Service Account-ისთვის მინიჭებული ნაგულისხმევი ნებართვების შეცვლა.
Google მოკლედ გირჩევთ ამას, მაგრამ დამატებით დეტალებს არ გვაწვდის:
„თუ არ გეგმავთ რაიმე ქმედების შესრულებას შექმნის პროცესის ფარგლებში, გირჩევთ, გააუქმოთ შესაბამისი ნებართვა Cloud Build სერვისის ანგარიშიდან, რათა დაიცვათ მინიმალური პრივილეგიის უსაფრთხოების პრინციპი.“
Timeline
Rhino Security Labs-მა გამოაქვეყნა პოსტი პრივილეგიების ესკალაციის პრობლემის შესახებ და შექმნა მისთვის PoC python სკრიპტი *.
Orca Security-მ თავისი დასკვნები Google-ის უსაფრთხოების გუნდს აცნობა.
Google-მა ჩაატარა გამოძიება და საპასუხოდ ნაწილობრივი შესწორება დანერგა.
თუმცა, მნიშვნელოვანია აღინიშნოს, რომ Google-ის მიერ მიღებულმა გამოსავალმა სრულად არ აღმოფხვრა აღმოჩენილი პრივილეგიების ესკალაციის (PE) ვექტორი. სამაგიეროდ, მან შეზღუდა მისი გავლენა, რამაც ის ფაქტობრივად დიზაინის ხარვეზად აქცია, რომელიც ორგანიზაციებს კვლავ აყენებს მიწოდების ჯაჭვზე თავდასხმის უფრო ფართო რისკის წინაშე. შესაბამისად, უსაფრთხოების ჯგუფებისთვის აუცილებელია დამატებითი ზომების მიღება ამ არსებული რისკისგან თავის დასაცავად.
დასკვნა
მოწინააღმდეგეებმა შეიძლება გამოიყენონ Google Cloud Build-ის ნაგულისხმევი ანგარიშისთვის მინიჭებული ზედმეტი პრივილეგიები შეტევის განსახორციელებლად დეველოპერის ანგარიშის გამოყენებით, რომელიც საშუალებას იძლევა შეიქმნას ღრუბლოვანი ბილდი. თავდამსხმელებმა შეიძლება მოიპარონ კონტეინერის სურათი, დააზიანონ იგი მავნე ქცევით და შემდეგ გადაიტანონ ის არტეფაქტების რეესტრში, პროგრამული უზრუნველყოფის მიწოდების ჯაჭვის შეტევის შედეგად, რამაც შეიძლება დამანგრეველი შედეგები გამოიწვიოს.
Google-ის პასუხი შერბილების სამუშაოს Cloud Build სერვისის გამოყენებით ორგანიზაციებს ანდობს, რომლებსაც რისკის კონტროლის პრივილეგიების გაუქმება სჭირდებათ. შესაძლებელია მომავალში Google-ს დამატებითი დახმარების თხოვნა უსაფრთხოების საკითხების მოგვარებაში. CI/CD სისტემა.
ლიტერატურა
- დანიშნულებით მუშაობს: RCE-დან IAM-მდე პრივილეგიების ესკალაცია GCP Cloud Build-ში. რინო უსაფრთხოების ლაბორატორიები.
- Bad.Build: PE და RCE დაუცველობები Google Cloud Build-შიორკას უსაფრთხოება.
- უსაფრთხოების ბიულეტენიGoogle Cloud.
მეტი ინფორმაციის მისაღებად Xygeni პლატფორმის შესახებ, ჩამოტვირთეთ Xygeni-ის პლატფორმის მონაცემთა ცხრილი
