Wprowadzenie
Firma Orca Security niedawno zidentyfikowała lukę w projekcie usługi Google Cloud Build o nazwie „Bad.Build”. Luka ta stanowi poważne zagrożenie bezpieczeństwa, ponieważ umożliwia atakującym wykonanie eskalacji uprawnień, co daje im nieautoryzowany dostęp do repozytoriów kodu w Rejestrze artefaktów Google.
Konsekwencje tej luki w zabezpieczeniach rozciągają się na łańcuch dostaw oprogramowania, ponieważ atakujący mogą ją wykorzystać do manipulowania obrazami aplikacji w złośliwych celach. W rezultacie niczego niepodejrzewający użytkownicy i klienci, którzy zainstalują zmodyfikowane aplikacje, mogą paść ofiarą infekcji.
Sytuacja ta przypomina nam o znaczącym wpływie, jaki zaobserwowano w przeszłości w przypadku ataków na łańcuchy dostaw, takich jak SolarWinds, 3CX, Rusz to, podkreślając dalekosiężne konsekwencje takich zaniedbań w zakresie bezpieczeństwa.
Jak to działa?
Google Tworzenie chmury oznacza ciągłą integrację/ciągłe dostarczanie (CI/CD) usługa oferowana w ekosystemie Google Cloud. Odgrywa ona kluczową rolę w aplikacjach chmurowych, płynnie współpracując z innymi niezbędnymi usługami, takimi jak Artifact Registry i App Engine.
Omawiana wada wynika z problemu z nadmiernymi uprawnieniami. Dokładniej, „rejestrowanie.prywatnewpisydziennika.lista„Działanie to nieumyślnie pozwala na przypisanie dziennikom audytu niezamierzonej roli, mianowicie „role/cloudbuild.builds.builder".
Niestety, ta domyślna rola jest przypisana do konta usługi Cloud Build. Sytuacja ta stwarza poważne ryzyko, ponieważ logi audytu zawierają poufne informacje, ujawniające wszystkie uprawnienia powiązane z projektem. Ten niezamierzony dostęp umożliwia atakującym podszywanie się pod konto Cloud Build, a tym samym zdobywanie wiedzy o tym, jakie działania mogą być wykonywane przez różne konta Google. W konsekwencji otwiera to drogę do przemieszczania się w poziomie uprawnień i eskalacji uprawnień, co stanowi niezwykle niebezpieczną lukę w zabezpieczeniach.
Podszywanie się pod konto usługi kompilacji wymaga jedynie cloudbuild.builds.create uprawnienia, które posiada wiele predefiniowanych ról i które są przyznawane programistom w każdym rozsądnym przypadku CI/CD środowisko za pomocą Cloud Build. Jeśli więc masz dostęp do takiego konta deweloperskiego, utworzenie dostosowanego pliku konfiguracji kompilacji spowoduje faktyczne uruchomienie polecenie odczytu rejestrowania gcloud, który wyświetli listę uprawnień.
Ale problem na tym się nie kończy: Konto usługi Google Cloud Build ma wysokie uprawnienia, z wieloma akcjami umożliwiającymi interakcję z Rejestrem artefaktów Goggle.
Wykorzystując lukę umożliwiającą podszywanie się pod domyślne konto usługi Cloud Build, cyberprzestępcy zyskują możliwość manipulowania obrazami przechowywanymi w Rejestrze Artefaktów Google poprzez wstrzyknięcie złośliwego kodu. W rezultacie wszelkie aplikacje zbudowane na podstawie tych zainfekowanych obrazów stają się podatne na potencjalne konsekwencje, w tym ataki typu DoS (Denial-of-Service), kradzież danych i rozprzestrzenianie się złośliwego oprogramowania.
Powaga sytuacji wzrasta, gdy te zmanipulowane aplikacje są przeznaczone do wdrożenia w środowiskach klientów, niezależnie od tego, czy on-premise lub pół-SaaS. To rozszerza ryzyko poza infrastrukturę organizacji dostarczającej, prowadząc do ataku na łańcuch dostaw, który infiltruje i kompromituje środowiska klientów. Takie ataki są podobne do wcześniejszych incydentów obserwowanych w przypadku naruszeń łańcucha dostaw oprogramowania, takich jak naruszenie SolarWinds. Konsekwencje takiego ataku mogą być poważne, powodując rozległe szkody i wpływając na wiele organizacji w łańcuchu dostaw.
Podobna eskalacja uprawnień miała miejsce w PoC Laboratoria Bezpieczeństwa Rhino, który w inny sposób wykorzystał nadmierne uprawnienia domyślnego konta Cloud Build.
Dlaczego jest to niebezpieczne?
Powaga tej luki polega na tym, że umożliwia ona atakującym wykorzystanie Rejestru Artefaktów i wprowadzenie złośliwego kodu do artefaktów. W rezultacie wszelkie aplikacje zbudowane na podstawie tych zainfekowanych obrazów stają się podatne na szereg negatywnych skutków.
Do skutków tych należą m.in. możliwość ataków typu „odmowa usługi”, kradzież danych i rozprzestrzenianie się złośliwego oprogramowania. Co więcej, jeśli te zainfekowane aplikacje zostaną następnie wdrożone on-premise lub w środowisku semi-SaaS ryzyko wykracza poza organizację ofiary, wpływając również na jej klientów. Ten scenariusz przypomina atak na łańcuch dostaw, który miał miejsce w przypadku incydentu SolarWinds, podkreślając potencjalne konsekwencje zarówno dla organizacji, jak i jej klientów.
Zalecenie Xygeni
Zastosuj zasadę najmniejszych przywilejów
- Czujnik Xygeni monitoruje działania użytkowników w systemach, w których jest wdrożony, i udostępnia je naszej platformie głównej, która identyfikuje nietypowe zachowania lub odchylenia od normalnych wzorców, takie jak nietypowe login czasu lub lokalizacji, dużych transferów danych lub zmian w uprawnieniach dostępu użytkowników, które wykraczają poza zakres modelowanego „normalnego” zachowania użytkownika.
Zasady i audyt firmy Xygeni egzekwują najlepsze praktyki w zakresie kontroli dostępu, wymagań uwierzytelniania wieloskładnikowego i aplikacji uprawnień opartych na rolach, aby ograniczyć dostęp użytkowników do kluczowych systemów i danych.
Narzędzia te monitorują działania użytkowników, takie jak zmiany kodu, dostęp do systemu lub transfery danych, i porównują je ze zdefiniowanymi wcześniej zasadami i wzorcami zachowań. Sygnalizują również podejrzane działania, takie jak nieautoryzowany dostęp, nadmierne uprawnienia lub nietypowe wzorce przesyłania danych.
Jak poradzono sobie z luką w zabezpieczeniach
Po powiadomieniu zespołu ds. bezpieczeństwa Google o luce w zabezpieczeniach, podjęto działania, odbierając uprawnienie logging.privateLogEntries.list domyślnemu kontu usługi Cloud Build. Przyznano, że chociaż logi audytu setIamPolicy są istotne dla celów audytu, udzielanie dostępu do nich z perspektywy konta usługi Cloud Build było zbędne.
Należy jednak pamiętać, że ta odpowiedź nie dotyczyła bezpośrednio głównej luki w zabezpieczeniach Rejestru Artefaktów. W rezultacie wektor eskalacji uprawnień i potencjalne ryzyko ataku na łańcuch dostaw pozostały niezmienione. Zasadniczo poprawka Google ograniczyła problem, ale nie wyeliminowała go całkowicie, pozostawiając organizacje nadal narażone na znaczne ryzyko związane z łańcuchem dostaw oprogramowania.
W odpowiedzi na tę sytuację Google zaleciło swoim klientom modyfikację uprawnień domyślnego konta usługi Cloud Build poprzez usunięcie wszelkich danych uwierzytelniających, które odbiegały od zasady najmniejszych uprawnień (PoLP). Ten środek ma na celu zwiększenie bezpieczeństwa poprzez zapewnienie, że konta mają jedynie minimalne uprawnienia niezbędne do wykonywania przypisanych im zadań.
Aby bronić się przed atakiem polegającym na eskalacji uprawnień, konieczne jest ograniczenie uprawnień przyznanych kontu usługi Cloud Build Service i zachowanie ostrożności przy udzielaniu uprawnień. cloudbuild.builds.create uprawnienia wszystkim użytkownikom w Twojej organizacji. Co najważniejsze, musisz wiedzieć, że każdy użytkownik, któremu przyznano uprawnienia, cloudbuild.builds.create, otrzymuje również pośrednio wszystkie uprawnienia przyznane kontu usługi Cloud Build Service. Jeśli Ci to odpowiada, możesz nie martwić się tym wektorem ataku, ale nadal zdecydowanie zaleca się modyfikację domyślnych uprawnień przyznanych kontu usługi Cloud Build Service.
Google zaleca to zwięźle, ale nie podaje dalszych szczegółów:
„Jeśli nie planujesz wykonać danej czynności w ramach procesu kompilacji, zalecamy cofnięcie odpowiedniego uprawnienia dla konta usługi Cloud Build, aby zachować zgodność z zasadą bezpieczeństwa polegającą na zapewnieniu jak najmniejszych uprawnień”.
Oś czasu
Firma Rhino Security Labs opublikowała artykuł informujący o problemie eskalacji uprawnień i utworzyła dla niego skrypt PoC w języku Python *.
Firma Orca Security poinformowała o swoich odkryciach zespół ds. bezpieczeństwa Google.
Google przeprowadziło dochodzenie i w odpowiedzi wprowadziło częściowe rozwiązanie.
Należy jednak zauważyć, że rozwiązanie Google nie wyeliminowało całkowicie odkrytego wektora eskalacji uprawnień (PE). Zamiast tego ograniczyło jego wpływ, skutecznie przekształcając go w wadę projektową, która nadal naraża organizacje na szersze ryzyko ataku na łańcuch dostaw. W związku z tym konieczne są dodatkowe środki bezpieczeństwa, aby zespoły ds. bezpieczeństwa mogły chronić się przed tym utrzymującym się ryzykiem.
Wniosek
Nadmierne uprawnienia przyznane domyślnemu kontu Google Cloud Build mogą zostać wykorzystane przez atakujących do przeprowadzenia ataku z wykorzystaniem konta dewelopera, umożliwiającego utworzenie kompilacji w chmurze. Atakujący mogą wykraść obraz kontenera, zmodyfikować go w sposób szkodliwy, a następnie przesłać do rejestru artefaktów, co stanowi atak na łańcuch dostaw oprogramowania, który może mieć katastrofalne skutki.
Odpowiedź Google pozostawia prace nad łagodzeniem ryzyka organizacjom korzystającym z usługi Cloud Build, które muszą cofnąć uprawnienia, aby kontrolować ryzyko. Można zwrócić się do Google o dodatkową pomoc w przyszłości w rozwiązywaniu problemów z bezpieczeństwem. CI/CD pomimo napiętego harmonogramu
Referencje
- Praca zgodnie z przeznaczeniem: eskalacja uprawnień RCE do IAM w kompilacji GCP Cloud. Rhino Security Labs.
- Bad.Build: Luki w zabezpieczeniach PE i RCE w Google Cloud Build. Orca Security.
- Biuletyn Bezpieczeństwa. Chmura Google.
Dowiedz się więcej o platformie Xygeni, pobierz arkusz danych platformy Xygeni
