Introductie
Orca Security heeft onlangs een ontwerpfout in de Google Cloud Build-service geïdentificeerd, genaamd ‘Bad.Build’. Deze fout vormt een ernstig veiligheidsrisico, omdat aanvallers hierdoor Privilege Escalation kunnen uitvoeren, waardoor ze ongeoorloofde toegang krijgen tot de codeopslagplaatsen van Google's Artifact Registry.
De gevolgen van dit beveiligingslek strekken zich uit tot de softwaretoeleveringsketen, aangezien aanvallers deze kunnen misbruiken om applicatie-images met kwaadaardige bedoelingen te manipuleren. Als gevolg hiervan kunnen nietsvermoedende gebruikers en klanten die de gemanipuleerde applicaties installeren, het slachtoffer worden van infecties.
Deze situatie herinnert ons aan de aanzienlijke impact die we hebben gezien bij eerdere aanvallen op de toeleveringsketen, zoals SolarWinds, 3CXen Verplaats het, waarbij de verstrekkende gevolgen van dergelijke veiligheidstekortkomingen worden benadrukt.
Hoe werkt het?
Google Cloud bouwen staat voor continue integratie/continue levering (CI/CD) service die wordt aangeboden binnen het Google Cloud-ecosysteem. Het speelt een cruciale rol in cloudgebaseerde applicaties door naadloos te interacteren met andere essentiële services zoals de Artifact Registry en de App Engine.
De betreffende fout is het gevolg van een probleem met buitensporige privileges. Met name de “logging.privateLogEntries.list' actie staat onbedoeld toe dat auditlogboeken een onbedoelde rol spelen, namelijk 'rollen/cloudbuild.builds.builder. '
Helaas is deze standaardrol toegewezen aan het cloudbuild-serviceaccount. Deze situatie vormt een groot risico, aangezien auditlogboeken gevoelige informatie bevatten, waarin alle machtigingen die aan het project zijn gekoppeld, worden onthuld. Deze onbedoelde toegang geeft aanvallers de mogelijkheid om het cloudbuild-account na te bootsen, waardoor ze kennis verwerven over welke acties door verschillende Google-accounts kunnen worden uitgevoerd. Bijgevolg opent dit de deur voor zijwaartse beweging en escalatie van privileges, wat een uiterst gevaarlijk beveiligingsprobleem oplevert.
Voor het nabootsen van het build-serviceaccount zijn alleen de cloudbuild.builds.create toestemming, die veel vooraf gedefinieerde rollen hebben en die aan ontwikkelaars worden verleend in elke redelijke CI/CD omgeving met behulp van Cloud Build. Dus als u toegang hebt tot een dergelijk ontwikkelaarsaccount, zal het maken van een op maat gemaakt buildconfiguratiebestand de gcloud logging leesopdracht, waarin de machtigingen worden vermeld.
Maar het probleem stopt hier niet: de Het Google Cloud Build-serviceaccount heeft zeer veel privileges, met veel acties voor interactie met het artefactregister van Goggle.
Door misbruik te maken van de kwetsbaarheid die de nabootsing van het standaard Cloud Build-serviceaccount mogelijk maakt, krijgen kwaadwillende actoren de mogelijkheid om te knoeien met afbeeldingen die zijn opgeslagen in Google's Artifact Registry door kwaadaardige code te injecteren. Als gevolg hiervan worden alle applicaties die zijn gebouwd op basis van deze gecompromitteerde afbeeldingen vatbaar voor mogelijke gevolgen, waaronder Denial-of-Service (DoS)-aanvallen, gegevensdiefstal en de verspreiding van malware.
De ernst van de situatie neemt toe wanneer deze gemanipuleerde applicaties bedoeld zijn voor implementatie in de omgevingen van klanten, ongeacht of ze on-premise of semi-SaaS. Dit breidt het risico uit tot buiten de infrastructuur van de leverende organisatie, wat leidt tot een supply chain-aanval die de omgevingen van de klanten infiltreert en compromitteert. Dergelijke aanvallen zijn vergelijkbaar met eerdere incidenten die zijn gezien bij inbreuken op de software-supply chain, zoals de inbreuk op SolarWinds. De implicaties van een dergelijke aanval kunnen ernstig zijn, wijdverbreide schade veroorzaken en meerdere organisaties binnen de supply chain treffen
Er was een soortgelijke privilege-escalatie PoC door Rhino-beveiligingslaboratoria, dat op een andere manier misbruik maakte van de buitensporige rechten van het standaard Cloud Build-account.
Waarom is het gevaarlijk?
De ernst van dit beveiligingslek ligt in het potentieel voor aanvallers om misbruik te maken van het Artefact Registry en kwaadaardige code in artefacten te introduceren. Als gevolg hiervan worden alle toepassingen die op basis van deze gecompromitteerde afbeeldingen zijn gebouwd, vatbaar voor verschillende nadelige effecten.
Deze effecten omvatten de mogelijkheid van Denial-of-Service-aanvallen, gegevensdiefstal en de verspreiding van malware. Bovendien, als deze gecompromitteerde applicaties vervolgens worden geïmplementeerd on-premise of in een semi-SaaS-omgeving, strekt het risico zich uit tot buiten de slachtofferorganisatie en heeft het ook gevolgen voor hun klanten. Dit scenario lijkt op de supply chain-aanval die werd waargenomen in het SolarWinds-incident, wat de mogelijke gevolgen voor zowel de organisatie als haar klantenbestand benadrukt.
Xygeni-aanbeveling
Pas het principe van Least Privilege toe
- Xygeni-sensor monitort gebruikersacties in de systemen waarop het wordt ingezet en deelt deze met ons kernplatform, dat ongebruikelijk gedrag of afwijkingen van normale patronen identificeert, zoals ongebruikelijke login tijdstippen of locaties, grote gegevensoverdrachten of wijzigingen in de toegangsrechten van gebruikers die buiten het bereik vallen van het 'normale' gemodelleerde gebruikersgedrag.
Het beleid en de audit van Xygeni dwingen best practices af op het gebied van toegangscontrole, multi-factor authenticatievereisten en op rollen gebaseerde machtigingstoepassingen om de toegang van gebruikers tot kritieke systemen en gegevens te beperken.
Deze tools monitoren gebruikersacties, zoals codewijzigingen, systeemtoegang of gegevensoverdrachten, en vergelijken deze met vooraf gedefinieerd beleid en gedragspatronen. Ze signaleren ook verdachte activiteiten, zoals ongeoorloofde toegang, buitensporige privileges of ongebruikelijke patronen van gegevensoverdracht.
Hoe met de kwetsbaarheid werd omgegaan
Nadat ze het Google-beveiligingsteam op de hoogte hadden gesteld van de kwetsbaarheid, ondernamen ze actie door de machtiging logging.privateLogEntries.list van het standaard Cloud Build-serviceaccount in te trekken. Ze erkenden dat hoewel de setIamPolicy-auditlogboeken relevant zijn voor auditdoeleinden, het verlenen van toegang tot deze logbestanden vanuit het perspectief van het cloudbuild-serviceaccount niet nodig was.
Het is echter van cruciaal belang om te begrijpen dat deze reactie niet rechtstreeks de kernkwetsbaarheid binnen het Artefact Registry heeft aangepakt. Als gevolg hiervan bleven de escalatievector van privileges en het potentiële risico van een aanval op de toeleveringsketen onaangetast. In wezen beperkte de oplossing van Google het probleem, maar elimineerde het niet volledig, waardoor organisaties nog steeds werden blootgesteld aan aanzienlijke risico's voor de softwaretoeleveringsketen.
Als reactie op de situatie adviseerde Google zijn klanten om de machtigingen van het standaard Cloud Build-serviceaccount te wijzigen door alle toegangsgegevens te verwijderen die afweken van het principe van minste privileges (PoLP). Deze maatregel is bedoeld om de veiligheid te verbeteren door ervoor te zorgen dat accounts alleen de minimaal noodzakelijke rechten hebben om de beoogde taken uit te voeren.
Ter verdediging tegen deze escalatieaanval met bevoegdheden is het noodzakelijk om de machtigingen die aan het Cloud Build Service Account zijn verleend te beperken en voorzichtig te zijn bij het verlenen van de rechten. cloudbuild.builds.create toestemming voor alle gebruikers in uw organisatie. Het belangrijkste is dat u moet weten dat elke gebruiker die toestemming heeft gekregen cloudbuild.builds.create, krijgt ook indirect alle rechten die zijn verleend aan het Cloud Build Service Account. Als u dat goed vindt, hoeft u zich misschien geen zorgen te maken over deze aanvalsvector, maar het wordt nog steeds ten zeerste aanbevolen om de standaardmachtigingen die aan het Cloud Build Service Account zijn verleend, te wijzigen.
Google beveelt dit kort en bondig aan, maar geeft geen verdere details:
“Als u niet van plan bent een actie uit te voeren als onderdeel van het bouwproces, raden we u aan de bijbehorende toestemming van het Cloud Build-serviceaccount in te trekken om te voldoen aan het beveiligingsprincipe van de minste bevoegdheden.”
Timeline
Rhino Security Labs heeft een bericht geplaatst over het probleem met de escalatie van bevoegdheden en heeft er een PoC Python-script * voor gemaakt.
Orca Security rapporteerde hun bevindingen aan het Google Security Team.
Google heeft een onderzoek uitgevoerd en als reactie daarop een gedeeltelijke oplossing geïmplementeerd.
Het is echter essentieel op te merken dat de oplossing van Google de ontdekte Privilege Escalation (PE)-vector niet volledig heeft geëlimineerd. In plaats daarvan beperkte het de impact ervan, waardoor het effectief werd omgezet in een ontwerpfout die organisaties nog steeds blootstelt aan het bredere risico van een supply chain-aanval. Daarom zijn aanvullende maatregelen nodig voor beveiligingsteams om zich tegen dit aanhoudende risico te beschermen.
Conclusie
Overmatige rechten die aan het standaard Google Cloud Build-account zijn verleend, kunnen door kwaadwillenden worden misbruikt om een aanval uit te voeren door een ontwikkelaarsaccount te gebruiken waarmee een cloud-build kan worden gemaakt. Aanvallers kunnen een containerimage exfiltreren, ermee knoeien met kwaadaardig gedrag en het vervolgens naar het Artefact Registry pushen, in een software supply chain-aanval die verwoestende gevolgen kan hebben.
Google's reactie laat het mitigatiewerk over aan de organisaties die de Cloud Build-service gebruiken, die de privileges moeten intrekken om het risico te beheersen. Men kan Google vragen om in de toekomst extra hulp te bieden bij het omgaan met beveiligingsproblemen met hun CI/CD systeem.
Referenties
- Werken zoals bedoeld: RCE naar IAM-rechtenescalatie in GCP Cloud Build. Rhino-beveiligingslaboratoria.
- Bad.Build: PE- en RCE-kwetsbaarheden in Google Cloud Build. Orka-beveiliging.
- Beveiligingsbulletin. Google Cloud.
Wilt u meer weten over het Xygeni-platform, download dan de platformdatasheet van Xygeni
